WebFonts Working Group Teleconference -- 22 Aug 2013

<trackbot> Date: 22 August 2013

introductions and demos

<Vlad> David K. is presenting the Chrome Canari demo with woff2 enabled

<Vlad> Participants: David Kuettel, Raph Levien., Fil Zimbowicz., Kenji Baheux (all from Google), Jonathan Kew. (Mozilla), Vlad Levantovsky., John Giannopoulos, Joe Vierra (all from Monotype), John Hudson (Tiro Typeworks), Sergei Malkin, Simon Daniels (all from Microsoft)

<Vlad> Adam Twardoch (FontLab)

<Vlad> Observer: Denis Jacqueyre (Dalton Maag)

<Vlad> Fil Z. - presenting his slides on the developments related to LZMA and problems that were encountered along the way that lead to reconsidering the choice of compression options

<Vlad> Action, Fil to distribute the slides to the WG

<Vlad> Google - proposal to replace LZMA with modified, large-window "flate" implementation. Google compression team is working on the implementation of the proposal

<Vlad> Discussing NewFlate option - file size gains, decompression speeds, possibility of multi-threading

<Vlad> Kenji - speaking about the work Chrome team has done and is in the process of doing to swap LZMA with NewFlate

<Vlad> Discussion of the most approriate way to introduce the new compression spec, whether it should be a standalone document what should be the home for it

<Vlad> 10 min break

Decompression speed should be a requirement

Raph: should have "most important requirements" and the rest should be "best practices

Joe or Adam (myfonts): compression and decompression should be seen differently;

Raph: compression ratio and decompression speed

Chris: (explaining deployment example)
... already there, nothing to invent.
... Candidate A (microtype + LZMA) (needs to reflect existing summary, will put data in appendix)

<FilZembowicz> Raph: Kern tables should always be replaced in favor of gpos since no consumer can consume kern and not gpos

(general agreement that kern tables are not useful)

Raph: (data should call out whether or not kern tables were included since they are super easy to compress)

round tripability relevancy?

Raph: (not relevant)

worth flagging as a non requirement

<Raph> WOFF2 is "effectively lossless" where WOFF1 preserved binary roundtrip

<Raph> not trivial to specify

discussion about idempotency

<AdamTwardoch> WOFF 1 was "binary roundtippable", WOFF 2 is "effective losslesness" [Raph]. WOFF 2 would not preserve identical bytes but it would preserve the "functional" identicality

had this discussion a while ago

<Raph> should we define a canonical form? it's possible but not necessarily easy, and not necessary to make the format work

and agreed that as long as functionality is preserved this is fine

<Raph> this is already acknowledged in a bit in the OpenType header (font has been preprocessed). This bit is set in MicroType Express processing

should we then use that flag?

<Raph> vlad proposes yes

Vlad: would say yes. (harmless)

data should be in the report (Appendix) not in a separate spreadsheet

<Raph> evaluation report is non-normative, will be published as WG note

<Raph> Chris will continue updating the document

"Preprocessing based on Microtype express"

<Raph> preprocessing step is based on MicroType Express

or something similar ought to be used

<Raph> MicroType Express has been published as a W3C submission

<AdamTwardoch> MicroType® Express (MTX) Font Format : http://www.w3.org/Submission/MTX/

<Raph> another step: preparing CTS (conformance test suite) for compression algorithm

<Raph> shouldn't necessarily be done by Google, this is work of the group

Vlad: (calling for commitment from other "implementers" (e.g. Microsoft, Mozilla))
... (security reviews, conformance test suites...)

(in terms of standardization we would need at least 2 independent implementations)

Vlad: (at least an acknowledgment would be welcomed)
... (should we schedule our next F2F earlier given the tentative timeline shared earlier)

October, amsterdam (next opportunity?)

Raph: (agree that this meeting is a good opportunity)

"Atypl Amsterdam"

<Raph> http://www.atypi.org/atypi-amsterdam-2013

Vlad: (this time around the proposal is not a blackbox and comes from an existing algo)

<Raph> 9–13 October 2013

Daniel: (will try to do its best)

