<trackbot> Date: 23 April 2014

<scribe> scribenick: ChrisL

<raph> Chris: special value of "table follows".

<raph> We have 7 bits to potentially use.

<raph> Reasonable for special value to 127, but it seems to be 63.

<raph> Vlad: most recent version of spec, the value is 127.

ok

<raph> Chris: ok, sounds like it's fixed.

<raph> Vlad: at the moment, we have exactly 63 tags, so it fits perfectly

Vlad: we could keep the one extra bit as reseerved for expansion

raph: yes

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

ChrisL: seems better to have 50% of expansion space available

raph: agree, one extra flag is less useful than 64 more spaces for tables
... so it seems we have all the basis for expansion

Vlad: ok so that is what we have now

kuettel: on the flip side though, on the proposal we had 63 as arbitrary tag follows
... so we interpreted it to mean as run with that set of table tags
... need to lock this down for stable implementation

ChrisL: thought last telcon we agreed at last code point in the space

Vlad: keeping rest of table empty and very last value as a flag

kuettel: we need to decide so the code doesn't change

raph: whole discussion on future expansion is speculative. want to decide on an allocation now
... might expand but should not revise

ChrisL: 127 seems clearer once expansion has happened

kuettel: when could we start using woff2 if everything is fluid? what is the target date

raph: what should code do with unknown, registered values?
... could break existing implementations

ChrisL: hadn't realised david was against expandability at all

kuettel: want to know when we can start really serving woff2, not clear if we are not firming up the spec

raph: we are firming up the spec
... not quite at the point of freezing it but its very good
... is known table space user expandable? no, it isn't, not for that one. expansion is to use the escape
... so four bytes cost gives stability and expandability

kuettel: agree

Vlad: also agree but there are two sides. if known tag table is fixed then its six bits and no expansion

ChrisL: was not clear before, the table list can only be edited by bumping the spec version and the running code

Vlad: yes, usr expansion is by using 4 bytes for new tables
... so one extra but can be reserved and we can use it as we decide

kuettel: sounds great
... users can't expand the code across all browsers

Vlad: agreed

RESOLUTION: flag value goes back to 63, seventh bit is reserved for standardization

Vlad: flag bits, before we had bit 7 as flag for opional transform. now its mandatory so we don't need that bit

ChrisL: we should reserve for expansion

Vlad: raph you mentioned possible future transforms?

raph: yes in a future spec version, not for this version
... we could think of transforms from MTX that might be used. and cmap transforms.
... 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 thing
... could build a backwards compat woff2.1 with extra transforms
... premature to do now but we want to allow future standardization
... so having a transform bit is attractive

Vlad: you only need the transform bit if you need a defined transform that can be optionally applied
... currently two transforms defined and not optional, which is good
... if we add some optional transform later we would need a flag. if its not optional we don't
... more flexible to eliminate the duplication

ChrisL: much better to undefine, have it reserved for future standarization

raph: think the bit makes atable easier to parse, have to know based on the length field
... simpler than resolving. not complex in either case
... test is very simple, glyph and loca, not much more complex than bit7=1
... in a future if we have morte transforms, easier to look for one flag
... that said its all weak preferences because these are easy code changes based on woff version

Vlad: no strong preference
... reserved and unassigned is more flexible in the future

kuettel: google compression team noticed this also, cleaner to just reserve the bit
... so its 2 bits now reserved?

Vlad: yes, 6 & 7

(general agreement)

RESOLUTION: bits 6 and 7 are reserved for future standardization

kuettel: we can look at code changes

raph: its a couple of lines change

Vlad: "spec is not yet frozen" claim needs to wait until ther are two independent implementations

raph: absolutely true. Hope it won't change in a substantial way

kuettel: kenji met with other browser vendors, they were all eager to see someone else plow ahead and show a beneficial impact

ChrisL: did they see the results from the evaluation report?

kuettel: assume so

type names

<raph> Chris: about type names

<raph> Chris: in hobby work on microcontrollers, code is moving from 8 to 16 bits

<raph> lots of problems with types without explicit bit length (what is the length of "short")

<raph> Chris: prefers type names of the form "uint16"

prefer to see uint16 and so on ie explicit on bit length and sign for types

<raph> Vlad: "long" is a similar problem, as it has historically been 32 bit but is in transition to 64 bits

Vlad: definitely see the point, we use short and ushort for example

raph: agree with ChrisL, add that uint16 closely matches actual types in c and suchlike languages
... do not want to use short and long in many languages

originally chosen based on 1970s assumptions

RESOLUTION: use uint16 instead of ushort, and so on

