W3C

- DRAFT -

WebFonts Working Group Teleconference

19 Feb 2014

See also: IRC log

Attendees

Present
+1.425.882.aaaa, cslye, Vlad, +1.510.717.aabb, raph, sergeym, JonhHudson
Regrets
Chair
SV_MEETING_CHAIR
Scribe
kuettel

Contents


<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

TTC support

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!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/02/19 16:13:12 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]