- From: Chris Lilley <chris@w3.org>
- Date: Tue, 13 Oct 2015 21:49:00 +0200
- To: WebFonts WG <public-webfonts-wg@w3.org>
Hello WebFonts WG,
Minutes of the São Paulo meeting are at the link
http://www.w3.org/2015/10/13-webfonts-minutes.html
and below as text for trackbot
WebFonts Working Group Teleconference
13 Oct 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/10/13-webfonts-irc
Attendees
Present
Vlad, Chris, Behedad, Garret, Rod, David, Nashan, Raph,
sergeym, (Zurich, Team), jfkthame, Zoltan, Jyrki,
Evegenii
Regrets
Chair
Vlad
Scribe
ChrisL
Contents
* [3]Topics
1. [4]WOFF2 compression improvements
2. [5]spec review, latest updates
3. [6]Anything other than hmtx, basically
4. [7]CTS planning
5. [8]font top-level type
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 13 October 2015
<scribe> Scribe: ChrisL
WOFF2 compression improvements
(slides will be online)
<scribe> Meeting: WebFonts WG f2f, Brazil
decompress and reconstructtake about 50% of the CPU time each,
so both need to be improved. Improving just one had limitedd
effectiveness
recently, much better performance on ARM
16.8% improvement (see slides)
20.8% woff2 speedup on x64
optimising brotli, 2.4x speedup on ARM
doing decompression and reconstruction on separate threads
might be faster (see "speculative" on the discussion graph in
slides)
Vlad: need to balance download time for extra data vs.
decompression speeed gaons. End to end timing.
kuettel: Some people say use woff1 vs woff2 in some cases. But
maybe can tune woff2 appropriately for each use case
... woff1 faster in some cases, which motivated this work
Vlad: click to available font time is important.
kuettel: we have seen incredibly high cache hitrates which
removes the transfer time
raph: speed in Mb/s is the quantity that makes sense, even
slowest is 30Mb/sec which is 300 mbits/s so thatputs a bound on
the network speed whewre transfer time make s adifference
... on google fibre, send woff1 :)
Vlad: monotype announced a new websitre design, so it is slow
until the chache is refreshed with all the new fonts
raph: we want to optimise for device utilisation pov
kuettel - milliseconds in delivery time affect the economic
balance
(we need more data on worst case performance)
Vlad: discussed with Kenji, on total time, and these times are
3-6 seconds on some web pages
... decompression is a tiny fraction of that
ChrisL: brotli ID is onw in the "ISE review" status. This means
Independent Specification Editor
[10]https://datatracker.ietf.org/doc/draft-alakuijala-brotli/
[10] https://datatracker.ietf.org/doc/draft-alakuijala-brotli/
Yergei: Marc said he had completed spec review and built an
independent decoder. he is enthusiastic and supportive and has
completed review
ChrisL: lets havew that email in the public archive
... also a link to the slides and a spreadsheet of the new data
on google font corpus, please
topic; agenda
Vlad: spec updates, possible spec modifications based on
additional data on htmx and skipping all transforms
rod: not completed that analysis, code is doing unnecessary
things so far
Vlad: also a discussion on CTS with Khaled
kuettel: also lunch, from 11:30 on it is available, maybe break
at 12
<jfkthame> ChrisL: yes, mostly
ChrisL: also agenda item on font/* top level type
<jfkthame> don't worry about me ... i'll be hanging around for
several hours yet
<jfkthame> though i'll come and go a bit i'm sure - just do
whatever works for you there
</lunch>
spec review, latest updates
Vlad: update, recent discussion on hmtx
rod: khaled said the new tests look fine to him
Vlad: some editorial changes wrt the suggested text from
jfkthame
... accepted with modifications, and some text was not dropped
... first update was para after table entry description,
modified the flag description
<RSheeter>
[11]http://dev.w3.org/webfonts/WOFF2/spec/#table_dir_format
[11] http://dev.w3.org/webfonts/WOFF2/spec/#table_dir_format
Vlad: if we decide to do untransformed we have three bits
available as flags for transform version
(discussion on breaking changes, 000=untransformed would break
all existing woff2 fonts)
kuettel: you were looking at making it backwards compat?
RSheeter: that didn't work
<RSheeter> does [12]http://dev.w3.org/webfonts/WOFF2/spec/ at
least work?
[12] http://dev.w3.org/webfonts/WOFF2/spec/
raph: what is the vaslue of making a change that invalidates
all fonts. and if not, what do we do for existing. its crufty
to define 001 = untransformed for glyf and loca
<RSheeter> oh sorry, I thought that didn't work meant the link,
lol
raph: needs a really substantial gain, like a huge decrease in
filesize, that affects users. a gain in future extensibility
does not count here, end users gain nothing
<jfkthame> we could handle this by defining a flag in the
'reserved' field of the WOFF2 header, it would mean decoders
would need to test an extra flag to know how to interpret the
transform version, but would be very cheap to implement
raph: we could do this with magic numbers
ChrisL: that fossilizes the previous design for all time
kuettel: maybe make 000 be the recommended one for typical
compression
Vlad: when we decode table directory, every field other than
flags is variable length and optional.
... so it is a bit inconvenient, we rely on specific tag values
... extending possibility of new transforms, instread of
relying on tags but using flag values, it says if it is
transformed, and if there is more than one version which one
ChrisL: we could say 000 except "for historical reasons" 001
for glyf and loca
raph: +1
rod: +1
Vlad: for glyf and loca, define 11 as null transform, rest have
00 as nul for all, then easily switch from tags to flags
raph: its a small enough amount of cruft, we can live with it
resolved: do not break backwards compat, go with flags solution
and document in spec
<scribe> ACTION: vlad to update spec for flags, weith glyf and
loca treated specially for historical reasons [recorded in
[13]http://www.w3.org/2015/10/13-webfonts-minutes.html#action01
]
<trackbot> Created ACTION-188 - Update spec for flags, weith
glyf and loca treated specially for historical reasons [on
Vladimir Levantovsky - due 2015-10-20].
Vlad: the existing implementations will need to change from
tags to flags to detect presence of transformation
raph: so, tags *and* flags?
Vlad: no
RSheeter: yes
:)
raph and RSheeter are correct :)
(conclusion, only glyf and loca are special; for all other
tables the tag is irrelevant)
RSheeter: say in spec not to mark only one of glyf and loca as
untransformed, once we introduce the null transform
kuettel: and add a test for that
Vlad: next change was to say for hmtx that null transform is an
option
[14]http://dev.w3.org/webfonts/WOFF2/spec/#hmtx_table_format
[14] http://dev.w3.org/webfonts/WOFF2/spec/#hmtx_table_format
Vlad: decided to keep the text because it also describes what
happens if there is a null transform
... note added per jfkthame suggestion
... we need a test for that
kuettel: we have not made the expected gains from disabling
transform.
<jfkthame> no objection to what vlad's done from me
raph: no harm in the constraint either
Vlad: when transform is applied, these are the constraints
ChrisL: concerned over the "can only be used" in a
non-normative note - that is not testable
Vlad: hmtx is required in OT, however CFF has its own numbers
and these take precedence. Adobe did not ever update so give
hmtx precedence! so we can't resolve that here
... so in CFF the hmtx table will have different values from
those in the CFF
RSheeter: can we say that in the spec?
Vlad: with collections extended to CFF, there may be a cvase
with a collection using CFF and different metric for each font,
so multiple hmtx
behedad: no because you can't change the lSB
... (draws on whiteboard)
Vlad: Sairus said they want their implementation updated to
follow spec and use hmtx as the preferred one, to also work in
collections
raph: language is ambiguous if there are multiple glyf tables
*in one file*
... needs to say "corresponding glyf table"
Vlad: or remove file, just say font
RSheeter: our entire description assumes hmtx belongs to *a*
glyf table, in a collection that may not be true
Vlad: hmtx would have to reference all the glyphs in that case
raph: there is a many to many relationshp - imagine a
collection with proportional and monospace using the same glyf
and two hmtx. only one can be reconstructed
(we agree)
raph: this is now a choice of the encoder, and the spec does
not reflect that
sergeym: there exist collections with multiple glyf tables
raph: prefer to not constrain what the encoder does
... if we remove the word file, so we mean in a font, there is
a single table directory. Maybe add language to make explicit
that if there are multiple fonts in a file, it must be the case
for each hmtx/glyf pair, transform only applied if they match
Vlad: maybe add more explanation, for font collections where
hmtx is shared, check that all of them comply else do not
transform
RSheeter: check for all the fonts in a collection
ChrisL: prefer for it to be explicit; one is "may transform "
and one "must not transform" so it is clear
action vlad to clarify about shared hmtx tables, can only
transform is all glyf tables match
<trackbot> Created ACTION-189 - Clarify about shared hmtx
tables, can only transform is all glyf tables match [on
Vladimir Levantovsky - due 2015-10-20].
behedad: bounding box can lie about actual xmin, optimisation
is toremove it. This one does not say in which way they must
match
<RSheeter> zakim has left?
Vlad: You refer to glyf transform, not hmtx transform
(more whiteboard, behedad vs. vlad)
vlad uses "it is clear already" It's super effective!
Vlad: if it is dropped we recalculate it first, then go onto
the next step
raph: there is a data dependency, cannot calc until you can
look at the glyf table
behedad: rather see the hmtx early to know I fill in the lSB
raph: these constrains minimise the decoder memory requirements
... so the expected pairng listed in the spec might not be
possible in the case of many to one or one to many
relationships between glyf and hmtx
... do not want additional table order constraints for glyh and
hmtx, unlike glyf and loca
... need to refer to table directory structure. and the
additional constraint of checking all hmtx-glyf pairings
... normative for decoder reconstruction to use table directory
structure to determine that
Anything other than hmtx, basically
raph: we need all the permutations of one and many glyf and
hmtx all in the test suite
action-189?
<trackbot> action-189 -- Vladimir Levantovsky to Clarify about
shared hmtx tables, can only transform is all glyf tables match
-- due 2015-10-20 -- OPEN
<trackbot> [15]http://www.w3.org/Fonts/WG/track/actions/189
[15] http://www.w3.org/Fonts/WG/track/actions/189
raph: this adds a file format validity test
... propose both an authoring test (that it does not transform
hmtx) and a ff test (with a n invalidy created transformed
hmtx)
action vlad to add conf reqt on AT and FF to test for
non-transformable shared hmtx with non-atching metrics in the
two glyf tables
<trackbot> Created ACTION-190 - Add conf reqt on at and ff to
test for non-transformable shared hmtx with non-atching metrics
in the two glyf tables [on Vladimir Levantovsky - due
2015-10-20].
CTS planning
[16]https://www.w3.org/Fonts/WG/wiki/Main_Page#WOFF_2.0_Test_Su
ite
[16] https://www.w3.org/Fonts/WG/wiki/Main_Page#WOFF_2.0_Test_Suite
[17]https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustL
oadFontCollection
[17] https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustLoadFontCollection
ChrisL: sounds more like a decoder test
browsers have no collection support currently
raph: lower levels of chrome font stack do support collections.
ski supports collections
... ask Kenji
... chromium bug exists
was moved to decoder tests
[18]https://www.w3.org/Fonts/WG/wiki/TestPlan20-Decoder#mustLoa
dFontCollection
[18] https://www.w3.org/Fonts/WG/wiki/TestPlan20-Decoder#mustLoadFontCollection
[19]https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustC
heckLSBFlags
[19] https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustCheckLSBFlags
[20]https://www.w3.org/Fonts/WG/wiki/TestPlan20-AuthoringTool#m
ustEliminateLSBs
[20] https://www.w3.org/Fonts/WG/wiki/TestPlan20-AuthoringTool#mustEliminateLSBs
font top-level type
Chris has to make a new ID before the IETF Yokohama meeting, to
be considered by the APP Area directors at that meeting for
adoption by the App Area WG at IETF.
Deadline is the 19th
Then we replace the current appendix with one that just has the
font/woff2 type defined
this relates to action-172
adjourned
Summary of Action Items
[NEW] ACTION: vlad to update spec for flags, weith glyf and
loca treated specially for historical reasons [recorded in
[21]http://www.w3.org/2015/10/13-webfonts-minutes.html#action01
]
[End of minutes]
__________________________________________________________
--
Best regards,
Chris Lilley
Technical Director, W3C Interaction Domain
Received on Tuesday, 13 October 2015 19:49:02 UTC