- From: Chris Lilley <chris@w3.org>
- Date: Wed, 16 Apr 2014 17:12:39 +0200
- To: WebFonts WG <public-webfonts-wg@w3.org>
Hello,
Te mnutes of today's call are at
http://www.w3.org/2014/04/16-webfonts-minutes.html
and below as text for bots.
WebFonts Working Group Teleconference
16 Apr 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/04/16-webfonts-irc
Attendees
Present
+1.408.921.aaaa, Vlad, +1.510.717.aabb, ChrisL, raph
Regrets
Chair
vlad
Scribe
ChrisL
Contents
* [3]Topics
1. [4]known table tags
2. [5]fpwd and outreach
* [6]Summary of Action Items
__________________________________________________________
<trackbot> Date: 16 April 2014
<scribe> scribenick: ChrisL
Vlad: we spent a lot of time to make state of the art font
compression and to prove it
... serving millions of fonts to billions of users, big savings
... moderately complex code with a lot of benefits
... can have two function calls, one for woff2 and one for
generic brotli
kuettel: jkew's point is a good one, more tools could support
woff2
... whether that is enough to make it optional is a separate
discussion but see his point
... trade off between fewer tools and better overall
compression. low impact on high volume sites, more for
specialized cases
Vlad: everything can be brotli compressed, but that is only
part of woff2. similar to jpeg compression for images
... agree brotli has widespread use, but we want to benefit
from the work we did for two years, it helps users
kuettel: all good points
Vlad: complexity of preprocessing - can be implemented in any
language. only time will tell on the uptake
... only one person writes a library, gets used by everyone
... MonoType tools all written in Python and shared for
servers, desktop etc
... wish jkew was on the call
ChrisL: jkew did say he was fine to move on if the group agrees
kuettel: would like to see us make a decision
raph: coming down to tradeoff between spec simplicity/few
options/easy testability vs ease of simple tools
ChrisL: the simple easy script could use woff1
raph: implementing brotli from scratch in a scripting language
would have poor performance, over time there will be callouts
to native libraries as with gzip
... deployment time
Vlad: main consideration is effect on users, don't want to see
them download more data than was needed
... code written once, deployed many times and data downloaded
billions of times
raph: so point is that we don't want substandard tools deployed
Vlad: priority of constituencies
... on mobile with low cpu, also metered bandwidth so best to
have small data
... do we agree to make preprocessing step mandatory and
eliminate options
(agreement)
resolved: no optional parts in woff preprocessing
raph: good discussion, an informed decision
<kuettel> Actually that was Raph, but I agree :)
<kuettel> Known table tag proposal:
[7]https://docs.google.com/a/google.com/spreadsheets/d/111MT0l7
LOVqotAnMXD4PMOm36jTPSznUigJPfxUYY_0/edit#gid=0
[7] https://docs.google.com/a/google.com/spreadsheets/d/111MT0l7LOVqotAnMXD4PMOm36jTPSznUigJPfxUYY_0/edit#gid=0
known table tags
Vlad: thanks for the detailed analysis
... tables in limbo for a long time or not frequently used need
not be listed
... will not loose data or affect function, just a few more
bytes
raph: 4 more
ChrisL: for new stuff (as opposed to old no longer used stuff)
usage will increase over time
Vlad: some tables fell out of favour
... if widely deployed, its in. if its niche use case, can
still be used
... need a policy for this, explain the choice
kuettel: caveat, limited corpus, mostly google fonts and
foundry search integration. no cff fonts
... we could get more data
raph: happy with list as it stands, behedad said its fine and
not to agonize over it.
... we can leave light green tags in
... these are things we see in real fonts. low wastefulness
... cost of missing a tag is trivial, number of fonts with
missed tags is tiny except for future standardization
... need language for the rationale but suggest we accept this
proposal
Vlad: agree
... we used 7 bits for tag code?
raph: yes, up to 7 available
Vlad: so 46 used out of 128
... include everything we know today, sill plenty room for
later standardization
... even if the number doubles we can still include everything
kuettel: second tab has a lot more tables. fontlab has tons of
them
Vlad: john hudson said font dev tools use that extensibiity for
source tables. occasionally these slip through. we don't want
to include those ones
... should never be in a final font that is an actual product
raph: spec has a guidance role. do not encourage people to ship
fonts with that stuff
Vlad: publised specifications is the cut
... opentype/off, aat, graphite
... any tables in shipped fon, not the source ones
kuettel: (true type accent table, scribe missed)
raph: vtt tables not included
... but include aat ones as they are a public spec
... so its all in the first sheet plus the aat ones?
kuettel: in the second tab the non standard ones are struck out
ChrisL: we should aleways drop dsig in woff2
kuettel: not seeing many of the older truetype tables
... then graphite, a mix, rows 66 to 70 are documented but
others are not
... are we planning for any sil table?
... then EPAR; after that random ones
Vlad: the crossed out ones should be disallowed. also EPAR
proposal, not current
... no tools read it
... if a font does use it it is still preserved
kuettel: rows 45 to 64 are the older truetype tables
raph: there are published aat fonts although low use, not in
corpus, some still around though
kuettel: row 76, SIL Silt is not in the spec
... not an expert on that
[8]http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=
typetuner
[8] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=typetuner
raph: Silt is present in the fonts but is tool specific, not
aimed at end consumer, so we should not include it. should be
stripped
Vlad: we need a few paragraphs to inform implementors that tool
specific tables should be removed before woff2 encoding
... as we did for woff1
... separate para for DSIG to explain why its dropped, because
woff2 processing invaliudates it
ChrisL: this tablular data should go in the evaluation report
kuettel: good to briefly talk about ordering
start with the microsoft OT tables, 29-30, then list in order
of specification date, apple tt tables next, math, graphite,
then colorfonts
Vlad: math and color are part of OFF v3
... preferto mention the ISO specs first
kuettel: so move math table up
Vlad: math and all the color ones
ChrisL: what about sbix, should include but no spec
Vlad: we can say its part of aat
kuettel: so move math up to 35 then sbix down to other aat ones
Vlad: makes sense
kuettel: row 51 the arbitrary tag follows
raph: needed for future expansion
kuettel: reserved ones?
Vlad: about half is left
... reserved for future use
... 29..31 willbe taken by identified tags unless some reason
to keep the literal 31 value
raph: no its a legacy from 5 bits, arbitrary was last one
Vlad: so the arbitrary is 127
kuettel: can make a third tab with the fewer plus aat and
reordering
fpwd and outreach
Vlad: spoke with PLH who mentioned AC meeting in June, team
busy getting ready for it, limited resources for fpwd and
outreach before meeting, much more resouce from Comm team after
the meeting
... so mid June
... one considerastion if we want to have a press release and
so on
raph: preference to do FPWD first and not block on publicity
... progress on solid spec is more important
Vlad: agree, just wondering because FPWD of Woff1 had a lot of
PR, lots of attention
... produced a lot of feedback
kuettel: prefer to make available sooner, other ways to get
more eyes on it. tweet about it etc
... there was a lot of controversy on webfonts before while now
its accepted
... so we get technical review soon
Vlad: twitter and blogs has a lot more weight than official PR
ChrisL: also would prefer early publication
Vlad: so, with the approved edits, all agreed for FPWD of Woff2
(explanation of process)
RESOLUTION: Publish FPWD of WOFF2
Summary of Action Items
[End of minutes]
--
Best regards,
Chris mailto:chris@w3.org
Received on Wednesday, 16 April 2014 15:12:42 UTC