[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]

Languages: en

Meeting minutes 23 October 2008



A proposal for a Fonts WG is under discussion in W3C. A small meeting was held on Thursday October 23, 2008, during the TPAC meeting in Mandelieu, to allow interested parties to discuss it.

Present were: Sampo Kaasila (Bitstream), Mike Champion (Microsoft), John Daggett (Mozilla, only until lunch), Håkon Wium Lie (Opera), Liam Quin (W3C), Bert Bos (W3C), Alex Mogilevsky (Microsoft), Josh Soref (Nokia, only until lunch), Vladimir Levantovsky (Monotype), Klaas Bals (Inventive Designers), Richard Ishida (W3C) and Philippe le Hégaret (W3C, until lunch).


Discussion topics

The meeting started with a discussion of the notable features of EOT and its advantages and disadvantages compared to raw fonts. The following issues were mentioned:

  1. It should not be more difficult to embed fonts in DHTML applications than in Air or Silverlight.
  2. Choosing EOT as the W3C standard for font embedding gives Microsoft an advantage.
  3. Choosing a technology that comes from Microsoft is politically not possible during the current “browser wars.”
  4. EOT require extra implementation work compared to raw fonts (unwrap, decode, test URL or domain, uncompress).
  5. Raw fonts have caused security problems before (due to bugs in operating systems), EOT may cause them as well.
  6. Almost no font vendors want to license their fonts for linking, most want to allow only embedding (and some not even that), because there is no economic model for free fonts.
  7. Many currently sold fonts may not be used on the Web. Their licenses are likely to change when there is an embedding standard, but there is no certainty.
  8. Recommending two ways to use remote fonts in Web documents, raw fonts and embedded fonts, may delay interoperability (compared to recommending only one).
  9. A UA must convert an embedded font to a raw font before it can be used. Does that remove a “technical protection measure” as meant by the DMCA?
  10. Subsetting is important for large fonts and slow networks. Is subsetting easier to manage if the subsetted font is stored in a different format from the original?
  11. Are there patents that apply to EOT and if so, will they be licensed Royalty Free?
  12. OpenType has “embedding bits” and EOT adds a “RootString” to that. How much of that requires processing by a UA and how much by an author(ing tool)?
  13. Is EOT already portable to non-Windows systems or does it need changes?
  14. The OpenType flags for “Preview & Print embedding” and “Editable embedding” were designed for electronic documents. Do they apply to applications (e.g., DHTML)?
  15. Distributing models: font served from a single server, from the same server as the document, from an arbitrary other server…
  16. Can embedded fonts be cached?
  17. Are there alternative formats to EOT?

Compromise proposal

