<ChrisL> Vlad: welcome everyone, and thanks to Google for hosting!

<ChrisL> kuettel: lucky the office was so close to the conference hotel

<ChrisL> scribenick: ChrisL

Vlad: a few things to get woff2 finished. after that is an unknown
... do not want the group to just exist without a plan for the next task. We have time left in the charter but let us decide what topics to pursue and get a new charter going. Or, decide to do maintenance only.

kuettel: what timescales are in effect?

Vlad: current charter is woff2 only. We can't change that charter before that happens, as any change will result in rechartering and rejoining. This affects IP commitments
... rejoining covers the new deliverables under the W3C royalty free patent policy

ChrisL: (current charter ends 31 May 2017)

Vlad: so if someone proposes a new work item, and we agree, then there will be an obligation to provide that IP once you join the group

ChrisL: we don't have to wait, we can recharter when we want to

Vlad: don't want to loose the IP commitments when the group recharters
... as an example Apple only joined for WOFF2 fairly late on

sergeym: we have multiple implementations?

Vlad: right, all the browsers used the same library

sergeym: what about font tools

Ned: all browsers share parts of the code but not all. So Safari Webkit for example are different and parts are the same

Vlad: right, it is a grey area
... so we need to examine the amount of shared code

sergeym: Brotli status?

ChrisL: it is a normative ref developed by IETF. It is now an RFC

sergeym: it has two independent implementations

behdad; and there is a native JS implementation too, so that is three

Ned: if conformance is measured at user agent level, how much code share is allowed

Vlad: spec is only good if people can independently implemnt it. hence the requirement for two implementations passing each test. it isn't an interoperability requirement for CR, it is an implementability test

Ned: so the downside is that it remains at CR
... apple would like to reimplement but we don't plan to in the short term
... benefits for our sourcebase to refactor, and progressing spec past CR would be another driver for that

Vlad: what license is there on the Google reference implementation?

sergeym: MIT license

Vlad: so people can make changes and are not required to contribute them back

Kaled: what is a UA? Fonttools can decode the fonts

ChrisL: so any sort of viewer that displays the html/css counts
... UA tests assume text display but not font access. Decoder tests assume access to the decoded font

(we notice the readme says MIT and the actual language is Apache)

behdad: Apache includes an IP grant

action kuettel to sort out the Google WOFF2 decoder license

<trackbot> Created ACTION-202 - Sort out the google woff2 decoder license [on David Kuettel - due 2016-09-19].

Vlad: JS implementations are common now, there is a clear benefit to shared libraries
... also a benefit for AMP as well which precludes third party JS libraries

output would be a library not a specification. But Rod mentioned we can have the API as a specification

kuettel: so that is two proposals, one for a library and one for native browser support. Both same API

Vlad: is that serverside?

kuettel: not necessarily

Vlad: client and server communicate

kuettel: Bram from Adobe is the expert on webfonts for typekit

Vlad: happy Bram could attend
... know Monoype, Adobe, Microsoft have IP related to subsetting
... none of us have express permission to propose tech in detail

(we talk about the joy of discussions with lawyers)

Vlad: access to shared IP

(more patent policy discussions and cost benefit analysis)

kuettel: agenda+ dinner

WOFF2 test suite status

Vlad: discussion on transformed glyf table, was that clear?

khaled: yes. Difference was huge for that one test
... conformance is all implemented, just need to check implementations against them

Vlad: any known tests not yet done?

khaled: no
... less than 10 tests that had no descriptions in test plan, added them
... we can review them if needed

Ned: Safari 10 has WOFF2 support, this week on iOS and next week on macos

kuettel: all the browsers have woff2 support now!

RESOLUTION: celebration

Khaled: (projects a diff of the test descriptions)

(we agree on the test description changes)

khaled: and now we need to fix the Google implementation as it does not pass all the tests

tabledata-recontruct-loca-001

tabledata-recontruct-loca-001

bram: some poeple think that woff2 eliminates metadata! Because the section is so short, just points to woff1

<kuettel> Chris is showing a demo of the WOFF 2.0 conformance test suites running in the W3C test framework

<kuettel> Chris: needed to make some changes to the tests in order for it to run, e.g. locating fonts in a special directory

<kuettel> Chris: we are in fairly great shape for the user agent tests

<kuettel> Chris: one of the tests that is failing is the total font size

<kuettel> Khaled: WOFF 2.0 module has a new API. OTS is still using the old API.

<kuettel> Khaled: Firefox is currently using an older version of OTS, thus perhaps the failure

<kuettel> Khaled: when Firefox picks up the latest version, should work

edge does not use OTS

Vlad: so here sharing the decoder is not exactly the same. Edge does not use OTS
... we have examples where Edge passes and FF/Chrome fail

<jfkthame> (FYI - hangout sound seems to have dropped off, i see people apparently talking but hear nothing)

<kuettel> Jonathan, are you able to hear now?

<jfkthame> yes, it's back

<kuettel> Great!

sergeym: we could have a seperate version of UA tests that just displays P/F for testing with fonttools

khaled: the failing tests should be reported on github. There are 4 or 5 such tests

ChrisL: what do we do for format tests?

khaled: we have about 300 files for testing the format tests

Big discussion on new work items

<jfkthame> mine's a cappucino, please :)

<Vlad> got it, coming right up :)

<scribe> scribenick: Garret

David: go around the table for ideas for projects for the working group to tackle next.

Bram: joined to get an update on the working group and find out where they're going next.

David: Rod proposed a few things
... - font access/manipulation apis in js.
... - named unicode ranges. Goes back to Jonathon Dagget. Would be helpful for scripts such as cjk where the range is not concise. Instead could have something like unicode-range: japanese
... Other unicode range issues: problem with open type features not spanning subsets.

<ChrisL> I would like to see the arabic and latin unicode-range example khaled just mentioned

Vlad: there is an iso standard that has been finalized which is based on apples composite font representation. xml based format that solves multiple problems. The biggest is the inability to support more then 64k glyphs. Recipe points to multiple fonts that behave as one.

Ned: doesn't work with CJK.

Vlad: crf allows different fonts by language.

Ned: the problem is that web browser needs to know how the crf is constructed to know which resources it needs. Doesn't solve the problem where common characters need to behave differently in different circumstances.

<ChrisL> ISO/IEC 14496-28:2012 (Composite Font Representation)

Vlad: purpose of my comment is to remind the standard exists.

<ChrisL> https://blogs.adobe.com/CCJKType/2012/07/cfr-support-in-mountain-lion.html

<ChrisL> https://blogs.adobe.com/CCJKType/2012/04/cfr.html

Ned: there's the issues having to do with common characters. Another cjk related situation is the different glyph behaviour of codepoints as they exist in different languages.
... paranthesis will appear differently depending on script. With cjk same script different language has a different behaviour. Even unicode range would not address that issue.
... with arabic if you have a full stop next to cjk. You want an appropriate appearance for cjk based on language.
... you could have identified a font with cfr, but it still doesn't address the issue that without having specified it you want the common character.
... the issue of fallback is not determined for each glyph independently. Each page will specify a font stack. It's primarily latin but has a run of arabic. You want the common characters to take on the properties of that script.

Sergey: you'll be wrong in some cases.

Ned: I think there's a huge amount of work that could be done. There's a lot of w3c work for layout.

Chris: there are sometimes no examples of how combinations should behave.

Kaled: important issue is cross font features.

Sergey: should not be a concern of w3c.

Khaled: harfbuz can do it.

<ChrisL> (preserves basic shaping across fonts. not kerning)

Khaled: i think if you have unicode range for the same script served as two fonts you lose kerning and features across those fonts.

David: what a lot of these are touching on is how could we support large web fonts. ie. Multiple megabytes. Latency would be too high without leveraging other techniques.
... the first one is if your serving streaming fonts cant you put the fonts back together.

Ned: the next point, templating brush strokes tech. That's a quest of how can we create new formats in an extensible way. Not just a question about cjk. I see there being a question of there is a negotiation now. It shouldn't be the servers job to sniff the client to determine what they support. There should be a way to negotiate what they support. Then it's much easier to experiment with new formats.

David: some is handled by @font-face. You can enumerate formats.

Ned: I'm interested in closing the hole.

David: we need to sniff because not all browsers fully implement the spec. For example with unicode range some browser will download all specified fonts.

Ned: we think that with the way things are now it's possible to introduce new formats.

Chris: @font-face tried to do it the other way, the css would specify which were available and the client would choose.

David: bullet proof syntax. To Chris' point it was to work around bugs in browsers. For example on particular android systems would crash when encountering local.

Bram: we use it to pick formats that render better on certain platforms.

Khaled: or if we want to drop hinting because it's not used.

Bram: it's something we're trying to move away from.

David: Ned, I agree that servers should not need too sniff ua's.

Ned: with variation fonts when does it become a new format. ie. hinted vs unhinted ttf's.
... font formats are becoming increasingly forked.

Bram: we differentiate between container format, outline format. Then can mix and match to determine what the browser gets.

Ned: it sucks on either end to have to figure out what the fallback is.

Vlad: we're just about to finalize registration font type for the format and sub flavours.

Chris: the reason there's the format in the first place is to try and get a top level mime type for fonts. We had to give up on that and put in the hack with format using strings. Should have been a mimetype.

Ned: sounds like format is not solving the problem anymore.

Chris: it's not fully solving it.

Ned: not that a service wouldn't want to do this, it would be possible to serve a font that supports multiple formats.

<ChrisL> hard to use @font-face to separately serve SVGinOT, COLR and classic OT from three URLs for example

Ned: I know that typekit would not serve a resource with svg glyphs and colour glyphs. You could though, and the client could support either and pick.

Khaled: many hybrid open type fonts.

David: back too the list: could there be a new format or mechanism for creating font files.

Sergey: or a mechanism for streaming.

Chris: strokes and library of terminals. Should be more compact in theory.

Vlad: monotype has it's own stroke format for years. For many devices that have resident fonts and a rasterizer. Especially for CJK fonts.
... also experimented, not successfully, with stroke fonts with different styles for the strokes.

Ned: battle between smaller but not nice enough, and the opposite.

Vlad: good for devices with limited resources that are self contained.

Ned: defining a font format is a huge/time consuming effort.

Vlad: vast array of standards and organizations that issue them. We can help others do something if we feel it's helpful.
... may not always be practical to do something outside of the scope of w3c.
... identified one potential: native implementation of combining fonts client side (ie. typekit augmented fonts)

Sergey: when sending font to printers subset to all characters on the first page. Then create batches which use more and more. The first one had the glyphs filled with zeroes. Then patches filled the holes.
... works for glyph data but not everything else.

David: last item can we send metrics first so the browser can do layout first.

Ned: would be only useful for CJK.

David: could also be useful for things like noto that support a large number of scripts in one font.

Ned: there's two types of fonts ones with huge number of glyphs and ones with complex shaping. Noto is the first example of one with both.

Behdad: CJK in Noto is seperate.

Ned: still have the possibility of one side with both.

David: if we were to see pan unicode fonts those files would be big.

Khaled: there would be other issues then just the size.

Peter: arial unicode was around 23mb.
... in direct write in windows 10 added the ability to download fonts from cloud services. Created mechanism similar to the subsetter where only a portion of the font is downloaded depending what's on the page. Then figure out from the content what byte ranges are needed to layout the content. Then fetch content in 64k chunks.

David: for browser or platform?

Peter: for platform.

Vlad: what we learned with woff 1. When you use byte range request the handshake could many times be longer then time to transfer the data. Kenji did that analysis again for webfonts in digital ads. He showed that a full font will take 50ms to download on mobile platform. The subset would take 10. The handshake 100-150ms.
... http2 being able to download more with one request is helpful here.

Peter: in the study what size of fontdata?

David: probably small

