IRC log of webfonts on 2014-04-23

Timestamps are in UTC.

19:59:03 [RRSAgent]
RRSAgent has joined #webfonts
19:59:03 [RRSAgent]
logging to http://www.w3.org/2014/04/23-webfonts-irc
19:59:05 [trackbot]
RRSAgent, make logs world
19:59:05 [Zakim]
Zakim has joined #webfonts
19:59:07 [trackbot]
Zakim, this will be 3668
19:59:07 [Zakim]
ok, trackbot; I see IA_Fonts()4:00PM scheduled to start in 1 minute
19:59:08 [trackbot]
Meeting: WebFonts Working Group Teleconference
19:59:08 [trackbot]
Date: 23 April 2014
19:59:45 [Zakim]
IA_Fonts()4:00PM has now started
19:59:52 [Zakim]
+Vlad
19:59:53 [kuettel]
kuettel has joined #webfonts
20:00:13 [Zakim]
+[Google]
20:02:42 [raph]
raph has joined #webfonts
20:02:56 [Zakim]
+[Google.a]
20:04:15 [ChrisL]
ChrisL has joined #webfonts
20:04:33 [ChrisL]
rrsagent, here
20:04:33 [RRSAgent]
See http://www.w3.org/2014/04/23-webfonts-irc#T20-04-33
20:05:35 [Zakim]
+ChrisL
20:05:42 [ChrisL]
zakim, who is here?
20:05:42 [Zakim]
On the phone I see Vlad, [Google], [Google.a], ChrisL
20:05:44 [Zakim]
On IRC I see ChrisL, raph, kuettel, Zakim, RRSAgent, Vlad, trackbot
20:06:25 [ChrisL]
regrets: jonathan
20:06:33 [ChrisL]
scribenick: ChrisL
20:06:38 [ChrisL]
chair: vlad
20:08:34 [raph]
Chris: special value of "table follows".
20:08:41 [raph]
We have 7 bits to potentially use.
20:09:23 [raph]
Reasonable for special value to 127, but it seems to be 63.
20:09:39 [raph]
Vlad: most recent version of spec, the value is 127.
20:10:05 [ChrisL]
ok
20:10:06 [raph]
Chris: ok, sounds like it's fixed.
20:10:46 [raph]
Vlad: at the moment, we have exactly 63 tags, so it fits perfectly
20:10:58 [ChrisL]
Vlad: we could keep the one extra bit as reseerved for expansion
20:11:10 [ChrisL]
raph: yes
20:11:42 [ChrisL]
Vlad: so do we want 7 bits for tables, or 6 bits of flags and then if needed use the reserved bit for something else
20:12:36 [ChrisL]
ChrisL: seems better to have 50% of expansion space available
20:13:02 [ChrisL]
raph: agree, one extra flag is less useful than 64 more spaces for tables
20:13:14 [ChrisL]
... so it seems we have all the basis for expansion
20:13:27 [ChrisL]
Vlad: ok so that is what we have now
20:14:07 [ChrisL]
kuettel: on the flip side though, on the proposal we had 63 as arbitrary tag follows
20:14:24 [ChrisL]
... so we interpreted it to mean as run with that set of table tags
20:14:43 [ChrisL]
... need to lock this down for stable implementation
20:15:13 [ChrisL]
ChrisL: thought last telcon we agreed at last code point in the space
20:15:29 [ChrisL]
Vlad: keeping rest of table empty and very last value as a flag
20:16:02 [ChrisL]
kuettel: we need to decide so the code doesn't change
20:17:05 [ChrisL]
raph: whole discussion on future expansion is speculative. want to decide on an allocation now
20:17:16 [ChrisL]
... might expand but should not revise
20:18:39 [ChrisL]
ChrisL: 127 seems clearer once expansion has happened
20:19:08 [ChrisL]
kuettel: when could we start using woff2 if everything is fluid? what is the target date
20:20:03 [ChrisL]
raph: what should code do with unknown, registered values?
20:20:43 [ChrisL]
... could break existing implementations
20:21:01 [ChrisL]
ChrisL: hadn't realised david was against expandability at all
20:21:36 [ChrisL]
kuettel: want to know when we can start really serving woff2, not clear if we are not firming up the spec
20:21:44 [ChrisL]
raph: we are firming up the spec
20:22:02 [ChrisL]
... not quite at the point of freezing it but its very good
20:22:38 [ChrisL]
... is known table space user expandable? no, it isn't, not for that one. expansion is to use the escape
20:23:11 [ChrisL]
... so four bytes cost gives stability and expandability
20:23:18 [ChrisL]
kuettel: agree
20:23:47 [ChrisL]
Vlad: also agree but there are two sides. if known tag table is fixed then its six bits and no expansion
20:25:25 [ChrisL]
ChrisL: was not clear before, the table list can only be edited by bumping the spec version and the running code
20:25:42 [ChrisL]
Vlad: yes, usr expansion is by using 4 bytes for new tables
20:26:18 [ChrisL]
Vlad: so one extra but can be reserved and we can use it as we decide
20:26:25 [ChrisL]
kuettel: sounds great
20:26:39 [ChrisL]
... users can't expand the code across all browsers
20:26:45 [ChrisL]
Vlad: agreed
20:27:46 [ChrisL]
RESOLUTION: flag value goes back to 63, seventh bit is reserved for standardization
20:28:26 [ChrisL]
Vlad: flag bits, before we had bit 7 as flag for opional transform. now its mandatory so we don't need that bit
20:28:51 [ChrisL]
ChrisL: we should reserve for expansion
20:29:13 [ChrisL]
Vlad: raph you mentioned possible future transforms?
20:29:27 [ChrisL]
raph: yes in a future spec version, not for this version
20:29:51 [ChrisL]
... we could think of transforms from MTX that might be used. and cmap transforms.
20:30:22 [ChrisL]
... decided not to do them as very minimal gains compared to loca etc. and very complex. but later we might decide to add such a thin
20:30:29 [ChrisL]
s/thin/thing/
20:30:56 [ChrisL]
... could build a backwards compat woff2.1 with extra transforms
20:31:21 [ChrisL]
... premature to do now but we want to allow future standardization
20:31:43 [ChrisL]
... so having a transform bit is attractive
20:32:29 [ChrisL]
Vlad: you only need the transform bit if you need a defined transform that can be optionally applied
20:32:48 [ChrisL]
... currently two transforms defined and not optional, which is good
20:33:13 [ChrisL]
... if we add some optional transform later we would need a flag. if its not optional we don't
20:33:32 [ChrisL]
... more flexible to eliminate the duplication
20:34:19 [ChrisL]
ChrisL: much better to undefine, have it reserved for future standarization
20:34:44 [ChrisL]
raph: think the bit makes atable easier to parse, have to know based on the length field
20:35:01 [ChrisL]
... simpler than resolving. not complex in either case
20:35:25 [ChrisL]
... test is very simple, glyph and loca, not much more complex than bit7=1
20:36:05 [ChrisL]
... in a future if we have morte transforms, easier to look for one flag
20:36:33 [ChrisL]
... that said its all weak preferences because these are easy code changes based on woff version
20:36:52 [ChrisL]
Vlad: no strong preference
20:37:05 [ChrisL]
... reserved and unassigned is more flexible in the future
20:37:28 [ChrisL]
kuettel: google compression team noticed this also, cleaner to just reserve the bit
20:37:50 [ChrisL]
kuettel: so its 2 bits now reserved?
20:37:56 [ChrisL]
Vlad: yes, 6 & 7
20:38:05 [ChrisL]
(general agreement)
20:38:23 [ChrisL]
RESOLVED: bits 6 and 7 are reserved for future standardization
20:38:35 [ChrisL]
kuettel: we can look at code changes
20:38:43 [ChrisL]
raph: its a couple of lines change
20:39:45 [ChrisL]
Vlad: "spec is not yet frozen" claim needs to wait until ther are two independent implementations
20:40:00 [ChrisL]
raph: absolutely true. Hope it won't change in a substantial way
20:41:02 [ChrisL]
kuettel: kenji met with other browser vendors, they were all eager to see someone else plow ahead and show a beneficial impact
20:41:34 [ChrisL]
ChrisL: did they see the results from the evaluation report?
20:41:37 [ChrisL]
kuettel: assume so
20:42:07 [ChrisL]
topic: type names
20:42:17 [raph]
Chris: about type names
20:42:45 [raph]
Chris: in hobby work on microcontrollers, code is moving from 8 to 16 bits
20:43:10 [raph]
lots of problems with types without explicit bit length (what is the length of "short")
20:43:32 [raph]
Chris: prefers type names of the form "uint16"
20:43:45 [ChrisL]
prefer to see uint16 and so on ie explicit on bit length and sign for types
20:43:59 [raph]
Vlad: "long" is a similar problem, as it has historically been 32 bit but is in transition to 64 bits
20:44:30 [ChrisL]
Vlad: definitely see the point, we use short and ushort for example
20:44:58 [ChrisL]
raph: agree with ChrisL, add that uint16 closely matches actual types in c and suchlike languages
20:45:12 [ChrisL]
... do not want to use short and long in many languages
20:45:27 [ChrisL]
originally chosen based on 1970s assumptions
20:46:05 [ChrisL]
RESOLVED: use uint16 instead of ushort, and so on
20:46:14 [ChrisL]
ChrisL: what to do with 255short?
20:46:39 [ChrisL]
raph: that is from MTX but that is not a normative reference, so calling it 16 is nice.
20:47:02 [ChrisL]
... explains why there are two integer encodings and it helps explain what they are and why they are used
20:47:12 [ChrisL]
... ok with it having two numbers
20:47:25 [ChrisL]
kuettel: impact on reference implementation
20:47:50 [ChrisL]
raph: better to update the names from a source code viewpoint but the wire format does not change
20:48:28 [ChrisL]
ChrisL: no impact on data on the wire, just makes it more portable in the future
20:48:45 [ChrisL]
raph: types ued to represent the data already the uint16_t stuff
20:48:49 [ChrisL]
kuettel: ok great
20:49:05 [ChrisL]
Vlad: will go ahrad and modify those
20:49:33 [ChrisL]
topic: trasform glyph header
20:50:05 [ChrisL]
Vlad: stream of uint16 to encode it as with OT. Zeroor positive, only negative 1 if a composite
20:50:38 [ChrisL]
why not use an unsigned type wit an explicit flag value
20:50:57 [ChrisL]
... composite done like bounding box bitmap field
20:51:13 [ChrisL]
... separate bitfield to say which glyphs are composite
20:51:21 [ChrisL]
.. sosaves one byte per glyph
20:51:59 [ChrisL]
raph: has come up before, proposal was to encode n contours+1 and we measured it, there was no gain
20:52:13 [ChrisL]
.. so separate bitmap might be a loss due to lack of locality
20:52:31 [ChrisL]
... so suspect it will be a tiny net loss
20:53:08 [ChrisL]
... has very low entropy, often very few number of outlines, blocks of the same value so these compress well
20:53:27 [ChrisL]
... extracting this redundancy compresses well
20:53:58 [ChrisL]
... also looked at deltas rather than explicit values, its an empirical question
20:54:17 [ChrisL]
... but this one was examined and was rejected. what we have is simple and very performant
20:54:26 [ChrisL]
Vlad: ok, good that it was examined
20:54:58 [ChrisL]
raph: ok this was actually done in the lzma days, to be fair, but brotli is actually better
20:55:06 [ChrisL]
(general agreement)
20:55:33 [ChrisL]
topic: editing and ssh
20:55:41 [ChrisL]
ChrisL: is ssh working now?
20:55:44 [ChrisL]
Vlad: yes
20:56:20 [ChrisL]
... need to set up tortoise
20:56:55 [ChrisL]
ChrisL: so what do we think of for a publication date
20:57:06 [ChrisL]
Vlad: if cvs working, edits done tomorrow
20:57:48 [ChrisL]
ChrisL: ok so likely good to go on Thursday
20:58:00 [ChrisL]
Vlad: two other questions can decide offlist
20:58:15 [ChrisL]
raph: can do today or tomorrow
20:58:22 [ChrisL]
zakim, list attendees
20:58:22 [Zakim]
As of this point the attendees have been Vlad, [Google], ChrisL
20:58:45 [ChrisL]
present: Vlad, Raph, David, Chris
20:58:52 [ChrisL]
topic: glyph table
20:59:20 [ChrisL]
Vlad: after transforma nd compressed, table has to be recreated so size may be less than original, in some cases a bit more
20:59:32 [ChrisL]
... functionality identical but size not
20:59:43 [ChrisL]
... due to encoding of deltas and so on
21:00:07 [ChrisL]
... so confusion as to the original size. what does it mean?
21:00:28 [ChrisL]
Vlad: raph introduced concept of "nominal size" seemed confusing
21:00:58 [ChrisL]
Vlad: so perhaps say the actual original size is in the header, and reconstructed size will vary
21:01:20 [ChrisL]
... depending on how it was reconstructed. so make sure it fits
21:01:31 [ChrisL]
... needs a spec clarification
21:01:41 [ChrisL]
raph: simpler from a spec point of view
21:02:05 [ChrisL]
.. responsibility of the recreation process. manageable complexity.
21:02:23 [ChrisL]
... gives them exactly how much memory to allocate
21:03:18 [ChrisL]
ChrisL: can it ever be bigger? if so its not how much to allocate
21:03:37 [ChrisL]
raph: if you follow the reconstruction exactly it is the exact number
21:03:56 [ChrisL]
Vlad: not sure we achieved that? what if we use absolute values always
21:04:35 [ChrisL]
raph: hence the IF. if you follow the rules it gives the exact size. if you don't then results vary. its fairly simple
21:05:03 [ChrisL]
... encoder can't just use the value in the source font because it might have used some hyper encoding
21:05:22 [ChrisL]
... so burden is on the woff compressor to write the exact value
21:05:39 [ChrisL]
... must be prepared to cope with a dynamic size that is slightly different
21:05:46 [ChrisL]
.. would make the spec simpler
21:06:19 [ChrisL]
... and the imple,mentation more complex, requires dynamic allocation
21:06:38 [ChrisL]
Vlad: would not sign off tat it gives a guarantee.
21:06:47 [ChrisL]
raph: want to see what the gap is
21:07:28 [ChrisL]
Vlad: input font has a glyph table of size n. nominal size is not the same as n, its a guess by the woff2 encoding tool from decompose and recompose
21:07:47 [ChrisL]
... even if done, still no guarantee that the implementation gets tht number
21:08:01 [ChrisL]
... may not match either nominal or original size
21:08:21 [ChrisL]
... or we could replace it by saying what the original size was
21:08:29 [ChrisL]
raph: of little value
21:09:00 [ChrisL]
Vlad: its a real reference point, pont to OT spec, explicitly say implementors have choices here which impact final reconstructed size
21:09:34 [ChrisL]
ChrisL: important to be clear as very different from woff1
21:10:10 [ChrisL]
raph: good to discuss on mailing list. hear the arguments, think i can make the case that the nominal size can be specified very cleanly
21:10:20 [ChrisL]
... can get to an actual guarantee
21:10:42 [ChrisL]
... reconstruction is very simple, its not complex or tricky.
21:11:06 [ChrisL]
... if you do that, you get the excact value. so it can be validated
21:11:19 [ChrisL]
Vlad: needs an exact reconstruction algorithm
21:11:23 [ChrisL]
raph: yes
21:11:49 [ChrisL]
(take to email)
21:12:14 [ChrisL]
raph: need info from zoltan
21:12:39 [ChrisL]
Vlad: changes do not affect existing implementations
21:13:13 [ChrisL]
raph: possible failure mode: hyper optimised original font, loose reconstruction gets a bit bigger one
21:13:33 [ChrisL]
Vlad: reconstructed font is for internal use, not shipped
21:13:49 [ChrisL]
raph: eliminating it from the spec make that failure go away
21:15:10 [ChrisL]
ChrisL: want the spec to be clear and testable
21:15:23 [ChrisL]
raph: reconstruction needs to be specced exactly
21:16:18 [ChrisL]
ChrisL: prefer to see details in spec not in reference software
21:16:45 [ChrisL]
raph: spec gives the algorithm focussing on some crucial choices on deltas, flag values, flag repeats.
21:17:06 [ChrisL]
... current spec says how to make those choices, and the padding. everything else is from OT spec
21:17:30 [ChrisL]
ChrisL: so we can make a crisp spec that specifies everything
21:18:31 [ChrisL]
ChrisL: lets do that after FPWD though, spec really needs to be published asap
21:18:51 [ChrisL]
raph: yes, should not block on this
21:19:06 [ChrisL]
... but its fairly simple to tighten up the spec
21:20:13 [ChrisL]
kuettel: wire format changes were covered, 63 is type flag. then we can update the reference implementation
21:20:57 [ChrisL]
ChrisL: editors draft will be updated by tomorrow, these are small changes
21:21:19 [ChrisL]
(adjourned)
21:21:28 [ChrisL]
rrsagent, make minutes
21:21:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/04/23-webfonts-minutes.html ChrisL
21:22:01 [Zakim]
-ChrisL
21:22:06 [Zakim]
-[Google.a]
21:22:08 [Zakim]
-Vlad
21:22:09 [Zakim]
-[Google]
21:22:10 [Zakim]
IA_Fonts()4:00PM has ended
21:22:10 [Zakim]
Attendees were Vlad, [Google], ChrisL
23:30:29 [jdaggett]
jdaggett has joined #webfonts
23:59:32 [Zakim]
Zakim has left #webfonts