WebFonts Working Group Teleconference -- 04 Mar 2015

<trackbot> Date: 04 March 2015

<RSheeter> in abc does c "follow" a? :D

scribenick ChrisL

<scribe> scribenick: ChrisL

open actions

action-133?

<trackbot> action-133 -- Raph Levien to Review the spec edits and finalize the definition of the "nominal size" -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/133

Vlad: we have been waiting for this for a long time

kuettel: add a drop-dead date?

Vlad: or tell implementors that nominal size is avariable they need to watch for
... kind of skeptical that nominal size can work across a range of decompression strategies

jfkthame: if we want to preserve the wire format, redefine it as original size and clarify it is informative hint on how much it may take - but no guarantee it decompresses to exactly that size

Vlad: that is what we say now, pretty sure
... total sfnt size gives that indication
... added language to say this

jfkthame: section 5.4 nominal size of a glyph, says it may not be same as source original size

Vlad: all tables have orig size and transformed ones have transformed size. So then just remove the nominal size concept

jfkthame: and then say you may not get the original size back again

Vlad: so rewrite all of 5.4

ChrisL: prefer to drop the nominal size as it is the last open issue now ttc is done

Vlad: yes we are nearly done bar a few minor adjustments. get ready for last call

close action-133

<trackbot> Closed action-133.

close action-159

<trackbot> Closed action-159.

action-126?

<trackbot> action-126 -- David Kuettel to Check publication of security review -- due 2014-01-15 -- CLOSED

<trackbot> http://www.w3.org/Fonts/WG/track/actions/126

<RSheeter> action-146?

<trackbot> action-146 -- Chris Lilley to Use ietf-w3c liaison to get review and guidance for next steps on brotli id -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/146

<kuettel> Mark Adler is making great progress on the new Brotli decoder, here is a link to the project and activity

<kuettel> https://github.com/madler/brotli/commits/master

close action-146

<trackbot> Closed action-146.

action Vlad to rewrite section 5.4 removing nominal size concept

<trackbot> Created ACTION-163 - Rewrite section 5.4 removing nominal size concept [on Vladimir Levantovsky - due 2015-03-11].

action-153?

<trackbot> action-153 -- Raph Levien to Work with vlad to clarify all uses of original length -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/153

Vlad: this is no longer relevant due to nominal size removal

close action-153

<trackbot> Closed action-153.

action-156?

<trackbot> action-156 -- Roderick Sheeter to Draft spec update for ttc support -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/156

Vlad: w3c sent a liaison to SC29, MPEG published a document of font collection issues in consequence

RSheeter: link?

<RSheeter> that was Rod :D

Vlad: will check. should go to mpeg convenor website
... will send link once doc is posted
... those of you not yet on the ad-hoc group are best to join

<Vlad> ISO AHG page: https://groups.yahoo.com/neo/groups/mpeg-OTspec/info

Vlad: current mandate is to study text of standard, verify and review wrt font collections
... will make a report to start off an ammendment
... work item is approved

action-155?

<trackbot> action-155 -- Vladimir Levantovsky to Clarify handling of checksum in a font collection -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/155

close action-155

<trackbot> Closed action-155.

Vlad: the fix here will be in the MPEG ammendment, nothing to do on our side

RSheeter: so its not clarified yet?

Vlad: right, but our spec does not need to change here

ChrisL: do ammendments take effect automatically?

Vlad: yes
... search on ISO includes any ammendments and corrigenda issued to date
... also this spec if freely available to the public
... third edition text under final ballot approval so it rolls in all ammendments on second edition

ChrisL: ok good

action-156?

<trackbot> action-156 -- Roderick Sheeter to Draft spec update for ttc support -- due 2015-01-14 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/156

Vlad: RSheeter did a great job there

close action-156

<trackbot> Closed action-156.

action-160?

<trackbot> action-160 -- Roderick Sheeter to Invite khaled to attend conference calls -- due 2015-02-04 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/160

ChrisL: all sorted now

close action-160

<trackbot> Closed action-160.

<RSheeter> Is this some sort of record for action items killed in a single call?

could well be

Vlad: grouped directory and collection together. one additional normative statement added
... rest added to 4.2, on authoring tools and user agents. not reflected in test plan yet
... feel free to help with updating test plan
... made major cange to media type registration, modified after kuettel finding that font top level type is used widely in practice
... links to google doc on mime finding

(link is broken, we need a stable one)

kuettel: happy to make a doc to put on w3c site

david if you make an html or pdf I can upt it on the w3c site

Vlad: officially defined types poorly used, intuitive but unregistered font/ tlt is widely used

