17:19:52 <RRSAgent> RRSAgent has joined #webfonts
17:19:52 <RRSAgent> logging to http://www.w3.org/2013/08/22-webfonts-irc
17:19:54 <trackbot> RRSAgent, make logs world
17:19:54 <Zakim> Zakim has joined #webfonts
17:19:56 <trackbot> Zakim, this will be 3668
17:19:56 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:19:57 <trackbot> Meeting: WebFonts Working Group Teleconference
17:19:58 <trackbot> Date: 22 August 2013
17:20:31 <Vlad> Topic: introductions and demos
17:21:07 <Vlad> David K. is presenting the Chrome Canari demo with woff2 enabled
17:24:45 <Vlad> Participants: David Kuettel, Raph Levien., Fil Zimbowicz., Kenji (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)
17:25:16 <Vlad> Adam Twardoch (FontLab)
17:26:18 <Vlad> Observer: Denis Jacqueyre (Dalton Maag)
17:30:10 <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
17:30:36 <Vlad> Action, Fil to distribute the slides to the WG
17:33:58 <Vlad> Google - proposal to replace LZMA with modified, large-window "flate" implementation. Google compression team is working on the implementation of the proposal
17:50:08 <Vlad> s/Kenji/Kenji Baheux/
17:53:52 <Vlad> Discussing NewFlate option - file size gains, decompression speeds, possibility of multi-threading
18:08:09 <Vlad> Kenji - speaking about the work Chrome team has done and is in the process of doing to swap LZMA with NewFlate
18:08:43 <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
18:11:17 <sergeym> sergeym has joined #webfonts
18:27:18 <Vlad> 10 min break
18:48:49 <Vlad> rrsagent, generate minutes
18:48:49 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/22-webfonts-minutes.html Vlad
18:52:35 <joe_vieira> joe_vieira has joined #webfonts
18:59:05 <KenjiBaheux> KenjiBaheux has joined #webfonts
18:59:15 <Fil> Fil has joined #webfonts
18:59:17 <Adam_> Adam_ has joined #webfonts
18:59:38 <Adam_> Adam_ has left #webfonts
18:59:50 <AdamTwardoch> AdamTwardoch has joined #webfonts
18:59:52 <Raph> Raph has joined #webfonts
19:00:11 <FilZembowicz> FilZembowicz has joined #webfonts
19:00:33 <KenjiBaheux> Decompression speed should be a requirement
19:01:00 <KenjiBaheux> Raph: should have "most important requirements" and the rest should be "best practices
19:01:24 <JohnH> JohnH has joined #webfonts
19:02:26 <KenjiBaheux> Joe or Adam (myfonts): compression and decompression should be seen differently;
19:02:34 <KenjiBaheux> Raph: compression ratio and decompression speed
19:03:21 <KenjiBaheux> Chris: (explaining deployment example)
19:03:37 <KenjiBaheux> Chris: already there, nothing to invent.
19:04:59 <KenjiBaheux> Chris: Candidate A (microtype + LZMA) (needs to reflect existing summary, will put data in appendix)
19:07:57 <FilZembowicz> Raph: Kern tables should always be replaced in favor of gpos since no consumer can consume kern and not gpos
19:10:40 <KenjiBaheux> (general agreement that kern tables are not useful)
19:11:27 <KenjiBaheux> Raph: (data should call out whether or not kern tables were included since they are super easy to compress)
19:13:57 <KenjiBaheux> round tripability relevancy?
19:14:11 <KenjiBaheux> Raph: (not relevant)
19:14:36 <KenjiBaheux> worth flagging as a non requirement
19:14:45 <Raph> WOFF2 is "effectively lossless" where WOFF1 preserved binary roundtrip
19:14:48 <Raph> not trivial to specify
19:15:30 <KenjiBaheux> discussion about idempotency
19:16:02 <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
19:16:04 <KenjiBaheux> had this discussion a while ago
19:16:24 <Raph> should we define a canonical form? it's possible but not necessarily easy, and not necessary to make the format work
19:17:39 <KenjiBaheux> and agreed that as long as functionality is preserved this is fine
19:18:11 <Raph> this is already acknowledged in a bit in the OpenType header (font has been preprocessed). This bit is set in MicroType Express processing
19:18:28 <KenjiBaheux> should we then use that flag?
19:18:59 <Raph> vlad proposes yes
19:19:11 <KenjiBaheux> Vlad: would say yes. (harmless)
19:20:12 <KenjiBaheux> data should be in the report (Appendix) not in a separate spreadsheet
19:20:23 <Raph> evaluation report is non-normative, will be published as WG note
19:20:33 <Raph> Chris will continue updating the document
19:21:30 <KenjiBaheux> "Preprocessing based on Microtype express"
19:21:39 <Raph> preprocessing step is based on MicroType Express
19:21:43 <KenjiBaheux> or something similar ought to be used
19:22:17 <Raph> MicroType Express has been published as a W3C submission
19:23:01 <AdamTwardoch> MicroType® Express (MTX) Font Format : http://www.w3.org/Submission/MTX/
19:24:03 <Raph> another step: preparing CTS (conformance test suite) for compression algorithm
19:24:12 <Raph> shouldn't necessarily be done by Google, this is work of the group
19:27:26 <KenjiBaheux> Vlad: (calling for commitment from other "implementers" (e.g. Microsoft, Mozilla))
19:27:57 <KenjiBaheux> Vlad: (security reviews, conformance test suites...)
19:28:19 <KenjiBaheux> (in terms of standardization we would need at least 2 independent implementations)
19:28:55 <KenjiBaheux> Vlad: (at least an acknowledgment would be welcomed)
19:29:51 <KenjiBaheux> Vlad: (should we schedule our next F2F earlier given the tentative timeline shared earlier)
19:30:17 <KenjiBaheux> October, amsterdam (next opportunity?)
19:30:33 <Zakim> Zakim has left #webfonts
19:30:46 <KenjiBaheux> Raph: (agree that this meeting is a good opportunity)
19:31:13 <KenjiBaheux> "Atypl Amsterdam"
19:31:37 <Raph> http://www.atypi.org/atypi-amsterdam-2013
19:33:05 <KenjiBaheux> Vlad: (this time around the proposal is not a blackbox and comes from an existing algo)
19:33:17 <Raph> 9–13 October 2013
19:34:06 <KenjiBaheux> Daniel: (will try to do its best)
19:35:14 <KenjiBaheux> 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)
19:36:40 <KenjiBaheux> David: (asking about the state of Brotli in terms of spec)
19:37:00 <KenjiBaheux> Raph: (understanding is that there is yet to be release document; so coming)
19:37:12 <KenjiBaheux> need a public document to start the discussion
19:38:17 <KenjiBaheux> 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)
19:39:23 <KenjiBaheux> Vlad: (drawing parallels with microtype: Flate is a known entity, the proposal is just making adjustments to it)
19:39:59 <KenjiBaheux> Raph: (should be able to get documentation out early)
19:41:00 <Raph> should send documents and related materials to mailing list - this makes the material public
19:41:57 <KenjiBaheux> (interested parties confirmed that at least one person would be able to join the discussion in Amsterdam)
19:42:30 <KenjiBaheux> (discussion about Spec editor)
19:42:49 <KenjiBaheux> Raph: (unfortunately, unlikely to be a full time editor this time around)
19:43:23 <KenjiBaheux> Raph: (we will make it happen one way or another; follow up offline)
19:44:53 <KenjiBaheux> ---
19:44:59 <AdamTwardoch> Raph talks bout MTX-inspired Preprocessing
19:45:58 <KenjiBaheux> Raph: (some tables are not included: kern, mdmx(? since it can be reconstructed nowadays))
19:46:08 <AdamTwardoch> "hdmx"
19:47:15 <KenjiBaheux> Raph: (glyph wise; very similar to existing approach; only difference: handling of the different aspects [e.g. hint, ...])
19:47:47 <AdamTwardoch> Raph: Decided to do dplitting the "flavors of data" (bboxes, coordinates, hints) into spearate streams
19:47:58 <KenjiBaheux> Raph: (additional 2-3% if we were to go after the open ? table )
19:48:04 <FilZembowicz> FilZembowicz has joined #webfonts
19:48:15 <FilZembowicz> "OpenType"
19:48:15 <KenjiBaheux> (open type table?)
19:48:40 <FilZembowicz> Note: a lot of gains are made from data locality (eg, all bounding box together, rather than per glyph)
19:49:47 <KenjiBaheux> Raph: (explaining the worst case scenario for gzip)
19:50:20 <KenjiBaheux> Raph: (not much gain from gplus gsub)
19:51:16 <KenjiBaheux> Raph: (glyph => unicode and representing delta is about 1% gain; needs to be discussed since this is somewhat complex)
19:52:45 <KenjiBaheux> Adam: (should we go for even more aggressive optimizations)
19:53:03 <FilZembowicz> Eg, Class-based kerning: designers doing compression by hand
19:53:03 <KenjiBaheux> (in open type tables for instance)
19:53:43 <joe_vieira> "Compact representation by hand"
19:53:49 <KenjiBaheux> Raph: (lots of scope for tools to optimize)
19:53:55 <KenjiBaheux> Adam: cubic to quadratic is one
19:54:31 <KenjiBaheux> Raph: (however, these are out of scope for this group and does not need to be captured in the spec)
19:54:40 <KenjiBaheux> => preprocessing
19:55:06 <KenjiBaheux> Adam: (would be nice to share these observations)
19:56:04 <KenjiBaheux> Raph: (yes, this would be in scope for a Best practices document)
19:57:19 <KenjiBaheux> Raph: the question is then is such a document in scope for the w3c or not
19:58:08 <KenjiBaheux> 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.
19:58:37 <KenjiBaheux> Vlad: and innovation.
20:00:02 <KenjiBaheux> Adam: (observing that this WG is a forum for web browser vendors = clients and font vendors = providers to talk together.)
20:00:44 <KenjiBaheux> Adam: (not sharing the additional observations might give an unfair advantage to some)
20:01:17 <KenjiBaheux> Vlad: (not our job to teach other how to innovate)
20:02:05 <KenjiBaheux> Chris: (giving an example of how we could share the data without stifling innovation)
20:02:59 <KenjiBaheux> Joe: "this tool function best if those are the input" makes sense. Not the only way but the ideal way
20:04:22 <KenjiBaheux> Raph: (talking about which tables we drop and which we don't)
20:04:34 <KenjiBaheux>  Chris: maybe those are not best practices but design decisions
20:04:59 <Raph> Chris: these are design assumptions used to drive the design
20:05:36 <Raph> chris: we need to document why we made that decision
20:05:53 <FilZembowicz> (dropping kern table in particular)
20:07:26 <KenjiBaheux> Daniel: (pointing out that web or non web would lead to different choices)
20:08:17 <KenjiBaheux> Vlad: (agreed that the specification should give the background on those decisions)
20:10:58 <KenjiBaheux> (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)
20:11:37 <KenjiBaheux> (Above was from the gentleman sitting next to Vlad)
20:11:46 <Raph> John Hudson, Tiro Typeworks
20:13:34 <KenjiBaheux> 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.
20:14:37 <KenjiBaheux> Chris: (explaining the advisor committee's role regarding charters)
20:16:32 <KenjiBaheux> Joe: (question about the current charter: 2009 charter?) Chris: (2012 but the page is still behind so needs to update it)
20:16:34 <ChrisL> ChrisL has joined #webfonts
20:16:51 <ChrisL> current charter http://www.w3.org/2012/06/WebFonts/charter-2012.html
20:19:53 <KenjiBaheux> After lunch: discussing Adam's proposal on the agenda, also per table vs per font compression discussion
20:22:25 <Vlad> rrsagent, generate minutes
20:22:25 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/22-webfonts-minutes.html Vlad
21:40:33 <Raph> Raph has joined #webfonts
21:41:39 <KenjiBaheux> KenjiBaheux has joined #webfonts
21:43:09 <FilZembowicz> FilZembowicz has joined #webfonts
21:43:28 <Vlad> Vlad has joined #webfonts
21:45:07 <FilZembowicz> FilZembowicz has joined #webfonts
21:45:10 <ChrisL> ChrisL has joined #webfonts
21:46:35 <AdamTwardoch> AdamTwardoch has joined #webfonts
21:47:27 <KenjiBaheux> Topic: per table vs per font compression
21:47:30 <FilZembowicz> Vlad: How important is per-table compression?
21:47:34 <joe_vieira> joe_vieira has joined #webfonts
21:48:01 <FilZembowicz> There aren't plans for UAs requesting individual tables
21:48:02 <AdamTwardoch> AdamTwardoch has joined #webfonts
21:48:39 <FilZembowicz> Jonathan: use cases were 1) potentially with a large font, could request metrics before the font to do layout
21:49:14 <FilZembowicz> 2) selective decompression -- downloaded the entire font, but only need to decompress the tables that a UA actually can handle
21:49:38 <FilZembowicz> Adam: 3) Assumption that certain tables might not benefit from compression
21:49:51 <ChrisL> rrsagent, this meeting spans midnight
21:50:04 <FilZembowicz> If you have a relatively small table, there might not be a benefit
21:50:09 <ChrisL> rrsagent, make logs public
21:50:56 <FilZembowicz> With LZMA, decompression there was some setup time per table
21:51:34 <FilZembowicz> With Brotli, perhaps this is less important
21:52:03 <FilZembowicz> Vlad: don't want to have anything in the spec without justifying it
21:52:41 <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
21:53:27 <FilZembowicz> Good agenda item for having by ATypi
21:54:18 <KenjiBaheux> s/Atypi/Atypl/
21:54:29 <FilZembowicz> Raph: seen with Woff1, the woff1 will be smaller than the gzip. Partitioning the data helps gzip
21:55:03 <FilZembowicz> Raph: Expectation that brotli, with exhaustive search, would work better on whole files
21:56:36 <FilZembowicz> Jonathan: another reason for per-table -- can't easily feed back to an uncompressor
21:56:49 <FilZembowicz> Not secure, but obscure
21:57:49 <FilZembowicz> A potential benefit of per-table is decompressing in parallel -- although Raph notes that in general one table dominates
21:58:30 <FilZembowicz> Are there optimizations in terms of table order?
21:58:54 <FilZembowicz> Raph: sounds almost like pre-preprocessing we talked about earlier
21:59:52 <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
22:00:00 <ChrisL> topic: mime types
22:00:16 <ChrisL> rrsagent, here
22:00:16 <RRSAgent> See http://www.w3.org/2013/08/22-webfonts-irc#T22-00-16
22:00:29 <ChrisL> ChrisL has joined #webfonts
22:00:34 <ChrisL> rrsagent, here
22:00:34 <RRSAgent> See http://www.w3.org/2013/08/22-webfonts-irc#T22-00-34
22:00:47 <ChrisL> ChrisL has joined #webfonts
22:01:00 <FilZembowicz> One of the reasons to not register a top-level mime type: perception that it's an uphill battle
22:01:26 <FilZembowicz> But it seems that this is easier today
22:01:46 <FilZembowicz> David Kuettel shows a presentation
22:02:06 <FilZembowicz> Proposal: top level MIME Media Type for fonts registered through the IANA
22:02:25 <FilZembowicz> font/* ... analogous to text/* and image/*
22:03:25 <FilZembowicz> Problem: today mime types are all over the place, application/* is a dumping ground
22:04:10 <FilZembowicz> Fun fact: people guessed that woff was "x-font-woff" and this was picked up in wikipedia
22:05:12 <FilZembowicz> Vague ones too: application/octet-stream used for ttf, otf
22:05:33 <FilZembowicz> Who does this affect? Web font hosts
22:06:14 <Raph> historically, there was application/font-tdpfr (TrueDoc Portable Font Resource). This was the inspiration behind the application/font-X pattern
22:06:22 <Raph> (Chris pointed this out)
22:07:15 <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)
22:07:19 <FilZembowicz> What happens when there is an incorrect mime type? Historically, guessing, but today there is more just throwing error/warnings
22:07:54 <FilZembowicz> In CSS, you specify the format, so browsers ignore the mime type that is sent
22:08:12 <ChrisL> css already has the format so the browser knows what it is expecting when it dereferences the url
22:09:44 <FilZembowicz> Drawbacks: everyone (web hosts) sets them differently, resulting in errors
22:10:27 <FilZembowicz> What is the advantage of a high level mimetype? David: more intuitive
22:11:32 <FilZembowicz> In Chrome inspector, can filter network requests by just fonts
22:12:14 <FilZembowicz> Chris: will adding a new specification, just add another mime type to the mix?
22:12:36 <FilZembowicz> If it's more intuitive, people will use the more intuitive one
22:12:58 <ChrisL> The problem is that people are guessing rather than readig the specs
22:14:09 <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)
22:14:30 <FilZembowicz> Adam: distinction between ttf and otf is baggage.
22:15:44 <FilZembowicz> Consider the distinction between .tif and .tiff, .jpg and .jpeg
22:17:08 <FilZembowicz> Vlad: in 2004, proposal was submitted, but given up after 3 years.
22:17:59 <KenjiBaheux> (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-)
22:18:01 <Raph> lots of history of proposals (see http://annevankesteren.nl/2008/08/font-mime-types for another example)
22:20:06 <FilZembowicz> Intent of application/ ... things specific to an application, like postscript. But for a long time everything was dumped into application
22:20:26 <Raph> Chris: only example of successful new top level mime type is model/iges
22:20:56 <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
22:21:17 <Raph> dave: what would chris recommend going forward
22:21:44 <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)
22:22:00 <KenjiBaheux> Chris: recommends gathering more evidence that the current situation is painful
22:23:08 <Raph> chris: I can ask this to be discussed at next w3c/ietf liaison meeting, gauge how much resistance
22:24:05 <Raph> joe viera: misconfigured mime type (users who wanted to self-host fonts using iis) caused customer support problems
22:24:49 <FilZembowicz> Jonathan: Alternative is to just standardize on application/octet-stream or something like that
22:25:49 <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
22:25:52 <FilZembowicz> Kenji: simplifies clients -- can filter font requests just by looking for font/*
22:27:02 <FilZembowicz> Problem: switching to another mime type will break existing things
22:28:30 <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
22:30:16 <FilZembowicz> Vlad: registering individual entries as part of an existing tree (subtype) is trivial
22:31:35 <FilZembowicz> Vlad: file extensions shouldn't match to mime types
22:32:58 <FilZembowicz> Is there precedent for moving to a new mimetype? Deprecation?
22:33:20 <FilZembowicz> VRML got migrated to a new top level type ... took like 7-8 years
22:34:57 <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
22:36:23 <FilZembowicz> Raph: one of the most important aspects of mimetype is security -- sending something with an incorrect mimetype that depend on heuristics
22:36:55 <FilZembowicz> Chris: fonts contain bytecode that can cause security issues
22:38:38 <FilZembowicz> Format in the CSS is a hint whether to download or not download
22:39:25 <FilZembowicz> Mimetype should be an indication that you're getting what you asked for
22:40:25 <FilZembowicz> mimetypes are also used outside of html context, like ooxml
22:40:59 <sergeym> sergeym has joined #webfonts
22:41:14 <FilZembowicz> Conclusion: 1) explore whether this is a feasible thing since we all agree 2) collect data on the impact of mimetypes and fonts
22:41:37 <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)
22:41:59 <ChrisL> http://xkcd.com/883/
22:42:00 <Raph> should we serve ttc?
22:42:55 <Raph> Adam: there is no selector in existing css, etc
22:44:16 <FilZembowicz> Adam's proposal: OFF/X: "Open font format for exchange"
22:44:36 <Raph> http://lists.w3.org/Archives/Public/public-webfonts-wg/2013Jun/0023.html
22:48:33 <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
22:49:01 <FilZembowicz> Compile the set of wishes valid for a given year, that can be revisited, like a off/x-2013
22:49:51 <FilZembowicz> Accept everything that isn't compliant to the profile -- but if browsers agree to a set of rules, they agree to support them.
22:50:52 <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
22:51:41 <KenjiBaheux> KenjiBaheux has joined #webfonts
22:55:40 <FilZembowicz> Sergey: Isn't this an OS level thing? Adam: why do this related to WOFF? It's a more controlled distribution channel
22:56:02 <FilZembowicz> Good idea for a desktop font to include a kern table -- but there's no need to include a WOFF
22:56:23 <FilZembowicz> Even if it goes to the level of the OS when it's actually used, the fonts should be differently made
22:57:22 <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
22:57:40 <FilZembowicz> OS will always need to support more applications than browsers.
22:58:41 <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
22:59:22 <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
22:59:33 <ChrisL> rrsagent, make minutes
22:59:33 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/22-webfonts-minutes.html ChrisL
22:59:36 <FilZembowicz> Even with a profile, UA might depend on heuristics anyway
23:00:54 <FilZembowicz> Raph: Technical observation -- you do consume fonts from a browser in other applications (like printing), which sometimes causes problems
23:01:08 <FilZembowicz> Set of people who sign on isn't so clear cut
23:03:28 <FilZembowicz> Adam: many old platforms and considerations aren't relevant any more
23:03:52 <Raph> Sergey: XP doesn't support new Indic script tags
23:04:48 <Raph> Adam: extension type lookups should be supported, because they're the future, but some browsers don't support them now
23:05:27 <FilZembowicz> Vlad: do you (Adam) expect enforcement from UAs? No
23:06:05 <FilZembowicz> What UAs could do is define stricter behavior for fonts that claim to conform to a particular table
23:07:47 <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
23:08:54 <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
23:09:47 <FilZembowicz> "Must not" is too strong
23:10:37 <ChrisL> must not is fine if it means compliance of a font to the profile. itstoo strong for complance of a renderer
23:10:44 <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)
23:11:37 <ChrisL> but "should be preferred" is not testable while "must be preferred" is testable
23:14:29 <KenjiBaheux> 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)
23:16:37 <jdaggett> jdaggett has joined #webfonts
23:16:38 <KenjiBaheux> 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.
23:17:16 <FilZembowicz> In css2 -- there was a lot of complications with things like ascenders and descenders and how to describe them
23:17:29 <ChrisL> ChrisL has joined #webfonts
23:17:30 <FilZembowicz> WOFF is just a container format, but CSS has expectations
23:18:30 <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. "
23:18:34 <ChrisL> CSS3 Fonts
23:18:35 <FilZembowicz> Vlad: most logical place for these recommendations to live is somewhere for font tool makers
23:20:02 <KenjiBaheux> Vlad: (important to be able to let participants being able to say) "I am fully compliant with the spec but *This* is why you should choose my product"
23:20:17 <FilZembowicz> Joe: sounds a lot like best practices, which might restrict the space of competition
23:20:55 <KenjiBaheux> s/important to be able to let participants being able to say/important that participants are able to say/
23:24:40 <FilZembowicz> Example: font-size-adjust property -- doing a clever thing, but leveraging an unreliable piece of data
23:25:16 <FilZembowicz> At what point does CSS affect font development / font format enhancement? Currently, fonts can be thought of a wild animal
23:25:45 <KenjiBaheux> (above was John Hudson's comments)
23:25:49 <Raph> but it would be reasonable to expect fonts to tweaked to fit the needs of css / browsers instead
23:26:38 <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
23:26:54 <KenjiBaheux> 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?"
23:26:59 <KenjiBaheux> Adam: "please..."
23:28:27 <ChrisL> check out the original list of font formats in CSS2  http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#referencing
23:28:42 <FilZembowicz> David: moving enforcement to the browser is a bad idea, because it's too late
23:29:03 <FilZembowicz> recommends moving enforcement to the tools, developers
23:29:19 <ChrisL> http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#referencing
23:30:17 <FilZembowicz> Example: pagespeed tool from Google -- helpful, informative feedback for developers
23:32:00 <KenjiBaheux> Dave: same approach could be used here (a tool that give insights to type designers, font services).
23:33:24 <KenjiBaheux> Dave: sounds like "best practices followed by an easy to use tool"
23:33:51 <KenjiBaheux> Adam: where those best practices should live?
23:34:40 <FilZembowicz> Dave Crossland: could these be represented by python unit tests running font tools?
23:34:58 <KenjiBaheux> (wiki environment would help)
23:35:55 <KenjiBaheux> Chris: community group is one way to do it
23:36:18 <KenjiBaheux> Adam: (sounds like a plan)
23:36:45 <KenjiBaheux> John: strawpoll
23:36:54 <KenjiBaheux> about 8?
23:36:59 <ChrisL> yes
23:38:02 <KenjiBaheux> Raph: if we could get TypeKit involved
23:38:11 <KenjiBaheux> Raph: if we could get TypeKit people involved
23:38:24 <ChrisL> http://www.w3.org/community/
23:39:28 <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
23:41:27 <KenjiBaheux> 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?
23:41:41 <KenjiBaheux> Vlad: (no, would create confusion)
23:45:59 <ChrisL> http://www.w3.org/community/groups/proposed/#offx
23:50:44 <jdaggett_> jdaggett_ has joined #webfonts
23:56:13 <Vlad> rrsagent, generate minutes
23:56:13 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/22-webfonts-minutes.html Vlad
00:51:39 <jdaggett> jdaggett has joined #webfonts
00:57:29 <ChrisL> ChrisL has joined #webfonts