W3C

- DRAFT -

WebFonts Working Group Teleconference

13 Oct 2015

See also: IRC log

Attendees

Present
Vlad, Chris, Behedad, Garret, Rod, David, Nashan, Raph, sergeym, (Zurich, Team), jfkthame, Zoltan, Jyrki, Evegenii
Regrets
Chair
Vlad
Scribe
ChrisL

Contents


<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

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> 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

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> 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

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

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 http://www.w3.org/2015/10/13-webfonts-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/13 19:45:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]