Minutes
(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.