- From: Chris Lilley <chris@w3.org>
- Date: Wed, 27 May 2015 17:17:45 +0200
- To: WebFonts WG <public-webfonts-wg@w3.org>
Hello WebFonts,
http://www.w3.org/Fonts/WG/2015-05-27-webfonts-minutes.html
and below as text for trackbot
WebFonts Working Group Teleconference
27 May 2015
See also: [2]IRC log
[2] http://www.w3.org/Fonts/WG/2015-05-27-webfonts.txt
Attendees
Present
jfkthame, KenLundeAdobe, kuettel, RSheeter, vlad,
ChrisL, sergeym
Regrets
Chair
Vlad
Scribe
ChrisL
Contents
* [3]Topics
1. [4]open action items
2. [5]f2f
* [6]Summary of Action Items
__________________________________________________________
trackbot, start telcon
<trackbot> Date: 27 May 2015
oh zakim, get your act together
<RSheeter> I want to believe that's a command
IA_Fonts()10:00AM
Started at 13:55Z and now has 3 participants:
[7]https://www.w3.org/1998/12/bridge/Zakim.html
[7] https://www.w3.org/1998/12/bridge/Zakim.html
ok the dialing works, zakim bot has incorrect info
zakim bot appears not to be reading the call info correctly
<scribe> scribenick: ChrisL
Vlad: one pending review item. behedad said lgtm
[8]http://www.w3.org/Fonts/WG/track/actions/pendingreview
[8] http://www.w3.org/Fonts/WG/track/actions/pendingreview
close action-175
<trackbot> Closed action-175.
KenLundeAdobe: when discarding redundant data in cff, when it
is reconstructed is it restored or discarded
Vlad: currently silent on cff processing
KenLundeAdobe: yes but in the proposal
... adobe apps prefer the data in the cff
Vlad: we don't remove anything. behedad says redundant data
could be removed, why keep it in 2 places. its a question to
the group and we have not discussed
KenLundeAdobe: pointing out that adobe apps prefer cff metrics
ove hmtx etc if they differ
Vlad: opentype spec says a different thing
ChrisL: would be good to know what adobe apps do there if the
cff dupes are removed
KenLundeAdobe: textedit on osx prefers the hmtx if they differ
... our tools may reject building such a font
Vlad: that would be useful info to know
... point was that it makes the font smaller
... no mandate to desubroutinise
open action items
[9]http://www.w3.org/Fonts/WG/track/actions/open
[9] http://www.w3.org/Fonts/WG/track/actions/open
RSheeter: cosimo tried that (??that) do we need more data
action-116?
<trackbot> action-116 -- David Kuettel to Decoder performance
analysis on mobile devices -- due 2015-06-30 -- OPEN
<trackbot> [10]http://www.w3.org/Fonts/WG/track/actions/116
[10] http://www.w3.org/Fonts/WG/track/actions/116
kuettel: compression team are woring on improvement on
decompression speed, with get to a chrome release; once it gets
to stable we have new numbers. that will take time.
... so we could close it and make a new action for round 2
Vlad: or bump due date to october
kuettel: ok
action-168?
<trackbot> action-168 -- Roderick Sheeter to Measure RAM usage
for woff2 vs. woff1 -- due 2015-05-13 -- OPEN
<trackbot> [11]http://www.w3.org/Fonts/WG/track/actions/168
[11] http://www.w3.org/Fonts/WG/track/actions/168
RSheeter: nope
action-171?
<trackbot> action-171 -- Vladimir Levantovsky to Review
conformance reqs to ensure they can actually be implemented --
due 2015-05-06 -- OPEN
<trackbot> [12]http://www.w3.org/Fonts/WG/track/actions/171
[12] http://www.w3.org/Fonts/WG/track/actions/171
vl this is an all-group assinment. everyone should look at the
spec to check this. before f2f if poss
scribe: found one or two, will need to deal with at f2f
action-174?
<trackbot> action-174 -- Chris Lilley to Ask webappsec to
review woff2 -- due 2015-04-29 -- OPEN
<trackbot> [13]http://www.w3.org/Fonts/WG/track/actions/174
[13] http://www.w3.org/Fonts/WG/track/actions/174
ChrisL: asked at tpac, could give them a deadline
action-176?
<trackbot> action-176 -- Roderick Sheeter to Test hmtx
transformation over google fonts corpus (how many lsb == x-min
for all glyfs, what savings) -- due 2015-05-27 -- OPEN
<trackbot> [14]http://www.w3.org/Fonts/WG/track/actions/176
[14] http://www.w3.org/Fonts/WG/track/actions/176
Vlad: preliminary tests show not much benefit, confirms earlier
analysis on MTX vs woff2 preprocessing
... it doesn't buy much in term of compression gains
... unless you have additional info lets decide now - drop or
pursue?
KenLundeAdobe: leave it alone is safest
Vlad: jfkthame you acked considering this, any ideas?
jfkthame: dont feel strongly one way or the other. its a very
simple transform to deal with on decoder side and gets 1% which
is worthwhile
... so really we should do it
... but ok either way with group decision
Vlad: Cosimo seemed to say we reduce the data size into brotli
but loose some entropy efficiency
... so not a 1% gain overall
jfkthame: (checks)
Vlad: avg saving 548 bytes on the corpus.
jfkthame: and avg font size?
Vlad: avg glyphs was 700. so less than a byte per glyph saved
jfkthame: link to data?
<Vlad>
[15]http://lists.w3.org/Archives/Public/public-webfonts-wg/2015
May/0028.html
[15] http://lists.w3.org/Archives/Public/public-webfonts-wg/2015May/0028.html
Vlad: we can defer decision if we want to research more
RSheeter: if we are really saving 1% we should do it
jfkthame: it is indeed 1% looking at mean filezize
ChrisL: agree we should keep looking at it if 1% and if
reconstruction is easy
Vlad: bigger question is spec extensibility
<KenLundeAdobe> As long as the decoding restores the removed
'hmtx' data, I have no objection.
Vlad: we identified a set of transforms it makes sense to keep.
insteead of a flag for transformed tables, decision was to
reserve the fla for something else
<KenLundeAdobe> (I am about to take my daughter to school, but
will stay connected as I should be back in 10 to 15 minutes.)
Vlad: now we see no need for reserved flags but a clear ne to
make the spec extensible if we find another preprocess
transform
... including possible future releases of the spec
... unfortunate at this point but can still do
... does not affect wire format, would affect implementations
... do we do a bit more now to make the spec extensible?
... um, silence?
jfkthame: we should intruduce a table transform flag, ignored
for loca and glyf
... used for hmtx
ChrisL: a one bit flag only lets us do this once
Vlad: we would have to change the spec and update
implementations. existing fonts still be compliant
RSheeter: what happens when i get a better hmtx transform. one
bit is not enough
ChrisL: this is what version numbers are for, not single bits
with flag we can extend it. once
ChrisL: dont follow how it helps more than once
Vlad: suppose we use it for hmtx processing
... later we have a new idea
<scribe> ... new spec defines that. flag on cff will now be set
ChrisL: ok its one flag *per table* i get it now
RSheeter: but we get to extend each table exactly once
Vlad: agreed
... we could have been smarter. likelihood is less than that we
find something for anew table
... glyf and loca are always preprocessed so that is a
consequence of the late spec change. impls will do this anyway
... for any other table, flag bits will show the optional
transform
ChrisL: current impls will do what with it?
jfkthame: if its reserved we should check if its zero
ChrisL: yes, clearly
... otherwise it can't be relied on
jfkthame: says reserved, does not say must be zero
Vlad: if we reserve bits 6 and 7 then we must check they are
zero. if we use one as a transform flag then both values are
allowed
<KenLundeAdobe> (I'm back)
RSheeter: think we should have an extensibility mechanism,
concerned about only once
jfkthame: propose using 2 bits for a 4 value version number
... on a per table basis
ChrisL: feel more comfortable with 4 values rather than 2
jfkthame: we only need a few bits so this gives us a coule of
chances per table to improve things
ChrisL: i like jfkthame's proposal
Vlad: we could, yes, use it like that to define over time.
wondering if theyre is anything else we would want to flag
RSheeter: worse comes to worse we can say that v2 is like v1
plus an extra thing
Vlad: ok sleep on it and follow up in email
... jfkthame please send a message for benefit of others not on
the call
action jfkthame to propose two-bit per table version number
<trackbot> Created ACTION-177 - Propose two-bit per table
version number [on Jonathan Kew - due 2015-06-03].
kuttel; we want to factor in dropping fonts into this
versioning discussion
Vlad: if unknown transform is found on a table, temporarily it
will cause older decoders to drop the font so we would not do
lihtly and is not a long term problem
... must spell out what to do with unknown transformed tables
... ok that was a good discussion which we should continue on
the list
... agenda items concluded. eob?
f2f
Vlad: we have conf room for the full two days
... want to be 100% set on conformance test suite definition ie
for each test, what is needed to implement it
so test plan is final
scribe: aside from tht, additional agenda items welcome. good
point for final decision on extensibility and versions
kuttel: sounds good to me.
RSheeter: we are at about 55% test coverage now
kuettel: of the ones defined so far
RSheeter: yes
kuttel: so would like to see us focuss on the ones undefined,
can go faster on the existing ones
Vlad: quite a few new requirements, need to check there are
none missing and some are placeholders
kuttel: important to have khaled comment on ease of
implementation on the new ones
Vlad: yes
... but first check the requirements are reasonable. we
eliminated one unreasonable one
... organising a social for tues night. any dietary
restrictions?
kuuttel: yes, steak only
... (grins)
jfkthame: suitable for emailing to the rest of us
Vlad: we will email you pictures
adjourned
rrsagent where are you!!
Vlad: remote participants welcome
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [16]scribe.perl version
1.139 ([17]CVS log)
$Date: 2015/05/27 15:11:47 $
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
--
Best regards,
Chris Lilley
Technical Director, W3C Interaction Domain
Received on Wednesday, 27 May 2015 15:17:48 UTC