<scribe> ACTION: chrisl to bring widely used top-level-type to W3C-IETF liaison [recorded in http://www.w3.org/2015/03/04-webfonts-minutes.html#action01]

<trackbot> Created ACTION-164 - Bring widely used top-level-type to w3c-ietf liaison [on Chris Lilley - due 2015-03-11].

<kuettel> FYI, the link is resolving to: http://dev.w3.org/webfonts/WOFF2/spec/goo.gl/zbDhUN With a http:// prefix, would become: http://goo.gl/zbDhUN

Vlad: security considerations section still applicable, but applies to all font top level types
... sfnt, woff and woff2 are the useful ones
... but sfnt has 2 optional parameters, tt/cff and aat/etc layout
... to be intuitive its better to hard code these, so ttf and otf which removes the outline type
... layout remains, otf is enough to say open type layout

ChrisL: (talks fast on undesirability of parameters)

Vlad: if its an aat font you can find the parameters needed
... reflecting the file extensions makes it more easy to use
... and can then specify the layout mechanism if wanted
... and for an opentype, just need to specify what outlines are used

kuettel: in favout of ttf and otf
... excellent proposal

Vlad: go ahead and finalize those sections?

ChrisL: please do

Vlad: is email contact correct? with a mail archive not a personal email?

ChrisL: yes its better as a public archive
... using www-font seems good

Vlad: ok

glyf/local

RSheeter: ref impl has put it in an alphabetical order. spec seesm to have not intended that
... so when changing it, OTS rejects the fonts as the tables are no longer alphabetical

Vlad: so OTS is also a woff decoder?

RSheeter: yes
... OTS rejects tables not in the OT spec order. so glyf, loca, hmtx
... before g, h, l ie alphabetical
... change pairs glyf and loca

Vlad: its correct per the spec
... how difficult to update OTS? Mostly we modify spec to meet impl, does not seem correct here

<jfkthame> OTS was fixed a couple of days ago, but what's in currently-shipping browsers will fail

Vlad: good reason to keep glyf and loca togather, reconstructs both tables at same time and having multiple pairs in the collection, with pointers rather than offsets, is better

RSheeter: nothing much supports collections yet. concern is what order we require for a non-collection
... practical issue is that ref impl makes a woff2 that does not work in browser

ChrisL: until new OTS is deployed

Vlad: can this be a maintenance update?

RSheeter: no it would be a future version and broken in the interim

Vlad: or could keep the ref as it used to be, update encoder after OTS is fixed - but then legacy files would fail

RSheeter: current woff files are in ots order

jfkthame: not sure legacy files would fail. if decoder accepts either OTS order or paired glyp/loca then it all works

Vlad: alphabetical did not matter before
... its quite a change in the spec
... should be able to avoid re-ordering
... put a loca placeholder

jfkthame: current text says loca must immediately follow the transformed glyph table
... and preserve physical order of tables. so we loose physical table order

Vlad: may not matter for some impls but there is a recommended table order and so should be preseved. also easier to decompress without buffering tables

ChrisL: what was the OTS fix?

jfkthame: no longer cares about incoming table sorting. now it warns and resorts to correct order
... it was an OTS bug for it to check that for WOFF2; ok for WOFF1 and sfnt
... OTS should not have been enforcing that

Vlad: woff2 has no random access intocompressed stream so that made sense to do that way
... current spec is correct and gives optimal implementation

RSheeter: except it won't work

Vlad: it wont work with OTS before the bugfix

RSheeter: risk people conclude it doesn't work

ChrisL: timescale for new OTS deployment?

jfkthame: few months

RSheeter: sounds about right

kuettel: there are two flavours of OTS?

RSheeter: old abandoned one and the maintained fork
... chrome shipping the old unmaintained one

Vlad: reluctant to glorify this bug in a spec change

RSheeter: what is the harm?

Vlad: loose physical order of tables. OT spec recommends a particular order. some impls may expect that order

RSheeter: hypothetical, or known?

Vlad: unknown
... presume the ordering was done for a reason

RSheeter: so its a hypothetical against a real one

Vlad: but the other one is a bug
... so what should we do

ChrisL: if we don't preserve the ug then chrome and firefox stop working with woff2

Vlad: monotype used the earlier code, would have to be redone
... in the long run its better to say, recompress your woff2 fonts and go clean for the future

RSheeter: actually, its telling people to redo in future and there is an interim phase as browsers updates are staggered

jfkthame: for non-collections, as long as decoder does not require loca right after glyf existing fonts continue to work.
... recompression is not rewquired
... but dont release an updated encoder until the decoder with bugfix is deployed

Vlad: like that option. legacy data can still work
... this is probably not the last time we find a need to change something.

RSheeter: current spec text has no clear advantage

Vlad: on the encoding side you drop the loca. on the decode you construct it at same time as glyph, so its logical to treat them as a pair
... loca in table in woff2 is just a placeholder to say one needs to be reconstructed
... for font collections, mismatched glyph and loca is a disaster
... using pointer to exact location, ok but with an index it will break
... so pairing as a conformance requirement on encoding and decoding is the right thing to do

RSheeter: conceeded for collections
... not clear why physical order of tables matters outside of collections

Vlad: recommended physical order has been in place for years
... its the safe thing to do, if it matters then preserve it

ChrisL: deployed encoder released or not?

jfkthame: current github is already like that
... put corrected code in a branch and not merge to head yet

ChrisL: like the idea of putting it in a branch

only real drawback is that collections don't work yet

jfkthame: nothing breaks yet

Vlad: would need quite some research to see if any impls break in the wider context of all font tools
... seems the fix is already there, just waiting for it to deploy

<jfkthame> https://github.com/khaledhosny/ots/commit/e779d45e7a96d3b97ed3d2b76db7478cb86fdd8b

ChrisL: can we track on browsers how they update to the new OTS?
... can we make a test case font that exposes the bug so it can be tracked per-browser

RSheeter: (looks for ticket moving chrome to new OTS)

<RSheeter> I think it's https://code.google.com/p/chromium/issues/detail?id=339857

action vlad to review spec for language changes to keep spirit of physical table ordering and tables in between glyf and loca

<trackbot> Created ACTION-165 - Review spec for language changes to keep spirit of physical table ordering and tables in between glyf and loca [on Vladimir Levantovsky - due 2015-03-11].

I mailed some text suggestions just before the call

<RSheeter> I liked those; seemed pretty unambiguous

(adjourned)

<RSheeter> How come I'm not an attendee?

<Vlad> Rod, you are [Google] :)

- DRAFT -

WebFonts Working Group Teleconference

04 Mar 2015

Attendees

Contents

open actions

glyf/local

Summary of Action Items

Scribe.perl diagnostic output