David: (the new plan is in response to concerns from other browser vendors: security concerns... let's take an existing well specified algo and tweak it to fit our use case)
... (asking about the state of Brotli in terms of spec)

Raph: (understanding is that there is yet to be release document; so coming)

need a public document to start the discussion

John: (agreeing that document comes first to get involvement from Mozilla. We might end up using the code from Google so this would not be an independent implementation; But expect that Microsoft would work on one)

Vlad: (drawing parallels with microtype: Flate is a known entity, the proposal is just making adjustments to it)

Raph: (should be able to get documentation out early)

<Raph> should send documents and related materials to mailing list - this makes the material public

(interested parties confirmed that at least one person would be able to join the discussion in Amsterdam)

(discussion about Spec editor)

Raph: (unfortunately, unlikely to be a full time editor this time around)
... (we will make it happen one way or another; follow up offline)

---

<AdamTwardoch> Raph talks bout MTX-inspired Preprocessing

Raph: (some tables are not included: kern, mdmx(? since it can be reconstructed nowadays))

<AdamTwardoch> "hdmx"

Raph: (glyph wise; very similar to existing approach; only difference: handling of the different aspects [e.g. hint, ...])

<AdamTwardoch> Raph: Decided to do dplitting the "flavors of data" (bboxes, coordinates, hints) into spearate streams

Raph: (additional 2-3% if we were to go after the open ? table )

<FilZembowicz> "OpenType"

(open type table?)

<FilZembowicz> Note: a lot of gains are made from data locality (eg, all bounding box together, rather than per glyph)

Raph: (explaining the worst case scenario for gzip)
... (not much gain from gplus gsub)
... (glyph => unicode and representing delta is about 1% gain; needs to be discussed since this is somewhat complex)

Adam: (should we go for even more aggressive optimizations)

<FilZembowicz> Eg, Class-based kerning: designers doing compression by hand

(in open type tables for instance)

<joe_vieira> "Compact representation by hand"

Raph: (lots of scope for tools to optimize)

Adam: cubic to quadratic is one

Raph: (however, these are out of scope for this group and does not need to be captured in the spec)

=> preprocessing

Adam: (would be nice to share these observations)

Raph: (yes, this would be in scope for a Best practices document)
... the question is then is such a document in scope for the w3c or not

Vlad: interesting question indeed but considering this out of scope for the now. Because specifying everything to the last nail does not leave room for differentiation.
... and innovation.

Adam: (observing that this WG is a forum for web browser vendors = clients and font vendors = providers to talk together.)
... (not sharing the additional observations might give an unfair advantage to some)

Vlad: (not our job to teach other how to innovate)

Chris: (giving an example of how we could share the data without stifling innovation)

Joe: "this tool function best if those are the input" makes sense. Not the only way but the ideal way

Raph: (talking about which tables we drop and which we don't)

Chris: maybe those are not best practices but design decisions

<Raph> Chris: these are design assumptions used to drive the design

<Raph> chris: we need to document why we made that decision

<FilZembowicz> (dropping kern table in particular)

Daniel: (pointing out that web or non web would lead to different choices)

Vlad: (agreed that the specification should give the background on those decisions)

(pointing out that the font preprocessing part does have an impact on the end goal of getting fast typography on the web. => font vendors will need information from browser vendors: is it safe or not, useful or not)

(Above was from the gentleman sitting next to Vlad)

<Raph> John Hudson, Tiro Typeworks

Vlad (as the chair): currently this is out of scope but if we wanted to make this part of the scope we would need to change the charter.

Chris: (explaining the advisor committee's role regarding charters)

Joe: (question about the current charter: 2009 charter?) Chris: (2012 but the page is still behind so needs to update it)

<ChrisL> current charter http://www.w3.org/2012/06/WebFonts/charter-2012.html

After lunch: discussing Adam's proposal on the agenda, also per table vs per font compression discussion

per table vs per font compression

<FilZembowicz> Vlad: How important is per-table compression?

<FilZembowicz> There aren't plans for UAs requesting individual tables

<FilZembowicz> Jonathan: use cases were 1) potentially with a large font, could request metrics before the font to do layout

<FilZembowicz> 2) selective decompression -- downloaded the entire font, but only need to decompress the tables that a UA actually can handle

<FilZembowicz> Adam: 3) Assumption that certain tables might not benefit from compression

<FilZembowicz> If you have a relatively small table, there might not be a benefit