ChrisL: what to do with 255short?

raph: that is from MTX but that is not a normative reference, so calling it 16 is nice.
... explains why there are two integer encodings and it helps explain what they are and why they are used
... ok with it having two numbers

kuettel: impact on reference implementation

raph: better to update the names from a source code viewpoint but the wire format does not change

ChrisL: no impact on data on the wire, just makes it more portable in the future

raph: types ued to represent the data already the uint16_t stuff

kuettel: ok great

Vlad: will go ahrad and modify those

trasform glyph header

Vlad: stream of uint16 to encode it as with OT. Zeroor positive, only negative 1 if a composite

why not use an unsigned type wit an explicit flag value

scribe: composite done like bounding box bitmap field
... separate bitfield to say which glyphs are composite
... sosaves one byte per glyph

raph: has come up before, proposal was to encode n contours+1 and we measured it, there was no gain
... so separate bitmap might be a loss due to lack of locality
... so suspect it will be a tiny net loss
... has very low entropy, often very few number of outlines, blocks of the same value so these compress well
... extracting this redundancy compresses well
... also looked at deltas rather than explicit values, its an empirical question
... but this one was examined and was rejected. what we have is simple and very performant

Vlad: ok, good that it was examined

raph: ok this was actually done in the lzma days, to be fair, but brotli is actually better

(general agreement)

editing and ssh

ChrisL: is ssh working now?

Vlad: yes
... need to set up tortoise

ChrisL: so what do we think of for a publication date

Vlad: if cvs working, edits done tomorrow

ChrisL: ok so likely good to go on Thursday

Vlad: two other questions can decide offlist

raph: can do today or tomorrow

glyph table

Vlad: after transforma nd compressed, table has to be recreated so size may be less than original, in some cases a bit more
... functionality identical but size not
... due to encoding of deltas and so on
... so confusion as to the original size. what does it mean?
... raph introduced concept of "nominal size" seemed confusing
... so perhaps say the actual original size is in the header, and reconstructed size will vary
... depending on how it was reconstructed. so make sure it fits
... needs a spec clarification

raph: simpler from a spec point of view
... responsibility of the recreation process. manageable complexity.
... gives them exactly how much memory to allocate

ChrisL: can it ever be bigger? if so its not how much to allocate

raph: if you follow the reconstruction exactly it is the exact number

Vlad: not sure we achieved that? what if we use absolute values always

raph: hence the IF. if you follow the rules it gives the exact size. if you don't then results vary. its fairly simple
... encoder can't just use the value in the source font because it might have used some hyper encoding
... so burden is on the woff compressor to write the exact value
... must be prepared to cope with a dynamic size that is slightly different
... would make the spec simpler
... and the imple,mentation more complex, requires dynamic allocation

Vlad: would not sign off tat it gives a guarantee.

raph: want to see what the gap is

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
... even if done, still no guarantee that the implementation gets tht number
... may not match either nominal or original size
... or we could replace it by saying what the original size was

raph: of little value

Vlad: its a real reference point, pont to OT spec, explicitly say implementors have choices here which impact final reconstructed size

ChrisL: important to be clear as very different from woff1

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
... can get to an actual guarantee
... reconstruction is very simple, its not complex or tricky.
... if you do that, you get the excact value. so it can be validated

Vlad: needs an exact reconstruction algorithm

raph: yes

(take to email)

raph: need info from zoltan

Vlad: changes do not affect existing implementations

raph: possible failure mode: hyper optimised original font, loose reconstruction gets a bit bigger one

Vlad: reconstructed font is for internal use, not shipped

raph: eliminating it from the spec make that failure go away

ChrisL: want the spec to be clear and testable

raph: reconstruction needs to be specced exactly

ChrisL: prefer to see details in spec not in reference software

raph: spec gives the algorithm focussing on some crucial choices on deltas, flag values, flag repeats.
... current spec says how to make those choices, and the padding. everything else is from OT spec

ChrisL: so we can make a crisp spec that specifies everything
... lets do that after FPWD though, spec really needs to be published asap

raph: yes, should not block on this
... but its fairly simple to tighten up the spec

kuettel: wire format changes were covered, 63 is type flag. then we can update the reference implementation

ChrisL: editors draft will be updated by tomorrow, these are small changes

(adjourned)

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/thin/thing/
Found ScribeNick: ChrisL
Inferring Scribes: ChrisL
Default Present: Vlad, [Google], ChrisL
Present: Vlad Raph David Chris
Regrets: jonathan
Found Date: 23 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/23-webfonts-minutes.html
People with action items: