See also: IRC log
<trackbot> Date: 13 October 2015
<scribe> Scribe: ChrisL
(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
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>
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> 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 http://dev.w3.org/webfonts/WOFF2/spec/ at least work?
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 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
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
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> 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].
https://www.w3.org/Fonts/WG/wiki/Main_Page#WOFF_2.0_Test_Suite
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
https://www.w3.org/Fonts/WG/wiki/TestPlan20-Decoder#mustLoadFontCollection
https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustCheckLSBFlags
https://www.w3.org/Fonts/WG/wiki/TestPlan20-AuthoringTool#mustEliminateLSBs
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/LSB/lSB/g Found Scribe: ChrisL Inferring ScribeNick: ChrisL Present: Vlad Chris Behedad Garret Rod David Nashan Raph sergeym (Zurich Team) jfkthame Zoltan Jyrki Evegenii Found Date: 13 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/13-webfonts-minutes.html People with action items: vlad[End of scribe.perl diagnostic output]