See also: IRC log
<trackbot> Date: 19 February 2014
<jfkthame> hi guys - sorry, i'm not able to call in today, but will lurk on irc to see any notes
Vlad: will postpone Brotli / IETF
RFC discussions, as Chris Lilley is not able to join
... big topic of discussion today: TTC support (or not)
... no new information from Adobe just yet
... Ken Lundy(sp?) historically was eager to see support for
TTC which contained both CFF and TTF
<raph> Ken Lunde
Vlad: TTC collections can be
beneficial for CJK
... not sure (need more info) if benefits of TTC on the desktop
would carry over to the web -- esp. as not being used with web
fonts to date
Raph: what would changes to the
format look like? TTC has notion of table directories
... multiple table directories, with each directory having same
structure (offset + length)
... some tables would be unique to the font, some shared across
fonts within the TTC
... one use case: complex scripts (multiple styles)
... glyph table is unique, but OpenType (esp. GSUB) is
shared
... as the shaping logic would be the same for bold or
italic
... one script where there could be a significant improvement
is Devanagari
<Vlad> scribenick: kuettel
Raph: however fonts that he
looked at did not follow this pattern -- would need to be
reworked
... gain in other cases is minor (few percent at best after
rework)
... thus, not an extremely compelling case for TTC support in
WOFF 2.0
... esp. given that the web page might only use some of the
styles, yet have to pay the transfer cost of all
... for CJK -- aware of Han unification using TTC
... e.g. font that covers many CJK languages
... in this case the glyph table is shared (union of the Han
unification), however other tables would be different (e.g.
cmap)
... next, device fonts
... could make a strong case, as device needs to support the
worlds languages
... combined font could be smaller
... that said, in a web context this makes a lot less
sense
... esp. as a frequent pattern on the web is to serve the most
optimized font for a given user agent
... where here, serving a specific Han language would be a
bigger win over serving the combined Han TTC
... thus, target would be a web page with multiple Han
languages, which just isn't that likely
... rather the common case would be a single Han language
... OpenType variant mechanism, is likely a more modern way of
accomplishing the same thing
... OpenType is backwards compatible, unlike TTC
... another use case that was proposed on the mailing
list
... (missed a bit). web has a great fallback mechanism that
allows fonts to be mixed
... other web font features, such as unicode-range enable even
greater optimizations over TTC
... thus, seeing few benefits of TTC support
Vlad: another use case that came
up recently, Japanese family of fonts + Latin.
... could combine all four fonts in to one TTC, which would be
handy for device fonts or distribution
... but not sure how compelling that would be for the web
Raph: more likely that for web
fonts the font would be split up, would combine with
font-family + unicode-range as needed
... huge file sizes put more pressure to subset, which makes
the use case for TTC less compelling
... how much complexity would TTC add?
... cost is non-trivial. wire format has a strong stream
processing flavor (process and then forget), where more
complicated structure with multiple references would require
more complex logic
... would likely involve significant changes for the client.
security would likely be another big factor (more work to
harden, more risks, etc)
... the open type sanitizer is pretty rigorous today, would
need to be reworked
... not impossible, but definitely not trivial
... would really need to go back and rethink the security
implications
... without a significant improvement, hard to justify
Vlad: for completeness, where would table overlap occur?
Raph: no, rather multiple
references to byte ranges (didn't capture everything)
... if only extracting a single font (from the TTC), likely
easier, but would need to skip
... extracting multiple fonts is more involved, which is what
one would want to do in the web case (otherwise, why return a
collection)
... implementation would likely have the option of returning
multiple fonts or a container
Vlad: to summarize, Raph made a detailed and compelling case for not supporting TTCs on the web
John Hudson: TTC has been a historical part of the sfnt structure. However as Raph noted, there are other (better) ways of doing the same on the web
John: have agreed with Jonathan
where we should look at how it would be used, just want to make
sure that we don't miss something
... esp. given that some have been eager to see further TTC
support (e.g. Adobe with CFF)
Raph: would love to hear from
Adobe
... we should gather their input prior to making a decision
Vlad: Sergey, thoughts?
Sergey: for Microsoft, having
seeing savings for CJK (on desktop), but don't see the savings
carrying over to web fonts (esp. given the other mechanisms).
Not sure about web apps
... thus, feel that it is not that important
... would be more work to support (esp. given existing MTX code
base)
... thus eager to hear from more foundries, to understand their
needs for TTC
Vlad: anyone else? Chris?
... (wearing Monotype hat): reached out internally to find a
compelling case, but was not able to. In the larger scope (e.g.
epubs), there could be compelling use cases
... balance might change for epubs, where many fonts could be
bundled with the book
Sergey: would that be the perfect case for subsetting?
Vlad: yes, but book would likely
pull in most of the font anyways
... that was the only likely compelling use case that I
found
... also share the desire to see TTC supported, due to the
OpenType spec -- want to carry it over
... from the implementation point of view, single stream
compression could make it easier (than otherwise)
... think that WOFF 2.0 is in a better position to support TTC
over WOFF 1.0
Raph: not just a matter of compression, rather there are also the table transforms that would complicate things
Vlad: agree
Raph: definitely not trival
... e.g. length of data after Brotli compression and
transforms
... I guess you could do it
... would likely involve multiple passes over the data
... definitely a multi-step process, would require detecting
regions in Brotli streams.... enough work to trigger more
security reviews, etc
Vlad: additional processing steps
not in conflict with single stream compression
... agree that it would be more work, not a departure from what
we have today from a compression point of view
... summarizing again
... have not heard a really compelling use case just yet
... mildly compelling use case for epubs (or weak case)
... believe that if we do decide to support TTC, additional
complexity would be marginal (could have been a lot more
complex with per-table compression)
... another weak case, TTC being part of the OpenType spec,
thus a nice to have, esp. in case we missed something looking
forward
David: another potential use case that has been brought up over the past few months is color fonts
Vlad: not seeing this as any different from others
Sergey: what tables would be shared? eager to learn more
Vlad: with color fonts, would
have shared glyph table
... from a compression point of view, not seeing a big
difference
Raph: sounds right
Vlad: to recap, great discussion
today
... continue active discussions on the mailing list
<jfkthame> and great note-taking ... thanks David!
thank you! :)
Vlad: thank you for starting the
editor's draft of the specification Raph
... once draft is somewhat complete, will take a pass over
it
Raph: hoping to share something soon
Thank you everyone!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: kuettel Inferring Scribes: kuettel Default Present: +1.425.882.aaaa, cslye, Vlad, +1.510.717.aabb, raph, sergeym, JonhHudson Present: +1.425.882.aaaa cslye Vlad +1.510.717.aabb raph sergeym JonhHudson WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 19 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/19-webfonts-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]