One idea for an alternative format to EOT is due to Sampo Kaasila. Instead of creating a container format to store the “RootString” and the font, as EOT does, the “RootString” can also be added directly in TrueType/OpenType. TrueType consists of a series of tables and new tables can be added. The new table has to be added as an non-ignorable extension, so that new software will interpret it and old software will fail to parse the file. Concretely:

  1. A new “Web” table with root strings inside regular TTF/OTF fonts. Possibly also some other info, e.g., if font is sub-setted or not, and possibly some obfuscation key. Browsers respect this Web table if present.
  2. Obfuscate 0–100 bits to make font file unusable on a desktop as is. (Prevents accidental illegal use.)
  3. All key browser vendors commit to support both forms of TTF/OTF forms: today's “naked,” and the new “rooted” format. (This leaves it to the market to decide which format will dominate.)
  4. Embedding bits interpretation would be clarified. Web authoring tools would respect them. Web authoring tools build the new “rooted” format. (It is unclear if a browser of “naked” TTF/OTF must look at embedding bits, as today's Safari does not.)
  5. The font name and the link to the font vendor should be shown in a font properties dialog in browsers. (It does not seem we can require must.)

Compared to EOT, this alternative format does not have the XOR obfuscation, does not duplicate any data (such as the embedding bits), and does not provide the MicroType Express compression.

The name of this format could be something like “TrueType-W” (W for Web). Where the distinction between embedded and raw font is important, a file extension such as .ttw could be used (instead of .ttf or .otf).

The fact that the format is an extension of TrueType, rather than a new format, may help to stress that implementers should support both normal (linked) TrueType and extended (embedded) TrueType. In the case of linked TrueType, UAs should probably check the “installable embedding” bit, in embedded TrueType they only need to check the RootString.

A disadvantage of a new format compared to an update of EOT is that it is more work to write new software tools than to update existing ones. But for new applications, a TrueType extension seems less work than implementing EOT.


(Minutes taken by Liam, edited for inclusion in this page by Bert. The minutes are not verbatim: they have been condensed and edited for readability and corrected by the participants.)

Vlad Levantovsky: Font embedding on the Web is long overdue. I want to help make it happen.

Klaas Bals: I'm in the XSL WG for XSL-FO, typesetting, but I'm really here as an observer.

John Daggett: I work on the @font-face implementation for Mozilla. We're implementing the same as Opera & Safari: direct linking to ttf/otf fonts. I'm also editing the CSS3 font spec in the CSS WG. Mozilla, Opera, Apple are queasy, have objected to an EOT WG, don't like the idea of encumbered formats. It makes the Web stack very difficult to use, and when we compare it to other platforms, e.g., Silverlight or Air, those two platforms are ducking these restrictions. I'd like to see fonts become available on the Web as much as possible and I think all kinds of interesting discussions can take place but [we don't want to] use EOT.

Mike Champion: What if it were a W3C Rec?

John: I can't see us supporting it in the way it's heading. EOT brings a lot of baggage that's not good for the Web, we don't think we should support it.

Josh Soref (“timeless”): I work for Nokia and am a Mozilla contributor. I've been researching fonts, APIs, e.g., on Windows. I'm mostly in line with Mozilla's queasiness. I'm uneasy about any fonts, I work on [mobile devices] and have security / stability / blue-screen concerns. I'm interested in fonts, played with Netscape 4 & PFR, and used to collect fonts, and like to look at the crashes fonts can cause. Not heard specific reasons why EOT is beneficial.

Mike Champion: AC Rep for Microsoft. I'm here to represent our official position as best I understand it. Chris Wilson is unable to attend as he's chairing HTML, too far for Simon Daniels to come for a not-WG meeting. My understanding, from Chris, is that supporting direct linking of the fonts would be a great disservice to the independent font industry. A high-level decision within MS says we won't implement that in IE. So what is done other than EOT is [probably] not going to interop with IE. The issue with Silverlight is fixed in version 2.0.

John: Silverlight 2 is partly fixed, not entirely, you can still access raw ttf fonts with script.

Mike: Steve Zilles said as far as he knows MS and Adobe see eye-to-eye on EOT: A direct font mechanism would be destructive to their font business.

Vlad: I'd like to add, we will probably have to explicitly disallow “embedding” with the raw TrueType file in the EULA.

John: The Monotype EULA already disallows it.

Vlad: Our legal people would review this, I'm saying, because we do have concerns. Once raw TT data is attached to Web pages, it's too much of a risk for us to take, as that data will eventually be available to everybody.

Liam Quin: XML Activity Lead at W3C, participant in XSL, we're working on XSL-FO 2.0 and want a liaison relationship at least, as we increase our font support.

Håkon Lie: I used to be W3C staff member, was part of the 1st font WG, have been wanting to see fonts on the Web for a long time. Now we have these wonderful font engines in all our computers, and there's thousands of fonts on the Web, but we need the link to use them. So if we can all agree on the mechanism that would be wonderful. So I started a campaign 2 years ago to have fonts implemented. Now we have 4 products: 3 browsers and Prince for print. I think it'll also work for commercial font vendors. The only real difference is a legal one, EOT is under DMCA but TT is not. E.g., if people write programs to take things out of the browser cache, DMCA might apply to us. Finally, from a marketing perspective, starting something new now that we have something is the wrong thing to do.

Mike: If EOT became a Recommendation, would Opera implement it?

Håkon: We don't automatically implement Recommendations; if everyone used it we might have to. If it turns out this [raw ttf] doesn't work, we could consider EOT.

Richard Ishida: I18N Activity Lead at W3C, mostly here as an observer. Concern for people for whom fonts are needed to display their language. Complex scripts are used in a large number of languages around the world, so want to ensure that the format supports OpenType-like features needed for complex scripts. And subsetting is an important aspect: E.g., Asian (not only CJK) fonts are multiple megabytes in size. But subsetting needs to capture OpenType features of the subsetted glyphs. (Some examples.)

Sampo Kaasila: Bitstream, font rendering & mobile technologies. I was lead engineer at Apple when TT was created. Really want to see fonts used on the Web in a way that makes suppliers of fonts comfortable. So I think EOT, not perfect, is closest thing to something workable I've seen. In principle I'm in favor of EOT, as long as it's really open for anyone to use without restrictions. Want to understand more about patent policy. Really want font vendors to be comfortable. Bitstream has a patent for linking back to documents, e.g., domain locking, so I want to see what Bistream can do to allow access to that patent. Widespread use of fonts on the web is long overdue!

Mike: I think that's the one thing we all agree.

John: The technical problems are minor compared to the licensing problems.

Vlad: I'm afraid many problems perceived to be problems really are not problems. E.g., I was stunned when Håkon brought up DMCA.

Philippe le Hégaret: My job is to figure out what to do with EOT in the immediate future.

Bert Bos: I'm here to find out whether to have the WG, as I'll probably be staff contact. And I'm in CSS WG, so I want to see @font-face deployed as much as possible. Seems to me we have people on one side who want no protection, others who want a lot, but I think EOT may be a compromise in the middle. The idea of having some way of linking fonts to documents seems acceptable to everyone I've spoken with.

John: Can we discuss the actual elements of EOT? I've spoken to people in this room who, if you look at the proposal, think it's something else.

Vlad: The patent of Monotype has already been disclosed in a statement, and contributed on an RF basis.

John: This submission describes 3 different formats, 3 versions. The distinction is the 2nd and 3rd add features, so we should look at the 3rd one, section 3.3 of the document. First, the embedding bits, described in section 4.1. There's a perception that these are used by application authoring content with embedded fonts, but there are also requirements on the UA: “If the font embedding bits do not allow for the font to be used for editing purposes, the user agent shall ensure the document is in read only mode and shall use a font other than the non-editable font in form elements where text may be input.” These areas are of concern to me.

Mike: The Recommendation doesn't have to be compatible with the submission.

John: The charter as written is: Let's push EOT to standard.

Vlad: The embedding bits description in EOT is exactly the same as in OpenType.

John: Relationship of embedding bits to EULAs is a big topic. Another feature: Actual data is obfuscated (section 4.4). The font data after the EOT header is obfuscated, XOR'd. [Not necessarily an issue, just a feature.]

Discussions of e.g., Arial Arabic not working on Apple systems.

John: One embedding bits is print preview. Supposed to be read-only. Any way you can change text in a document, you have to restrict. Can be hard to implement on top of system APIs.

Sampo: Those bits are identical to OpenType today, so you have this same problem with linking to raw otf fonts.

John: [yes]

Josh: EOT highlights this.

Sampo: Yes, but same thing exists in OpenType.

Håkon: There's only one shipping browser: Apple. Apple chose to ignore the embedding bits.

John: Both Silverlight and Flash are taking the stance that they are applications and not documents, so ignoring the bits.

Josh [on IRC]: Nokia Logo contains 28 glyphs and no standard kern pairs. This font does not include embedded bitmaps.

Liam: The restriction about text fields is partly about subsetting, someone could type characters whose glyphs aren't in the font.

Vlad: This is true in OTF too.

John: But the embedding bits are tied to the EULA.

Vlad: But this is true in TrueType too.

Josh [on IRC]: John has mentioned licenses. I'd like to list one: “NOTIFICATION OF LICENSE AGREEMENT
This typeface is the property of Monotype Typography and its use by you is covered under the terms of a license agreement. You have obtained this typeface software either directly from Monotype or together with software distributed by one of Monotype.s licensees.
This software is a valuable asset of Monotype. Unless you have entered into a specific license agreement granting you additional rights, your use of this software is limited to your workstation for your own publishing use. You may not copy or distribute this software.
If you have any question concerning your rights you should review the license agreement you received with the software or contact Monotype for a copy of the license agreement.
Monotype can be contacted at: USA 847-718-0400 UK 44(0)1737 765959 For license terms and usage rights, please visit our web site at www.monotype.com/html/type/license.html”

Josh [on IRC]: Of note, that url is 404. [From Century Schoolbook Bold (TrueType).]

Discussion of meaning of embedding bits.

Liam: So, technical issue, should the embedding bits be removed, since they are burdensome to implement?

John: This all boils down to a legal issue. I'd be happy if font vendors said, if it's a print preview font you can't use it in a Web page. We're taking a model of licensing and of functionality, that's taken from printing, from Word and PDF docs, and trying to apply it to the Web.

Richard: Sounds to me like if we omit 4.1.1 or replace it with text saying people providing fonts for download need to honor eulas and embedding bits, would that solve it?

John: That would simplify for implementers, doesn't necessarily solve EULA issue.

Josh [on IRC]: Aharoni Bold (TrueType) is an example of a print & preview only font.

John: If a EULA says you must respect the embedding bits, those fonts couldn't be used.

Vlad: But that EULA is usually for fonts sold for personal use by retail, print & preview usually all that's allowed; as a Web designer you will have different kind of EULA. Same font sold retail will be sold to Web designers with editable embedding.

John: Look at the bits in Font Folio, maybe 20% of the fonts are editable. And Adobe EULA says you must respect these embedding bits.

Josh [on IRC]: Andalus (TrueType) from GlyphSystems is restricted license embedding.

Vlad: I'm saying they can be licensed differently.

Bert: Josh had talked about how it might be OK (for Mozilla, or for him at least) if fonts were served only by the vendor.

Håkon: It's something we'd consider if it would lead to consensus.

Vlad: What's important is what format it's served in.

Bert: A context of making money, people subscribe, and people also get latest version.

Liam: But can be a privacy problem, potentially the font vendor would find where you were browsing.

Bert: Next issue was obfuscation.

John: I don't see any particular problem with it. Question is, does this really make font vendors feel comfortable? A lot of the information seems to have been slanted. People pitching the idea of the EOT proposal aren't necessarily saying what this means. This obfuscation will be a hackable format.

Bert, Mike, Vlad: Yes, they do.

Liam: Not an issue, we're publishing the spec, it'll be hacked, but they wanted it.

Richard: Yes, makes people think.

John: One alternative is to say, for vendors who want to publish fonts on the Web, could say you have to put it into a jar file.

Håkon: I proposed zip for the same reason.

Liam: Concern I've heard is that that's too easy, e.g. zip, jar, are unpacked too easily.

Vlad: Double-click is too easy.

Håkon: Soon there will be a Linux distro that will take EOT files.

Vlad: People who do that would know they're not supposed to.

Bert: Linux people are very aware of licences.

Håkon: If you try & build a technical barrier it will be climbed.

Mike: It's like a subway turnstile, it's climbable.

John: How high does it need to be?

Håkon: To spark off DMCA.

Liam: Or coppyright, doesn't need to be DMCA.

John: We're not lawyers.

Håkon: If someone makes a statement about indemnification on this basis, that would be good.

Vlad: I am not a lawyer, but I don't see how it can happen, we're talking about an open technical specification. If your browser implements everything that the specification tells you a browser should do to download and process EOT file, and a user hacks the EOT file and uses it illegally, you as a browser vendor won't know (and shouldn't care) what is the source of that EOT file; and the fact that it may have been hacked and used illegally should not be your concern [if everything was done according to the spec].

Håkon: If we take an EOT file and put it into our browser cache as a ttf file and then people write tools to extract things from our cache (they do this today), so we've decrypted the file.

Vlad: So you've done everything you're supposed to.

Liam: What if the EOT spec says explicitly that a browser can keep a copy in memory, in cache?

Håkon: But it's up to a judge.

Bert: If you download, and remove [Mozilla's proposed] access header, you've the same problem.

Vlad: “Applications loading embedded fonts for temporary use (see Preview & Print and Editable embedding below) must delete the fonts from the device when the document containing the embedded font is closed.”

John: There are browser protocols that say, I can reuse data when I visit multiple pages.

Richard: MS has been doing this for several years, has anyone gone to prison yet?

Håkon: By introducing technical measures.

Mike: If, with proper legal guidance, if the spec said something to the effect, this is not a technical measure, used the DMCA language, do you think that would be possible?

Håkon: It would be like the JPEG image spec saying copyright doesn't apply to JPEG images.

Vlad: Nobody can be held accountable for something you do not do.

John: That's not true, if you're a maker of DeCSS software you can be held liable when someone else takes a DVD and decrypts it.

Vlad: But you make the tool by breaking the spec, it's a big difference. DVD player will decrypt the disk according to the spec, I'm not liable.

Håkon: I have a friend in Norway, who wrote the decss tool. So I've been marching in the streets of Oslo protesting CSS. :-) When he was 16, the police came to his door, he was charged, spent his youth, 4 years, in the court system before being acquitted.

Richard: Another way of addressing this is not to apply XOR encryption.

Liam: [Difference between “desktop fonts” and “web fonts.” Vendors don't want it easy to move fonts. EOT will change it, but it's enough to get us past the hurdle maybe.]

Håkon: What if we remove hints from web fonts?

Liam: Chris W would be saying, they spent $1m on the hinting for Arial, it's exactly what they want users to experience.

Discussion on what the font vendors like. Liam describes Le Monde fonts, talking about business model for fonts.

Håkon: They have a font model, it works, but now we're changing it, we're saying you probably can't get payment for every font. When a font is used on my screen you don't get paid. Web model challenges copyright model, this is Hollywood's problem, too, moving into online distribution.

Vlad: Agreed, but that's not what we're going to be charging for. EULA lets you produce as many documents as you like, doesn't matter if it's printed or PDF or Web page. You want to be published and want everyone to see it the same way. You got a license for that, your customers [viewers] don't need to pay extra. I'm nervous that if you publish on the Web a source I license to you, potentially that's open for all sorts of infringements.

Liam: Bad analogy involving breaking into houses vs unlocked door.

Håkon: Example using HTTP “referer” header.

Mike: How would that be enforced?

Håkon: In a stylesheet you'd download the sheet, and your browser would request the font with the style sheet as referer and you'd only serve the font in that case.

Bert: “Referer” does not work in practice, privacy proxies block it, browser extensions fake it.

Vlad: I read the source file to your [Hakon's] Web page, I go to the URL of the file, I get a popup, save this font as.

Håkon: If the Referer field has been used, you wouldn't have gotten it.

Liam: Rathole, can we go back to what could happen to make Opera and Mozilla discuss compromises?

Håkon: We're willing to discuss access control, Referer limits, etc, but not EOT.

Vlad: I as a font vendor and customer will find that solution unacceptable for me.

John: There will always be font vendors who are not satisfied.

Vlad: If we have both protected and raw data format, then the decision to use one or the other is a business decision of the Web designer and the EULA.

John: From Mozilla's standpoint, everything Håkon says, and we'd also like for as many font foundries to support fonts on the web. We're unsure of the degree to which EOT enables beyond flat TT. Maybe they'd change over time and we'd end up with a format no one is interested in.

Richard: From where I'm sitting it seems the issue is we don't know what font vendors really want, don't feel confident they know what they want. So you guys need to make your position for the alternative to EOT clear, e.g., the Access Control idea.

Håkon: These are things we're willing to discuss.

Liam: The charter is a proposal, it is not fixed. We've compared different solutions in a WG before, e.g., in EXI. Let's say the WG is called Fonts Deployment WG or some such.

Håkon: We're following Recommendations, W3C has done everything already, we have rapid progress right now.

Bert: We're still not getting the fonts that we want.

Vlad: Richard asked important question. At this table, we have Bitstream, Linotype, ITC, Monotype, Microsoft, and (not at this table) Adobe, 6 major font foundries, who want EOT and not raw TT.

Richard: So there were other issues, e.g., DMCA, and you keep saying, font vendors don't want this. That's why it would be useful if you could put the plan together.

Håkon: I've written many articles on this subject. We're going ahead with the original font-face spec. Had people come to me, they were afraid of their fonts being used on the Web, but they were unhappy with EOT, too

Bert: The CSS specification for @font-face lists EOT, by the way.

Richard: You want to do what users want.

Mike: Users want good fonts. This [EOT] is a mechanism. MS and Monotype are willing to make IP available to W3C.

Håkon: I do see that font vendors with a big catalogue may see linking to TTF as a threat. But I don't need those fonts, I have 10,000 free fonts to choose from.

Vlad: we sell maybe over 100,000.

Mention of Ascender's study.

Liam: Yes, Ascender vendor is biased.

John: The vendors that support EOT is very small, Microsoft, Adobe, a few others. [ list of licenses.]

Vlad: The reason you don't see it much today, our Web designers in our corporate site, they all told me, we will design & test on every browser. EOT is only on one browser so we don't use it today.

John: That's not an argument for why it's not in a EULA.

Håkon: 90% of browsers have been able to use EOT for 10 years, but it has seen little use except on certain areas of India.

Richard: It's non-interoperable.

Håkon: Many other other things IE has done, some are good, e.g. XHR, these have been picked up and are widely used.

Liam: Several vendors made their EULAs stricter after hearing about Web Fonts in 1995. Also some of the technologies, such as MicroType Express, were simply not available outside of Windows. So there are several reason for the EULAs and for the low rate of use of EOT.

Liam: If the browser Web page info showed a link to the font designer/vendor's page, e.g., GPL or how to buy the font, it may reduce the demand for protection.

Richard: If you have both versions available, and mention both in CSS, what happens?

John: We'd have to test.

Vlad: Reason why browser would support 2 formats, is to give choice to content developer?

Richard: I'm thinking if we can't get past this impasse, you could serve EOT to IE and ttf to Opera, Mozilla, etc.

Vlad: That would only be possible if the font vendor allowed it. You lose the purpose.

Liam: Some purposes.

John: You could write a PHP script that made an EOT header on the fly, you'd have a solution for all browsers. It's not optimal, requires processing time, extra work.

Håkon: Is there anything we could do with the TT solution that would satisfy you?

John: Are you willing to, instead of creating another format, but putting a root string into an existing TT format?

Håkon: [not sure]

Vlad: We can't change OpenType.

Sampo: Nothing prevents us from adding a table, wouldn't break anything, so could add a table with root string.

Håkon: So you could add a Web table.

Vlad: But it will not protect the data. If someone saves it to desktop, the desktop renderer will ignore the Web table.

Sampo thinks it is possible to add a table to a TrueType file that cannot be ignored. Just enough bits or bytes must be different from standard TrueType that existing software will not recognize the file as valid TrueType.

Vlad: I've heard the proposal, a good way to start. We need to maybe for the time being put aside solutions we're considering, and create a group that collects requirements. Probably with much more detailed input in the field. And once we have the requirements we can make an intelligent decision.

Richard: And change the name of the WG.

Mike, Bert: It's already changed, it's “Fonts Working Group.”

Håkon: I'd like to try the link-to-TTF solution for a few years first.

Vlad, Mike: This solution isn't OK for everyone.

Richard: I think what Vlad is saying is that your solution may turn out to be OK.

Vlad: I want you, Håkon, to be a part of this group.

Håkon: By starting a group, we'll go down a route. Unless it's very clear in the proposed charter that the participants are committed to support raw TrueType files, I'd rather W3C doesn't do anything.

Bert: It's proprietary, we can have patent protection if we do it in the W3C.

Håkon: The vendors could make those patents RF.

Vlad: Why would we do that, when the proposed approach doesn't meet our needs? [i.e. no]

Richard: But the important thing is to discuss requirements and find a mutually agreeable format.

Sampo: Håkon and John, we discussed adding a table to TrueType [for domain locking, root strings]. That I think is the major turnstile. Problem is the old rasterizers. Consider adding a table. If that table exists and some other tables are renamed so that it breaks all existing rasterizers, then you couldn't use the font immediately, but it's literally very close to TT/OT: one new table. You look at [the table]: do I have permission to use the font yes or no. If yes, the other tables have to be renamed back [in order to use the font]. So it would be in the cache as a real tt font. Might still have DMCA concern.

John: I was asking Håkon about root string, I think he has problems with it.

Sampo: I think root string, if we put it into OpenType, would you still be opposed?

Håkon: You're proposing a root string, and also a [very very thin obfuscation]. The currently deployed fonts would continue to work?

Sampo: Yes, this would only come into effect if the table was there.

Håkon: So you would only obfuscate in new fonts. I think that's a very creative proposal. It's something I need to think about. Sampo, technically, much easier to implement and less baggage if it doesn't catch on. But font vendors comfortable because root string there. But still possible concern about what goes in the cache. I think it's a good starting point. E.g., you do XOR on table header. But that means we'd have to modify the font to use it, even if only 8 bytes.

John: To use this effectively, you're going to have to look at that data, from a security viewpoint, you're going to have to wander round in font tables already today. I don't think you can take font data off the net and simply pass it down, you need to validate it.

Mike: Does this address Richard's use case for subsetting?

Sampo: [Subsetting] is available at TrueType, too.

Alex: We need font vendors to be comfortable.

Vlad: I understand Sampo's suggestion, can't tell you yes or no on the spot though. But it'd be the same as EOT, root string & XOR… except for the compression. But it's not only people in Europe, US, on the Web, people in Africa say will want the compression, and it is better than 50%.

Liam: Has EOT compression been measured?

John: Microtype is 20 to 30% better [than gzip for Western fonts].

Sampo: Is Microtype something we could all give up?

Vlad: Arial 278K uncompressed; winzip 155K; EOT 117K.

Richard: You'd still be able to use fonts that didn't have the new table.

Sampo: Yes, just like today, but there would be an additional class of fonts with the root string that wouldn't work in today's desktop.

Richard: That leaves your legacy fonts exposed still. Would there be a Weft-like tool?

John: This doesn't prevent piracy, if people just slap a font up there it will work.

Håkon: I think this compromise, IE would need to implement.

Mike: What is good about this over EOT?

(others): No encryption.

Vlad: The only difference is compression.

Håkon: Don't want domain-specific compression. HTTP already has compression.

Liam: [About W3C not usually standardizing submitted technology:] But we have PNG.

Mike: Adobe needs to be in this conversation, too.

Alex: Maybe it's [acceptable to Opera] just because MS also has to do work.

Mike: We've stated that we're willing to take the pain of breaking the EOT legacy, if necessary.

Bert: Chris Wilson said that, too.

Alex: We'd love it if EOT is standardised and we already have 90% of browsers and the other 10% are now going to support it, but that's not what we have here.

Håkon: Does this mean MS would support my Web pages unchanged, with raw unchanged ttf?

Alex: We've talked about possibly supporting direct download if the font is marked as installable embedding, meant to be shared for free.

Alex: We don't want to support direct download if that's the only interoperable way of sharing fonts. That would encourage people to put fonts out there [that aren't so licensed].

Vlad: What you can do now in EOT, can have raw TT data in EOT with no XOR, and no root string, and no compression.

John: We're saying we're not really creating a new format.

Vlad: If you need to restrict it, you'd need to change the format.

John: I think that jettisons a lot of the baggage.

Mike: Those things [the “cruft”] are on the table, could be removed from EOT.

Bert: This is sounding like a change [to OpenType] that would be done by ISO.

Vlad: We'd be asking ISO to standardize something they'd see as Web-specific, they'd want W3C to do it.

John: What does it take to register a new table? Can we get Apple on board with this? TrueType restricts lower-case table names to Apple.

Vlad: I see this gets us half-way, we'd need a conscious reason to drop compression.

John: 90% of the implementation complexity is implementing the decompression.

Vlad: Monotype might be able to share the source code.

John: I don't know if this format is great for mobile.

After lunch

Photo: the whiteboard with some notes.

The whiteboard shows traces of the afternoon discussion.

Most of the participants returned after lunch to evaluate the results of the morning discussion. These were the points discussed:

  1. Is it a requirement to support normal (not extended) OTF? Should that be in the charter of the WG?
  2. Should browser makers make a commitment to implement both raw and embedded fonts before starting the WG?
  3. Compression is useful, but is it a hard requirement? (Håkon would like to avoid having to implement it: HTTP-level gzip is not as good, but good enough.)
  4. There should be a URL to the vendor of the font. (It exists already in OpenType).
  5. Recommend that browser make that URL to the vendor (and other info?) available, e.g., in a “Properties” dialog.
  6. Should UAs always check the “ installable” bit in the case of raw fonts?
  7. There should be no need for a browser to check the editable and print preview bits. But an authoring tool may have to.
  8. What about other formats, such as Graphite? (Graphite is an extension of OpenType and can probably be treated the same as OpenType. Ditto for AAT.)
  9. The specification coming out of the WG should probably mention CFF, to make sure that is supported, too.
  10. There should be no encryption that may fall under the DMCA. (Adding a table to OpenType that cannot be ignored is probably sufficiently weak to not fall under the DMCA.)
  11. Ease of use under different scenarios. It seems we cannot make it easier than adding a “RootString.”
  12. What can font vendors accept?
[an error occurred while processing this directive]

Created 29 October 2008. Last updated $Date: 2009/06/01 13:18:10 $ GMT