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