Thursday 14 August 2008
The Coming Battle Over Web Fonts
Bill Hill has posted an article about "font embedding" on the Web, pushing Microsoft's "Embedded OpenType" format as the only way to do font embedding that's acceptable to font foundries. The theme is that "font linking" as implemented by Safari (and soon Gecko and Opera) is likely to get people sued and would lead to widespread font theft, and EOT is a much better approach that is endorsed by Microsoft and other font vendors. Chris Wilson followed up.
One huge problem with Microsoft taking this position is that Silverlight does not support EOT but does support direct font linking. It is very hard to take Microsoft's EOT arguments seriously when their own Silverlight division is obviously not convinced. It is especially galling for Microsoft people to practically demand that other browsers adopt EOT, and scold Apple, while Silverlight is not mentioned. It's plain hypocrisy. We need to keep pressing Microsoft hard on this issue.
Another big problem is that EOT is oversold. It is nothing more than trivial obfuscation of the font file plus some metadata asking the client to limit the domains in which the font file can be used. EOT proponents tout its font-subsetting features, but plain OpenType font files also support subsetting. The Ascender/Microsoft advocacy site suggests "EOTs are bound to a specific web page or site", which overstates the case; it's trivial for someone to unpack an EOT to obtain an unrestricted font, or to modify the domain list, or to modify a client application to ignore the domain restrictions.
The only protection of value is the ability to prevent site A from directly linking to fonts on site B, and that can also be obtained with bare font files, simply by imposing a same-origin restriction on font linking. (Even this won't be a big deal in practice; no commercial site is going to link to fonts on a random server which could be replaced with obscene glyphs at any time!) Safari 3.1 doesn't impose such a restriction but I'm in favour of it for Gecko. (We could support Access Controls for fonts so site B could permit less restrictive linking.)
The strongest argument for supporting EOT is that font foundries will sue Web authors who serve bare font files but they won't sue EOT users. That's a weak argument, since in the absence of meaningful practical differences it boils down to "font foundries are stupid" and I hope they aren't. But if that turns out to be the case, we may end up having to support EOT. Ick.
Another thing about this discussion that bugs me is the "embedded" vs "linking" terminology. "Embedded" sounds more tightly bound to particular documents than "linking", and therefore "better" ... but of course you do link to EOT files and the difference is illusory --- especially if we have a same-origin restriction on @font-face.
Update Chris Wilson comments "[Silverlight] needs the fonts to be in a package starting with SL 2.0, and that package would need to be opened (i.e. you can’t just link to fonts on other people’s systems".
Silverlight has always imposed a same-domain restriction for font loading, and I've never claimed otherwise. As for the package requirement, in March, that wasn't true. I haven't been able to determine whether direct font linking as described in that post was removed in June's beta 2 (apparently the idea you should be able to create Silverlight apps using a text editor has fallen by the wayside), but it's not mentioned in the list of breaking changes in beta 2 (or here). So I dunno. Even if they've removed that, you can probably still use FontSource and WebClient to load a bare font file. Anyone want to experiment?
Anyway, requiring fonts to be placed in the application XAP file (which is actually just a ZIP file!) is a negligible increase in protection over the same-domain restriction Silverlight already had --- I don't see the point.
Comments
OK, now I'm back.
Luckily we have a nice collection of free fonts with different open source licenses. Those can be used legally on any web page. Sometimes the quality of a commercial font could be higher but if the owner of said font says that the font must not be used in the internet, then so be it.
I'd trust that font foundries will get the point once people start using free fonts instead of commercial fonts. Just forget the EOT.
BTW IIRC fonts are covered by a special form of patents, not copyright, aren't they? Well just like every other content, the owner will be able to take legal action against unauthorized users; and they could be able to tap a new market by licensing their fonts for embedding.
Will they be smarter than the MAFIAAs?
The web has spoken!
Right-click, save font as...
Personally, I'd be very interested in seeing the court judgement of Microsoft vs. Microsoft here. It would at least answer the question of whether EOT is legally necessary. ;)
http://securitylabs.websense.com/content/Blogs/3114.aspx
Not all that simple to rip out the TTF from the EOT; maybe someone will make it easier...
Brian: I have no idea how the compression compares to gzip (or bzip2), but I'd be surprised if it's a huge win. The EOT proponents haven't presented any evidence.
fantasai: that's great! If making the point about Silverlight gives Bill Hill and Chris Wilson ammunition against them, then they owe me a drink!
It's not about making it render. It's about making it render nicely. I, personally, think any platform but OS X fails _miserably and tragically_ at rendering fonts at all.
Once you go Mac you never go bac.
They start off with making $0 from the web, due to an overwhelming paranoia that "perfect digital copies" will ruin their business. Then they fight tooth-and-nail to require broken, user-hostile DRM schemes, while ignore $BIGNUM of potential revenue due to their all-or-nothing approach. Eventually they start to cave, and find that they can make a tidy sum from this new-fangled online thing.
Penny-wise, pound-foolish.
From my POV, I think compression + subsetting (that doesn't pollute the pool of TrueType font files with incomplete fonts) are both meaningful advantages that EOT has over raw TTF. I abstain on the DRM stuff: I can see both points of view.
I imagine you can improve on zlib compression by parsing the font file into semantic streams and compressing them individually, but we really need to see numbers. If it's not a big win, it's not worth it.
Huh? You offer no compelling argument for that conclusion.
"Another big problem is that EOT is oversold. It is nothing more than trivial obfuscation of the font file plus some metadata asking the client to limit the domains in which the font file can be used."
Wrong. Even the smallest barrier can effectively prevent widespread piracy - as well as the adoption of legitimate products and techniques. Business history is littered with products that failed to gain a foothold because of seemingly small accomodations customers would have to make to obtain and/or use them. Pirated products are subject to the same dynamic.
Lastly - a question to all: Isn't it obvious that a browser's support for direct linking to TTF files encourages the use of fonts without proper licensing?
(I'm quite certain that you do, Robert, because why else would you anticipate widespread "cracking" of EOT files which require much more effort than if the browser links directly?)
Robert, you can call font foundries stupid if you like, but EOT does enable them to continue to have a market, while bare TTF file sharing does not, in their opinion. Don't take my word for it - ask Ascender, or Adobe, or pretty much any other. You will find a few who say they don't like EOT either - and they will turn off the font embedding bit in their fonts, and EOT tools don't embed them - but they are few and far between.
File sharing, on the other hand, forces you to either only use freeware fonts that have no restrictions (including attribution) on distribution (I don't even know of any that don't have attribution (i.e. "include this license.txt file"), but that doesn't mean they're not out there) - you would never be able to legally use, say, Calibri.
It is not true to say "the only protection is [prevention of] cross-domain]." You could, I suppose, say "if you presume subsetting and the need for a tool to decompress files in order to copy the ttfs are irrelevant, then prevention of cross-domain is left."
Perhaps the problem here is that we disagree on what the goals should be of font usage on the Web, and how it should be accomplished. I think using high-quality commercial fonts without violating their license restrictions is important. I also think not haphazardly destroying any economic model for font foundries is a good goal. What do you think the goals should be, and how they should be priotized?
As an aside, I continue to push on Silverlight - but as I said, they consider themselves to be an application not a document, and therefore are concerned that the "document embedding" bit cannot apply to them legally. We've started that conversation with the font vendors, but it will be a much longer solution there. Until then, Silverlight essentially copies what Flash does, IIRC. Feel free to contact the SL team, though.
Say, "", I gotta say - I have a Mac and a Windows machine, and I can't STAND the Mac's font rasterization. It's nasty.
Justin, how exactly do you think font foundries will make $BIGNUM of money in the future?
I've experimented a bit with Microsoft's WEFT tool which uses the Monotype MicroType compression by default. With a small mixture of fonts I didn't see huge wins (e.g. a 320K font file, 150K gzip, 130K with the MicroType compression). And yes, Monotype has patent claims related to this compression.
Note that subsetting is an orthogonal issue, you can easily subset raw TrueType or OpenType fonts, that is not something that EOT somehow magically enables.
AFAIK font licenses --- even Microsoft's Vista font licenses --- don't talk specifically about EOT, so I don't think you can categorically say that EOT permits something bare font files do not. That's for a court to decide.
People have already pointed out subsetting is not exclusive to EOT. The only issues still on the table are whether EOT's trivial obfuscation is valuable in practice or in law. If the law sees a distinction where practice does not, then the law is an ass. In practice, I think it's completely realistic to expect *Web authors* to download whatever tools they find interesting or useful, and an EOT opener packaged as, say, a Windows shell extension would appear if authors found it useful. (Richard's argument about small barriers preventing piracy fails because small barriers may deter "regular users", but they are unlikely to deter Web authors, who are already in the habit of downloading and using various tools.) We'd probably also see browser extensions to harvest bare fonts from EOTs downloaded during a browser session.
I agree with your goals, Chris, but I'd add a few more --- the solution needs to be a royalty-free standard, it needs to be as simple as possible to implement, and it needs to be as convenient as possible for authors. So it all comes back to the question of whether EOT's trivial obfuscation is valuable. It's not enough to say "well, the font vendors think it is" --- that's just argument from authority.
I see that the Silverlight documentation warns authors to ensure they respect font licensing, but if your position is that Silverlight authors can only legally use free fonts, then I think it's irresponsible to not actually say that directly in all Silverlight materials.
> Lastly - a question to all: Isn't it obvious
> that a browser's support for direct linking to
> TTF files encourages the use of fonts without
> proper licensing?
That's not obvious at all. It's even less obvious that this would create significant economic losses for font vendors. (I'm assuming "direct linking" applies a same-origin restriction, although even without that restriction things would probably still be OK.)
> (I'm quite certain that you do, Robert, because
> why else would you anticipate widespread
> "cracking" of EOT files which require much more
> effort than if the browser links directly?)
For that discussion, I have to hypothesize that authors will want to violate font licensing; then I argue that EOT would do nothing to stop them.
For the question of author motivation, the comparison to images made by Beltzner and others is absolutely right. Probably individual fonts are more valuable than individual images, but images are still valuable --- ask Getty and Corbis. All browsers allow unrestricted linking to images, yet you don't see those images being ripped off everywhere, and Web authors mostly do get their image licensing right. Simply, people with big sites and deep pockets have an incentive to do the right thing. (Cross-site linking is especially stupid for them because of the risk of their site being damaged by a non-affiliate.) Individual Myspace users may do anything, but they're not economically relevant.
So Justin may well be right. But I don't think we need to force the issue.
That's a weak argument, since in the absence of meaningful practical differences it boils down to "font foundries are stupid" and I hope they aren't.
...to mean you consider font foundries, well, misled then, if they believe EOT offers them some protection. (They do, FWIW. Microsoft built EOT as an industry initiative a decade or so ago.) I was not trying to put words in your mouth, so I apologize.
As for your assumption that direct linking would appy a same-origin restriction, I really don't understand why you would assume that. Håkon clearly doesn't believe in it (Prince serves fonts cross-domain today), and Safari (the only current implementation) doesn't apply such a restriction.
I do agree with your goals, BTW - but two of them go at the bottom of the list for me. I would say, in order:
1) The solution needs to be a royalty-free standard (I'd just assumed this one, good catch).
2) The ability to use high-quality commercial fonts without violating their license restrictions needs to be enabled.
3) Providing an economic model for font foundries to continue to be successful is important.
4) The solution needs to be as simple as possible to implement.
5) The solution needs to be as convenient as possible for authors.
> As for your assumption that direct linking would
> appy a same-origin restriction, I really don't
> understand why you would assume that.
Yeah, that's a fair question. I assume it because that's what I want to see in Gecko :-). And I want to see it discussed as an option, since it's technically easy and familiar to the Web, but the only options presented on the IE Blog and the Ascend/Microsoft site are EOT vs cross-site-linking-for-all. Hopefully we'll soon have an implementation out there and then we can talk about it as more than hypothetical.
I guess I'm more concerned about convenience for authors than you are. I'm acutely aware that EOT has been available in IE for nearly 10 years now, and yet has hardly been used at all. Yeah, there always were cross-browser issues, but at various times and places non-IE browsers have been invisible.
But I grant that some Web technologies simply have to wait for the right times and circumstances before they flourish. (I'm thinking of the whole AJAX nonsense!)
I think you really consistently overstate the level of protection that EOT offers. And the EULAs of many font foundry are much more restrictive than you imply and in many cases, read literally, they only really allow fonts to be used with standard document formats (e.g. Word docs, PDFs) and not on the web.
For example, consider the Monotype Imaging Font EULA (http://www.fonts.com/Legal/MI-EULA.htm). Fonts licensed under this agreement are allowed to be embedded only in documents that are "distributed in a secure format that permits only the viewing and printing (and not the editing, altering, enhancing, or modifying) of such static graphic image or embedded document." [Clause 12] Since a description of EOT has been published at this point I don't think EOT could be considered a "secure format" and I don't really think it's practical or desirable to make preview vs. editable distinctions on the web. Does IE disallow the use of preview/print-only EOT fonts within text boxes?
The larger picture is that font licensing in general is incredibly murky to begin with. Apple ships Mac OS X with an incredible set of fonts but there's no mention in the EULA of what license is associated with them. Same is true for the Windows XP EULA although the Vista EULA does explicitly allows users to "embed fonts in content as permitted by the embedding restrictions in the fonts". Although restrictive, Hoefler & Frere-Jones has uses a EULA that is much clearer and more explicit about what is and is not allowed (http://www.typography.com/home/eula.php).
I was hoping, Robert, that you would answer Chris's question and I'm glad that, as a first step, there is a set of goals on the table.
However, it's the second step that's the real doozy:
Who is going to make the final decision as to how these goals are met?
And, taking the comments here in total, this is where I fear there's a wide divergence, perhaps unbridgeable.
Because, at bottom, this whole debate hinges upon property rights. About who has the right to make the final call. And historically, property rights have been an eye-gouging, ear-biting - "oh yeah? well, if you want it you'll have to pry it from my cold, dead hand" kind of thing.
@Robert
In an earlier post, you answered my question:
"Isn't it obvious that a browser's support for direct linking to TTF files encourages the use of fonts without proper licensing?"
With:
"That's not obvious at all."
Now, as a rule, ad hominem arguments stink. And they are doubly treacherous in an online forum where I can't look you in the eye, gauge your body language, none of that. But that said, there are occasions when it's appropriate to voice an opinion of the motives, intentions, and credibility of those with whom you are interacting, especially when there are many others who are sure to weigh in on the same question and take a similar stance.
I do not find your answer credible. That is, I don't think it's your true belief. I think it's a case of "playing dumb" for argument's sake, justified in your mind, perhaps, by what seems to be what you truly do believe: that font foundries don't know what's good for them and that they'll actually end up better off economically if everybody's free to take what they need when they need it.
This is borne out by the second sentence of your reply (non-responsive, though, I didn't ask your opinion on this):
"It's even less obvious that this would create significant economic losses for font vendors."
I have no reason to think that you do not believe that what you truly believe would not be for the greater good. Your intentions may be pure as the driven snow. But contending that if browser support for direct and unfettered linking to TTF's did lead to widespread piracy, few foundries would be badly harmed and most better off, is a lot different from pretending that widespread piracy is not what's going to happen.
Interestingly, exactly this sort of "willful blindness" has been used as a defense in well-publicised infringement cases and courts have shot it down. Judges aren't stupid and they most certainly will ask, "Who do you think you're fooling with this?"
And so should we all.
If am off-base with this, let me have it between the eyes, by all means.
Respecfully,
Richard
I did follow up by presenting one reason why "it's not obvious": allowing cross-site-links to bare *image* files has not descended into an orgy of cross-site copyright violation. You need to explain why it's *obvious* that this will happen for fonts, when it hasn't happened for images. You should have addressed that point before making accusations of dishonesty. Anyway, surely the precedent of images means that it's *possible* the same result would happen for fonts, or at least, that someone could in good faith think it's possible.
I repeat again my opinion that the technical issues of Web font deployment can be settled without having to make judgments about licensing models, property rights or the behaviour of authors. That is a big side-track. The key issue for me is still whether EOT's obfuscation provides significant protection against font copying in practice.
EOT is a silly standard pushed by people who should know better - it is obvious that obfusication is never going to work. Imagine if browsers started to support obfusicated jpgs to prevent hotlinking - would this stop people just ripping the image out of the file and hosting it themselves? Of course it wouldn't. Even the best obfusication in the world is not going to help when the browser must unobfusicate a font before displaying it.
My guess is that web sites using unlicensed fonts will not be a big problem, if only because not many sites really need custom fonts. Outside sites that need to display Klingon or ancient languages, there is not much call for fancy fonts since the existing web fonts are pretty good and everyone uses images for mastheads and logos. Maybe sites like CNN will use a house font for stylistic reasons, but you can be sure that they will license it properly.
Thank you responding to my post in the spirit with which you have.
I will get back to you with something comprehensive and FACTUAL shortly.
Once in a while an issue grips me and I feel compelled to get involved. And, in this case, getting involved means seeking out and concatenating a lot of disparate information from a lot of different sources and then attempting to interrelate them into something understandable and coherent. It takes a little time to separate the wheat from the chaff.
I'm also toying with the idea of setting up an info site on this very subject but am unsure if I want to dive in that deep.
One thing I'd like to focus on (later) is your position that:
"the technical issues of Web font deployment can be settled without having to make judgments about licensing models, property rights or the behaviour of authors. That is a big side-track. The key issue for me is still whether EOT's obfuscation provides significant protection against font copying in practice."
It's not that I think EOT is all that great, it's that the technical issue, for now, HAS been settled in light of licensing models and property rights in that EOT is supported, by and large, by the font foundries.
1) EOT exists now, today.
2) MS is willing to share it - no strings
We're halfway there - why not just roll with it?
Why so ornery?
Plus - and I'll go into this further later - I strongly, strongly, suggest you take into account the legal issues. It is for your sake that I say this. Don't jeopardize you and your colleagues hard work without first checking things out thoroughly.
"Why not just roll with it"? Because if EOT is not necessary, then mandating it puts an unnecessary burden on browser implementers and Web authors. Authors have to use tools to create EOT packages; the EOT packages have to be regenerated when sites migrate, including when stuff moves across staging servers; if a new font file format appears it would have to be shoehorned into EOT; etc. And I'm especially reluctant to make it harder to use fonts on the open Web than it is in Silverlight, just because *Microsoft* says we have to! That seems like a very silly thing for proponents of open Web standards to do.
This seems like a red herring to me. What's to stop me pointing my browser directly at siteA/yourfont.ttf, downloading that file to my machine, uploading it to my server and using it on my site? Or heck, downloading it to my machine and using it in word documents, PDFs, images or anywhere else where a font might come in useful.
The comparison with images really doesn't work. If I put a picture of a waterfall on my website, even if it's a really nice one, its value to thieves is pretty limited. Basically, they've got to want a picture of a waterfall in that size or smaller. Furthermore, if I want to sell the image, I can do things like add a watermark - which means I can post a usable version online whilst retaining a saleable version elsewhere.
It's not like that with fonts. Once you've got the file, you can use the font anywhere and anyhow you like. There's no size restriction. There's no equivalent of watermarking. That's a real threat to anyone hoping to generate earnings from their work.
I don't see the problem with EOT. I've been using it for years. Reading some of the comments here (and elsewhere) it seems that many don't like it solely because of the company that it come from.
You have a font. You use a free program to convert it to a (now) open standard format. You upload it, and add a couple of lines to your stylesheet. Instant font on your website! What's not to like?
> at siteA/yourfont.ttf, downloading that file to
> my machine, uploading it to my server and using
> it on my site?
Nothing, except that there is now an open-and-shut case against you for copyright infringement. No respectable site is going to take that risk.
Of course, there is also nothing to stop you downloading siteA/yourfont.eot and modifying or repackaging the file for use on your site. EOT's not going to make a difference.
For your image comparison, you're assuming that the online image is only a teaser for a higher-fidelity offline version, but that's irrelevant here. We're taking about images and fonts for use on Web sites.
"I'm not a lawyer, but I think it's absurd to think that *we* would be legally exposed here."
Robert: Wrong, wrong, wrong.
I'm not a lawyer either, just a citizen who can read and for the past week part of what I've read has been the court opinions in all the major cases that would apply here; Sony, Aimster, Grokster, and a few others.
Like I said, I'll get back to you with something more comprehensive soon. I'm actually having some fun researching this, my problem is time.
Web authors who are using expensive fonts and believe that using eot will somehow bring them into compliance with the font licence will wrap them up into eot files. Web authors who are using free fonts with permissive licences and don't want the hassle of one extra tool will link directly to the ttf. Everybody is happy!
I'm going to start putting together a whitepaper of sorts on this issue starting tonight. I know there will be others interested so it'll work out better as a separate document rather than a long post.
It'll take some days but it's coming.
In the meantime just a couple of things:
1) The big difference between image files and TTF/OTF files is that the font files carry with them information regarding provenance (who made it, etc..) and licensing restrictions or lack thereof.
This is a BIG BIG difference legally because the knowledge necessary to prevent unlicensed use is embedded in the file. (Yes, I know you are going to want to argue about that, but later. And the fact that the files can be hacked is irrelevant.)
2) Hakon Wium Lie has been speaking and publishing about this issue for at lest two years and STILL, Opera has not implemented @ font-face with direct linking to TTF/OTF files. I have emailed him asking why, but I'm a nobody to him and haven't gotten an answer. But it's a good question right? Maybe he would respond to you with an honest answer. (I am quite sure we haven't seen it because Opera does not want to run the risk of exposing itself legally. Lie seems quite savvy legally. But this is just my suspicion.)
3) Why did Apple implement it? Well, it could very well possibly be that the implications just fell through the corporate cracks and no-one thought about it much. It happens. Or it could be that Apple is flipping Microsoft and Adobe "the bird" and saying, "Don't like it? Sue!", and are perfectly willing to let it play out legally if that's what it comes to.
(Remember that the fonts we have today funnel up from the operating system whether it be Mac, Windows, or whatever, and that Apple licenses those web fonts we've all come to know and love and grow tired of from MS. There's competitive maneuvering going on that neither you nor I will ever be privvy to.)
4) The legal exosure you would be facing and that Apple is facing right now is called contributory and/or vicarious infringement.
5) About me: I don't work for anybody who has a stake in the outcome of this issue. I have no stake in it, either. Richard Fink is my real name. I live in sunny Naples, Florida.
6) I urge you strongly not to take anybody's word about this and to seek guidance from a qualified IP attorney before taking the step that Apple has taken. (Emphasis on QUALIFIED - the average IP attorney wouldn't have any experience at all with a situation of this kind.)
http://blog.fawny.org/2007/09/13/simonda/
This is a post from accessibility expert, author, and typophile Joe Clark's blog reporting on a talk given by Simon Daniels, one of Microsoft's typography guys.
Note the phrase: "a few high profile cases" in regards to the possibility of future litigation.
rich
It is implemented in something they call Wingogi, which is a stripped-down build they use as a test-bed.
Available here:
http://labs.opera.com/downloads/
However, whether or not support for it will actually be in the next release he did not say.
As of Opera 9.2 it is not.
But please, this feature will go a long way in making the hurt go away. Make it go away. Please.
It will, at the very least, be interesting to see how this unfolds.
If you're still monitoring this...
In retrospect I'm very glad font-linking was implemented in FF 3.5.
It's clear to me now that the only way forward was to just do it and get beyond talking.
In a year or two, we'll all have a much better idea of whether @font-face needs refinement based on results in the real world.
Thanks for your fine work. FF3.5 looks great.
Apple has done a decent job of incorporating well designed fonts because Steve Jobs loves typography. But Microsoft needs to catch up.
http://www.freerepublic.com/focus/chat/1422863/posts
Knockoffs (Arial anyone?), worn out typefaces (TNR), and screen fonts that print terribly (Calibri) are just the tip of the frustration iceberg.
Any number of well designed fonts from Adobe or Linotype would do. Here are some suggestions:
* Berthold Types (Akzidenz-Grotesk)
* Hoefler & Frere-Jones (Gotham, Mercury)
* International Typeface Corp (ITC New Baskerville),
* Font Bureau (Titling Gothic, Benton Modern)
Between Windows and Mac OS X, the number of shared (or similar) well-designed fonts is extremely low. I'm preaching to the choir in this forum, but well designed HTML based sites consistently lean on a handful of fonts, like Verdana, Lucida Grande, Georgia, and Helvetica.
http://www.smashingmagazine.com/2008/07/24/a-small-study-of-big-blogs/
Foundries need to fight embedding because that's intellectual property theft. Well designed fonts have tremendous value.
Cufon and sIFR are not the solution. Neither are Flash or Silverlight.
Consumers have the power to push industry change, but they have to be aware of the need. Most in the non-web, non-design community don't know (and frankly don't care) what a serif is.
I would be willing to pay a premium for an OS that contained a library of well designed fonts. And I'm sure others would too. Getting good fonts into Operating Systems is the only real way to push change in this arena, which extends beyond the web into desktop publishing software.
In every market there is an affluent consumer that insists on having the premium product. How many consumers purchase Ultimate or Professional versions of software, and never use a fraction of the extra features.
I guarantee, if you bundle some great fonts into an OS, consumers will use them. Microsoft, if you're listening, license some great fonts for Windows.