<FilZembowicz> With LZMA, decompression there was some setup time per table

<FilZembowicz> With Brotli, perhaps this is less important

<FilZembowicz> Vlad: don't want to have anything in the spec without justifying it

<FilZembowicz> Jonathan: need to see new data. Aim would be to come up with a single specficiation, unless there is a compelling reason to support both per-table and per-font

<FilZembowicz> Good agenda item for having by ATypi

s/Atypi/Atypl/

<FilZembowicz> Raph: seen with Woff1, the woff1 will be smaller than the gzip. Partitioning the data helps gzip

<FilZembowicz> Raph: Expectation that brotli, with exhaustive search, would work better on whole files

<FilZembowicz> Jonathan: another reason for per-table -- can't easily feed back to an uncompressor

<FilZembowicz> Not secure, but obscure

<FilZembowicz> A potential benefit of per-table is decompressing in parallel -- although Raph notes that in general one table dominates

<FilZembowicz> Are there optimizations in terms of table order?

<FilZembowicz> Raph: sounds almost like pre-preprocessing we talked about earlier

<FilZembowicz> Not really relevant in per-table compression, wouldn't have an effect. In older windows platforms this had an effect due to page misses

mime types

<FilZembowicz> One of the reasons to not register a top-level mime type: perception that it's an uphill battle

<FilZembowicz> But it seems that this is easier today

<FilZembowicz> David Kuettel shows a presentation

<FilZembowicz> Proposal: top level MIME Media Type for fonts registered through the IANA

