- From: Chris Lilley <chris@w3.org>
- Date: Wed, 4 Mar 2015 17:27:55 +0100
- To: public-webfonts-wg@w3.org
Hello Public-webfonts-wg,
http://www.w3.org/2015/03/04-webfonts-minutes.html
WebFonts Working Group Teleconference
04 Mar 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/03/04-webfonts-irc
Attendees
Present
[Google], sergeym, Vlad, ChrisL, +1.408.921.aaaa,
kuettel, jfkthame, RSheeter
Regrets
Chair
Vlad
Scribe
ChrisL
Contents
* [3]Topics
1. [4]open actions
2. [5]glyf/local
* [6]Summary of Action Items
__________________________________________________________
<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> [7]http://www.w3.org/Fonts/WG/track/actions/133
[7] 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> [8]http://www.w3.org/Fonts/WG/track/actions/126
[8] 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> [9]http://www.w3.org/Fonts/WG/track/actions/146
[9] 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> [10]https://github.com/madler/brotli/commits/master
[10] 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> [11]http://www.w3.org/Fonts/WG/track/actions/153
[11] 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> [12]http://www.w3.org/Fonts/WG/track/actions/156
[12] 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:
[13]https://groups.yahoo.com/neo/groups/mpeg-OTspec/info
[13] 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> [14]http://www.w3.org/Fonts/WG/track/actions/155
[14] 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> [15]http://www.w3.org/Fonts/WG/track/actions/156
[15] 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> [16]http://www.w3.org/Fonts/WG/track/actions/160
[16] 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
[17]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:
[18]http://dev.w3.org/webfonts/WOFF2/spec/goo.gl/zbDhUN With a
http:// prefix, would become: [19]http://goo.gl/zbDhUN
[18] http://dev.w3.org/webfonts/WOFF2/spec/goo.gl/zbDhUN
[19] 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>
[20]https://github.com/khaledhosny/ots/commit/e779d45e7a96d3b97
ed3d2b76db7478cb86fdd8b
[20] 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
[21]https://code.google.com/p/chromium/issues/detail?id=339857
[21] 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] :)
Summary of Action Items
[NEW] ACTION: Vlad to rewrite section 5.4 removing nominal
size concept
[NEW] ACTION: chrisl to bring widely used top-level-type to
W3C-IETF liaison [recorded in
[22]http://www.w3.org/2015/03/04-webfonts-minutes.html#action01
]
[End of minutes]
__________________________________________________________
--
Best regards,
Chris Lilley, Technical Director, W3C Interaction Domain
Received on Wednesday, 4 March 2015 16:28:07 UTC