Re: Updated WD text (was RE: Minutes, 23 April 2014 WebFonts WG call)

On Thu, Apr 24, 2014 at 11:29 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

> The updated WD text with the edits we discussed on the call is now
> available:
> http://dev.w3.org/webfonts/WOFF2/spec/
> There are still some parts that Raph and I need to work on, but we should
> be able to have it ready before the publication next Thursday.
>

Fantastic, thank you Vlad, Raph and Chris!

We will target updating the reference implementation to reflect the
specification changes (specifically, the known table tags, reserved flag
bits and pre-processing no longer being optional) by early to mid next
week.  We will follow up once complete.

>
> Cheers,
> Vlad
>
>
> -----Original Message-----
> From: Chris Lilley [mailto:chris@w3.org]
> Sent: Wednesday, April 23, 2014 5:24 PM
> To: WebFonts WG
> Subject: Minutes, 23 April 2014 WebFonts WG call
>
> Hello WebFonts,
>
>   Minutes of todays meeting at
>
>   http://www.w3.org/2014/04/23-webfonts-minutes.html
>
>   and below as text for bots.
>
>                  WebFonts Working Group Teleconference
>
> 23 Apr 2014
>
>    See also: [2]IRC log
>
>       [2] http://www.w3.org/2014/04/23-webfonts-irc
>
> Attendees
>
>    Present
>           Vlad, Raph, David, Chris
>
>    Regrets
>           jonathan
>
>    Chair
>           vlad
>
>    Scribe
>           ChrisL
>
> Contents
>
>      * [3]Topics
>          1. [4]type names
>          2. [5]trasform glyph header
>          3. [6]editing and ssh
>          4. [7]glyph table
>      * [8]Summary of Action Items
>      __________________________________________________________
>
>    <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)
>
> Summary of Action Items
>
>    [End of minutes]
>      __________________________________________________________
>
>
> --
> Best regards,
>  Chris                          mailto:chris@w3.org
>
>
>
>