Vlad: the overhead even if they had subset of chinese kills any gain from reducing the size. Download time is usually pretty fast.

Ned: you can imagine cases where it's not worth augmenting more then a couple of times because the data required to specify new ranges.

David: named unicode ranges may need to be persistent but dynamically updatable.

Sergey: coming back to efficient stream we could also look at composite formats.

Ned: what do you see missing from composite formats now?

Sergey: you need to specify family directly.
... need individual font face rules.

Ned: wondering if the server now needs to be parsing content for the optimal experience.

Sergey: think it would be interesting to look at alternate ways for specifying composite fonts. Get hints working better and more.

Ned: does there need to be a replacement for @font-face?

Sergey: maybe an improvement.

Ned: don't want an intermediate resource, would be good if it could be specified in css. What's missing in the css.

Behdad: being able to specify language and script instead of unicode range would be useful.
... selection works based on script but needs to be able to be refined by language.
... no canonical algorithm for font fallback selection.
... css algorithm is broken.
... the hard part is around common and formatting characters.

Khaled: some clients do fallback after shaping.

Behdad: shape and then only day extra work for areas where that doesn't work. Decompose then try to recompose if the font supports it.

Ned: all chrome knows is that none of the things harfbuz tried works and then tries going on to the next fallback

Behdad: it's like we do some unicode normalization on the input to make sure it shapes better.

Vlad: would like to bring up tracking. For fonts on the web it's not a big issue since services can track. It's more difficult in the larger world like use in digital ads.
... web font services want to know how many times a fonts delivered. Ads track number of views but don't want to share that information.
... can the group consider doing a universal tracking mechanism that no-one will object too?

Chris: that's the problem. Also there's some ambiguity in what you're counting.

Vlad: once the font is cached it wont ask the service again, but tracking would count the impression. This could count towards someones subscription package.

Peter: what happens when the quota is up since the font is already cached.

Vlad: will get a reminder to subscribe to a bigger limit.
... it's about accurate billing.

Chris: something that made webfonts succeed is that the browser is not policing usage.

Vlad: right now css includes a ping link that doesn't slow anything down.
... ads providers don't like any additional pinging as part of display ad code.
... wondering if we can tackle a solution that makes all sides happy.

David: somewhere where there could be lots of complication such as in abuse and scam. We could end up coming up with combinations that would be easy to abuse.

Chris: someone could run up someone else's bill.

Behdad: ads already have these problems.

David: yes, but they tackle them differently ie. have a bunch of intelligence server side.

Vlad: in order to create a thriving ecosystem you need to make sure creators can get accurately paid for their product.
... because ads don't want us to do tracking we have to do unlimited usage licenses.
... a problem with independent creator because we can't give them accurate numbers of usage.
... we currently have to limit fonts available to these services.

Bram: we have the same problems, but feel this shouldn't be a w3c solutions. It's our problem to keep track of usage.

Vlad: it's about creating sufficient transparency that policing is not necessary.
... I don't have a solution.

David: I agree. It's probably one of the hardest problem as an industry we have yet to solve.
... ads is a more complicated situation than traditional usage.

Vlad: want to bring up: non-traditional deliverables can the w3 accommodate. Like a js library. Spec portion would be the api.

Chris: if we're developing a spec and an implementation of that spec then that's fine. As long as someone can develop an independent implementation.

Vlad: if it's something that doesn't fit the typical mold like having a test suite available.

Chris: some features may be able to have a native implementation.
... will it be client side or have the option of sending some operations to a server.

Vlad: everything's on the table.

Bram: what is this groups scope, could we do css stuff?

Chris: css should be left to the css group.

Bram: interested in extended css font loading.

David: API's to query info about a font?

Bram: yes

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: ChrisL
Found ScribeNick: Garret
Inferring Scribes: ChrisL, Garret
Scribes: ChrisL, Garret
ScribeNicks: ChrisL, Garret
Present: kuettel ChrisL Bram Stein sergeym Khaled Ned Behdad jfkthame Peter_Constable

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 12 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/12-webfonts-minutes.html
People with action items: