- From: Chris Lilley <chris@w3.org>
- Date: Wed, 23 Apr 2014 23:24:28 +0200
- To: WebFonts WG <public-webfonts-wg@w3.org>
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 Wednesday, 23 April 2014 21:24:31 UTC