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

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.

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

Received on Thursday, 24 April 2014 18:30:15 UTC