<FilZembowicz> font/* ... analogous to text/* and image/*

<FilZembowicz> Problem: today mime types are all over the place, application/* is a dumping ground

<FilZembowicz> Fun fact: people guessed that woff was "x-font-woff" and this was picked up in wikipedia

<FilZembowicz> Vague ones too: application/octet-stream used for ttf, otf

<FilZembowicz> Who does this affect? Web font hosts

<Raph> historically, there was application/font-tdpfr (TrueDoc Portable Font Resource). This was the inspiration behind the application/font-X pattern

<Raph> (Chris pointed this out)

<Raph> Vlad points out that there is also now an application/font-sfnt, with parameters indicating outline format (cubic vs quadratic) and layout (see http://www.iana.org/assignments/media-types/application/font-sfnt)

<FilZembowicz> What happens when there is an incorrect mime type? Historically, guessing, but today there is more just throwing error/warnings

<FilZembowicz> In CSS, you specify the format, so browsers ignore the mime type that is sent

<ChrisL> css already has the format so the browser knows what it is expecting when it dereferences the url

<FilZembowicz> Drawbacks: everyone (web hosts) sets them differently, resulting in errors

<FilZembowicz> What is the advantage of a high level mimetype? David: more intuitive

<FilZembowicz> In Chrome inspector, can filter network requests by just fonts

<FilZembowicz> Chris: will adding a new specification, just add another mime type to the mix?

<FilZembowicz> If it's more intuitive, people will use the more intuitive one

<ChrisL> The problem is that people are guessing rather than readig the specs

<Raph> (this isn't being discussed out loud, but https://code.google.com/p/chromium/issues/detail?id=70283#c3 has fascinating background on the history of application/x-font-woff)

<FilZembowicz> Adam: distinction between ttf and otf is baggage.

<FilZembowicz> Consider the distinction between .tif and .tiff, .jpg and .jpeg

<FilZembowicz> Vlad: in 2004, proposal was submitted, but given up after 3 years.

(from https://code.google.com/p/chromium/issues/detail?id=70283#c3 : the x prefixing apparently is a by-result of the IETF process where a submitted but not yet approved mime type can be used as long as it is prefixed with an x-)

<Raph> lots of history of proposals (see http://annevankesteren.nl/2008/08/font-mime-types for another example)

<FilZembowicz> Intent of application/ ... things specific to an application, like postscript. But for a long time everything was dumped into application

<Raph> Chris: only example of successful new top level mime type is model/iges

<FilZembowicz> text/ also has additional baggage: wanted fallback so that it could be readable if an email client couldn't handle it, so text/html kinda doesn't fit either

<Raph> dave: what would chris recommend going forward

<Raph> chris: i think it's worth having another try at getting font/ , but i'd like to see evidence it's causing real problems (more than just debug warnings)

Chris: recommends gathering more evidence that the current situation is painful

<Raph> chris: I can ask this to be discussed at next w3c/ietf liaison meeting, gauge how much resistance

<Raph> joe viera: misconfigured mime type (users who wanted to self-host fonts using iis) caused customer support problems

<FilZembowicz> Jonathan: Alternative is to just standardize on application/octet-stream or something like that

<Raph> chris: experience with SVG: getting server vendors (apache) to follow the spec had more impact than wrestling with the standards process choosing the most appropriate mime type

<FilZembowicz> Kenji: simplifies clients -- can filter font requests just by looking for font/*

<FilZembowicz> Problem: switching to another mime type will break existing things

<Raph> vlad: if it's not going to be a huge headache, we should try to get font/ toplevel, do it once and get it right

<FilZembowicz> Vlad: registering individual entries as part of an existing tree (subtype) is trivial

<FilZembowicz> Vlad: file extensions shouldn't match to mime types

<FilZembowicz> Is there precedent for moving to a new mimetype? Deprecation?

<FilZembowicz> VRML got migrated to a new top level type ... took like 7-8 years

<FilZembowicz> Server has to sniff UA to know what to serve .. but it's actually not a problem if it's a garbage mimetype since the UA renders it anyway

<FilZembowicz> Raph: one of the most important aspects of mimetype is security -- sending something with an incorrect mimetype that depend on heuristics

<FilZembowicz> Chris: fonts contain bytecode that can cause security issues

<FilZembowicz> Format in the CSS is a hint whether to download or not download

<FilZembowicz> Mimetype should be an indication that you're getting what you asked for

<FilZembowicz> mimetypes are also used outside of html context, like ooxml

<FilZembowicz> Conclusion: 1) explore whether this is a feasible thing since we all agree 2) collect data on the impact of mimetypes and fonts

<Raph> dave: I'm happy to provide measurements and data, but I don't know how to measure pain (raph offline: how about http://hyperboleandahalf.blogspot.com/2010/02/boyfriend-doesnt-have-ebola-probably.html)

<ChrisL> http://xkcd.com/883/

<Raph> should we serve ttc?

<Raph> Adam: there is no selector in existing css, etc

<FilZembowicz> Adam's proposal: OFF/X: "Open font format for exchange"

<Raph> http://lists.w3.org/Archives/Public/public-webfonts-wg/2013Jun/0023.html

<FilZembowicz> Profile proposed is modeled after PDF/X -- would not exclude other formats. Idea is that it's a hint between font foundries, font tool makers, and consuming applications that this is a set of tools that have a name

<FilZembowicz> Compile the set of wishes valid for a given year, that can be revisited, like a off/x-2013

<FilZembowicz> Accept everything that isn't compliant to the profile -- but if browsers agree to a set of rules, they agree to support them.

<FilZembowicz> Eg, Raph said that he wasn't aware of a UA that supported kern but not gpos -- this could be in a profile. With a profile, we could have more assurance about assumptions like this

<FilZembowicz> Sergey: Isn't this an OS level thing? Adam: why do this related to WOFF? It's a more controlled distribution channel

<FilZembowicz> Good idea for a desktop font to include a kern table -- but there's no need to include a WOFF

<FilZembowicz> Even if it goes to the level of the OS when it's actually used, the fonts should be differently made

<FilZembowicz> Vlad: from the beginning Adam has made it clear that it's not a stick to punish implementors that don't do what is said

<FilZembowicz> OS will always need to support more applications than browsers.

<FilZembowicz> Sergey: it's easier to define the behavior if there is less data in the sfnt -- don't need to know what each OS supports

<FilZembowicz> Eg, on a Mac, if you have opentype and aat tables, it's unclear what will actually be used, it depends on the browser

<FilZembowicz> Even with a profile, UA might depend on heuristics anyway

<FilZembowicz> Raph: Technical observation -- you do consume fonts from a browser in other applications (like printing), which sometimes causes problems

<FilZembowicz> Set of people who sign on isn't so clear cut

<FilZembowicz> Adam: many old platforms and considerations aren't relevant any more

<Raph> Sergey: XP doesn't support new Indic script tags

<Raph> Adam: extension type lookups should be supported, because they're the future, but some browsers don't support them now

<FilZembowicz> Vlad: do you (Adam) expect enforcement from UAs? No

<FilZembowicz> What UAs could do is define stricter behavior for fonts that claim to conform to a particular table

<FilZembowicz> Vlad: that is a contradiction. Adam: document should describe what kinds of data are conformant or not, and then secondarily define suggestions on what UAs should do in each case

<FilZembowicz> Under the profile, it becomes legitimate for the UA to completely ignore a kern table if the profile suggests to do so. It suggests a set of expectations, but what you do with the expectations may vary

<FilZembowicz> "Must not" is too strong

<ChrisL> must not is fine if it means compliance of a font to the profile. itstoo strong for complance of a renderer

<Raph> (example given: if Beng and Bng2 tags are both present, then Bng2 _should_ be preferred. This is better than saying it _must not_ process Beng, or that the Beng tag _must not_ be present in the source font)

<ChrisL> but "should be preferred" is not testable while "must be preferred" is testable

Vlad: (concerns about calling these profiles which sounds normative; if the intent is not to specify UA behavior then these should be called best practices)

Adam: one more place where this would be needed. w3c has css3 fonts and woff/.../ . css3 fonts module has clear expectations defined. OTH, there is no document that says how to actually make good fonts in light of css3 fonts module.

<FilZembowicz> In css2 -- there was a lot of complications with things like ascenders and descenders and how to describe them

<FilZembowicz> WOFF is just a container format, but CSS has expectations

<ChrisL> "This means that explicitly disabling the kern feature will not affect the application of kerning data found in the ‘kern’ table (as opposed to kerning data associated with the kern feature in the ‘GPOS’ table). Authors should use the ‘font-kerning’ property to explictly enable or disable kerning since this property affects both types of kerning. "

<ChrisL> CSS3 Fonts

<FilZembowicz> Vlad: most logical place for these recommendations to live is somewhere for font tool makers

Vlad: (important that participants are able to say) "I am fully compliant with the spec but *This* is why you should choose my product"

<FilZembowicz> Joe: sounds a lot like best practices, which might restrict the space of competition

<FilZembowicz> Example: font-size-adjust property -- doing a clever thing, but leveraging an unreliable piece of data

<FilZembowicz> At what point does CSS affect font development / font format enhancement? Currently, fonts can be thought of a wild animal

(above was John Hudson's comments)

<Raph> but it would be reasonable to expect fonts to tweaked to fit the needs of css / browsers instead

<ChrisL> John suggests that CSS folks talk more to font people to ask for features that would make sense, rather than just trying to work around what is there

John: UA looked at these and saw stripes but wanted dots. UA tried to find workarounds. Instead they should talk to the creators and ask "can we have dots?"

Adam: "please..."

<ChrisL> check out the original list of font formats in CSS2 http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#referencing

<FilZembowicz> David: moving enforcement to the browser is a bad idea, because it's too late

<FilZembowicz> recommends moving enforcement to the tools, developers

<ChrisL> http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#referencing

<FilZembowicz> Example: pagespeed tool from Google -- helpful, informative feedback for developers

Dave: same approach could be used here (a tool that give insights to type designers, font services).
... sounds like "best practices followed by an easy to use tool"

Adam: where those best practices should live?

<FilZembowicz> Dave Crossland: could these be represented by python unit tests running font tools?

(wiki environment would help)

Chris: community group is one way to do it

Adam: (sounds like a plan)

John: strawpoll

about 8?

<ChrisL> yes

Raph: if we could get TypeKit involved
... if we could get TypeKit people involved

<ChrisL> http://www.w3.org/community/

<Raph> Raph: we should get TypeKit and Google to merge existing work (for example, around vertical metrics recommendations) to seed the wiki; this would be a great show of collaborative effort

Raph: would it be ok to reference the community group's output in the normative spec as a way to provide a rationale for the design decision?

Vlad: (no, would create confusion)

<ChrisL> http://www.w3.org/community/groups/proposed/#offx

- DRAFT -

WebFonts Working Group Teleconference

22 Aug 2013

Attendees

Contents

introductions and demos

per table vs per font compression

mime types

Summary of Action Items

Scribe.perl diagnostic output