One of the biggies Mozilla is missing for CSS2 is downloadable font support. This bug should serve as discussion towards that end.

Should this be done by 1.0? What are our goals for 1.0 WRT CSS2 compliance?

setting status to new.

Oops. Forgot to add a keyword

*** Bug 72813 has been marked as a duplicate of this bug. ***

transferring keyword from duplicate bug.

Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.

There is bug 55194 about WebFonts. Anyhow, there is no way it can be implemented for 1.0 without external help.

Is this different from bug 41250?

I am not sure if it's the same as bug 41250; PFR support seems to be major missing feature. Maybe BitStream could help out?

marking dependencies as a reminder

(See also bug # 59611/52746) I have called BitStream to go open source with the TrueDoc PFR technology for the benefit of the Mozilla project, and they indicated they're ready to do so. Please see my article on this topic at http://www.tarunz.org/~vassilii/BitStream.html

Assigning pierre's remaining Style System-related bugs to myself.

Disclaimer: I've no idea, how font-usage works in Mozilla. In Java/AWT, it is possible to use any font-file (as long as it's supported by the font engine). This can as well be done at runtime, so it's possible to download a font file from the net and just use it. Question 1: Is this possible in Mozilla? Or would this require some kind of 'install the font in the system'? If it is possible, question 2 is: Is the only problem preventing this bug from being fixed the lack of PFR/EOT support? If so, http://www.w3.org/TR/REC-CSS2/fonts.html#referencing specifies a whole bunch of font formats that may be used for downloadable fonts, so what?

I understand this bug as more general. It covers any possible formats potentially specifiable via font-face (which is not necessarily a frozen set for the whole future), currently indeed as per the URL you've given. Go into the prev. comments on this bug & the referred bugs for specific Bitstream PFR support request. As for the present status, on Linux at least, I'm unable to have any (not installed) font referred to by the stylesheet dynamically downloaded and shown along with a page. I don't run Windows on my home machine so I don't know whether at least TTF would be fetched there, I can give it a try next week off the latest version at work during some lunch break :-) IMHO, any viable format would be good (Opentype, PFR, Type 1 or whatever). As long as at least ONE PER PLATFORM is supported by Mozilla - i.e. so that the designer could, say, give a PFR for non-UNIX and Type 1 for UNIX, link them both into the page, and have the browser download the font face if allowed by the user. (Of course, the CSS spirit is not to rely on the fact that the user prefs will ever allow the font to be downloaded ever, not to mention the exact sizing wrt the other page elements, and this is why as much as possible font attributes should be specified by the stylesheet so that the closest local matching font could be used; so, in a way, Mozilla sort of enforces good design by having people specify those attributes while the fonts aren't downloaded yet ;-) ).

Note that there are intellectual property issues here. Most (not all) fonts are not freely redistributable in their "native form". The point of converting to Bitstream'sPFR, or to Microsoft's eot format, is that the fonts are (1) restricted to a single domain or URL, and (2) (lightly) encrypted, to make them harder to rip off. Of course, it's also desirable to have a web page that works for readers on multiple platforms. E.g. http://www.holoweb.net/~liam/old-books downloads fonts in MSIE and Netscape 4 on Windows, but not with Mozilla on Linux. (with Netscape 4 on Solaris I think it downloads the fonts but then does not display them).

> Note that there are intellectual property issues here. Sure. But these IP issues are certainly not an issue for mozilla, but for the website owners. Please, there are enough legal issues around mozilla, don't add this one... So technically, there are three issues here: 1. Extend the CSS parser to recognize the src attribute of font-face descriptors, and download the font. 2. Make the downloaded font available to the rendering engine. 2. Add support for other font formats. While (1) is certainly almost trivial, my question in comment #13 was whether or not (2) is easy to do for supported font formats. If it is, then (3) shouldn't completely inhibit the implementation of this feature.

ccing some people who may have an idea of how complicated item #2 in comment 16 (I suspect it'll require separate code on all the supported platforms....)

With Xft it's not too hard. If we have a directory that we download the .ttf files into, we can tell Xft to include that directory in its search list, reload the list of files once the download is finished and re-render using a new font metrics object. Or, if you make sure the font has been downloaded and the xft font list has been re-hashed you only have to make the font metrics object once.

Hmm... if we combine that with reloading the font list at app exit (when we delete the font files), that may work.....

what about evil font files (could a downloaded font poison other x apps?) and what happens when mozilla doesn't exit cleanly?

If font files are downloaded, they should be used from memory, or downloaded into a tmp file that's unlinked immediately (I think this technique is Unix-only though). There *are* legal issues associated with making fonts available to other users without also the license. It's sort of like distributing GPL'd software after removing the GPL, and if we as a community make a fuss about people doing that, we can only be listened to while we respect other people's licenses, even ones we happen not to like. There are good reasons why both Netscape and Microsoft chose not to support downloading TrueType and Type 1 fonts, and these should not be dismissed without legal advice. Technically, though, maybe the fonts could simply be in the browser cache. The main two formats I can think of right now other than Type 1 and TT/OTF are SVG fonts and Bitstream PFRs. I don't know if Bitstream would be willing to donate their code to read and render PFR fonts, but I doubt it. SVG fonts are unhinted, but it'd be a good 3rd term project or undergrad thesis to convert them to Type 1 and have the FreeType autohinter run on them.

timeless write: > what about evil font files (could a downloaded font poison other x apps?) and > what happens when mozilla doesn't exit cleanly? That's no problem. Just create a fonts.dir file with a unique XLFD name and modify run-mozilla.sh to create a temp. dir for scratch files (where the fonts are downloaded to...) at startup which gets deleted when mozilla-bin exists... :)

[snip] The main two formats I can think of right now other than Type 1 and TT/OTF are SVG fonts and Bitstream PFRs. I don't know if Bitstream would be willing to donate their code to read and render PFR fonts, but I doubt it. SVG fonts are unhinted, but it'd be a good 3rd term project or undergrad thesis to convert them to Type 1 and have the FreeType autohinter run on them. Bitstream used to be willing to talk about it, the ball was in the Mozilla project hands last time I checked. See Comment #11 in this very bug for details/reference/contact info.

grrr... the 1st paragraph in my last submission was a quote from liam's Comment #21 - sorry for misquoting

>It's sort of like distributing GPL'd software after >removing the GPL To my knowledge, the license of fonts is stored inside them, so you'd not be "removing" it.

(or at least the copyright, if not the license)

> To my knowledge, the license of fonts is stored inside them, so you'd not be > "removing" it. Only the copyright. It woud be like forwarding files that say "see COPYING" and not including the GPL. Typically the license, a separate document (often printed on paper, not online) will say how many CPUs you can use the font on. A TrueType font, and newer Type 1 fonts, may also say whether "embedding" is allowed, and Microsoft's Weft tool uses this to deny or allow conversion of the font to .eot format, possibly after removing defintions for glyphs that don't occur on the web pages using the font. Obviously this part is not the browser's responsibility; the issue for us here is that te rules for subsetted and encrypted/encoded fonts are different than for the original font files. Anyway, sorry for long messages, I really *do* want to see downloaded fonts, but we have to remember that there are IPR issues. Downloading Type 1 or TT would be OK for testing, but the files should not be in a format whereby people can mine their browser cache (or, worse, a shared directory like /tmp) and get fonts that they should have paid for. Yes, I realise that someone could hack FreeType to save outlines, but the goal isn't perfection, it's making it not so easy that people do it without thinking about the implications. The "page info" dialogue could also display the copyrights from downloaded fonts, which would help a lot.

> what about evil font files (could a downloaded font poison other x apps?) and > what happens when mozilla doesn't exit cleanly? Depends on how you decided to set it up. What I was suggesting was that the .ttf files are downloaded to a private-to-mozilla directory and the search path for that specific directory was added to the running mozilla instance, this would work. You might be able to load these fonts directly from memory, but I can't remember off the top of my head. You may need an intermediary file. As for respecting other people's IP, I certainly have to agree. However, if the companies are creating formats for fonts that we can't use because of IP issues (oh, the irony!) then I guess we can only support the well known formats and leave it up to web authors not to violate company's and people's IP. In addition, there _are_ free fonts out there. We certainly shouldn't stop them from being used just because someone out there might stop on someone else's toes.

No matter how the legal issue is resolved, the user should always have the veto regarding downloading of font resources, regardless of font format (.eot, .pfr, .ttf, etc..). MSIE 6 for Windows gives the final word to the user regarding font download and so should Mozilla. IMHO, bug 86525 blocks bug 70132, bug 52746 and certainly bug 41250.

why should the user be asked for fonts? the user isn't asked for images, javascript or css either.

Just go over all of the Edit/Preferences... options and settings available and you'll see that the user has a lot of control over images, cookies, scripts, java, protocols, security settings, plugins, etc... and fonts as well. The user can grant or remove the ability to view a webpage with other fonts than his selected ones: that's in the UI preferences. I personally am against having a dialog popping up to ask repeatedly the same question to an user, unless that's the user's choice: that's why browsers UI preferences have in general 3 settings: yes, no and prompt. The user permission can be sollicited in MSIE 6 for windows each time a script (javascript or vbscript) is about to be loaded during page load: again, prompt is an option at the user's disposal. Wisdom has taught me to test my opinions and ideas before standing up and voicing these. In alt.html newsgroup, the following exchanges happened: Subject line: Can I allow visitors to download fonts? Date: 2002-08-30 { P1: do you really think people are going to bother downloading a font and then installing it just to view your site? I hate to break it to you but your site isn't that special P2: You have a point about the hassle of downloading fonts. That's why font synthesis was part of the CSS2 recommendation and will be part of the CSS3 recommendation when official. P3: And that is exactly I have turned off anything to do with downloading fonts in IE6. Even temporary downloads. If the "standard" fonts are not good enough for me to read the *content* of a web page then the chance that a random font chosen by the author of that page being any better is very slim. } I support bug 86525; that does not mean I don't support this bug and other CSS2 font synthesis related bugs.

Could you please take the legal and artistical discussion to the newsgroups? This is a bug on a *technical* problem. Thx.

How is this bug different from bug 52746?

RE: Comment#23 If it is a matter of getting the code to handle conversion of the PFR, is there any way we can rip the code from NS4.8 (I assume it is still available in opensource, right?), or at the least read the code to see what it is doing and rewrite into Mozilla code? Worst case we raise mozilla up to NS4.x level of support. Or is the PFR code not part of the NS4 release (one of the proprietary modules)?

baffoni@aerovironment.com: 1. n4.8 isn't open source 2. mozilla.org most likely doesn't have a license to the pfr code 3. mozilla.org almost certainly doesn't have permission to opensource the pfr code that said implementing something might be possible. expect it to be done in small steps. and it won't be done sooner if people rant or make silly suggestions. if you're interested in coding, setup a mozilla build environment, build mozilla, visit irc.mozilla.org #mozilla and ask what needs to be done. step one: * add an api to open an nsIFile and load the font for the gecko app. if at all possible the font should not appear in any other application. I'm leaning toward trying to have this implemented on windows first. --- As for loading fonts... we should have a preference wrt whether fonts should be loaded at all, i suppose it could be caps aware in case people really want to be silly. Do we really need a way to not load dynamic fonts? yes. Why do we need this? fonts can be used to crash things (xref: xbox?)

*** Bug 236615 has been marked as a duplicate of this bug. ***

I don't know, since they encouraged AOL to support Dynamic fonts (http://www.bitstream.com/categories/developer/truedoc/pfrspec.html) and because the spec is open, I can't see why there is any legal problem of developing a font engine to render the PFR.

*** Bug 239331 has been marked as a duplicate of this bug. ***

*** Bug 239331 has been marked as a duplicate of this bug. ***

I don't think mozilla devs have to worry about the reuse of copyrighted and licensed fonts any more than they have to worry about the reuse of copyrighted swf, gif, jpeg, wav, mp3 etc files. All of these file types have similar restrictions (most clipart or photos are licensed for example). Also, other downloadable media embeds fonts all the time (like flash), so there is no reason that an html page shouldn't be able to do the same. There is as I understand it a embed bit in fonts that say whether or not the font can be used to for embedding, so if there is any issue at all, that bit can be checked after a font is downloaded. I also agree that the downloaded font should not be installed on the user's machine as any other font would be, because that is like installing software (fontagraphers swear that fonts are programs). Besides that wouldn't be "embedding" that would be more like an active X control or something (downloads, installs, now can be accessed from OS and all other programs). So a temporary location for fonts (or direct from memory) seems like the most sensible solution technically. Also, if there is an issue with making type 1 or true type fonts downloadable, because of technical or licensing (font engine licensing) issues, then maybe the Open Type derived .cef (Compact Embedded Font) could be used (Freetype already supports this format). Adobe is already using CEF files (http://www.adobe.com/svg/illustrator/optimization.html) in their implementation of SVG, and Mozilla's implementation of SVG will probably rely on this at some point too. Some discussions I found on google (searched for combination of the keywords cef, svg, css, custom font), seem to suggest that Adobe intentionally made CEF very compatible with the OpenType standard so that it could be freely developed into other SVG (or CSS level 2) implementations (it's just an open type file with some tables stripped out or something like that), so starting with CEF support seems logical. Also, there is a plugin that is able to render custom type faces (an inellegant and highly restricted proprietary solution - you have to run their server addon). You can find them here http://www.glyphgate.com/. Maybe some possible implementation ideas could be drawn from their plugin implementation?

*** Bug 257984 has been marked as a duplicate of this bug. ***

*** Bug 260368 has been marked as a duplicate of this bug. ***

*** Bug 274364 has been marked as a duplicate of this bug. ***

*** Bug 276235 has been marked as a duplicate of this bug. ***

*** Bug 288564 has been marked as a duplicate of this bug. ***

The css2 stuff was updated in css3. Should that be a new bug/feature request? http://www.w3.org/TR/css3-webfonts/ It seems like the official keyword for this feature is "webfonts" btw.

No.

*** Bug 292946 has been marked as a duplicate of this bug. ***

Didn't Netscape have support for PFR fonts? I wonder why they pulled it out.

*** Bug 322075 has been marked as a duplicate of this bug. ***

(In reply to comment #20) > what about evil font files (could a downloaded font poison other x apps?) and > what happens when mozilla doesn't exit cleanly? We'd definitely have to handle using the fonts in a way that they aren't exposed to other apps, or even to other Web pages. Another important issue with evil font files is that font code in operating systems or things like libfreetype may not be particularly robust at handling malformed fonts, and could have security vulnerabilities (e.g., buffer overflows, deleted memory access, etc.); something like this would be exposing it to potentially harmful content in a (mostly) new way.

> We'd definitely have to handle using the fonts in a way that they aren't > exposed to other apps, or even to other Web pages. On Windows AddFontResourceEx with FR_PRIVATE flag will do this. When the process terminates, Windows will remove all fonts installed by the process with AddFontResourceEx. > what about evil font files? Anytime we pass data to a system library we're at risk -- should we avoid using system libraries to draw images because of the GDI exploits?

(In reply to comment #52) > On Windows AddFontResourceEx with FR_PRIVATE flag will do this. When the > process terminates, Windows will remove all fonts installed by the process with > AddFontResourceEx. And on a Mac you would probably use ATSFontActivateFromMemory() with kATSFontContextLocal. I don't think there is a way to get the Mac OS to clean up font files from disk, unless you save them in /tmp or install a signal handler to clean up after unexpected termination, in which case you could activate them from a disk cache instead.

I'm glad that priority is raised but I would like to know the reasons for this too :-)

A wishlist was opened up for this feature for Konqueror (http://bugs.kde.org/show_bug.cgi?id=128920). Perhaps a common solution could be worked out with them, Safari, Opera, and (if they want) MS IE.

(In reply to comment #55) > A wishlist was opened up for this feature for Konqueror > (http://bugs.kde.org/show_bug.cgi?id=128920). Perhaps a common solution could > be worked out with them, Safari, Opera, and (if they want) MS IE. > suprisingly it seems IE already does it (http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/fontface.asp)

@font-face proposed standard is based on IE implementation which exists since a long time.

The Microsoft support is only for embedded OpenType (.eot) files. I remember playing with that seven years ago. However, this request is for an updated proposal that can be implemented by any browser and created by any tool without restrictions. EOT files can only be created by a Microsoft tool on MS Windows. With the advent of open sources fonts with no licensing restrictions on downloading and copying, and tools like FontForge, and fast internet connections (for some parts of the world, anyways), even supporting standard TrueType fonts in web pages looks like a good prospect.

I'm sorry to add to all the bugspam, but I just wanted to point out two things; 1. eot fonts can only be made from true type fonts - possibly OpenType fonts if they have true type outlines in them, but definitely not if they contain PostScript outlines (CFF or Type 1 or whatever)). 2. It would be cool to support eot fonts if it is possible and not too much work, since then you could use the same font on IE (feature parity is a plus in my book). 3. Perhaps it would be possible to get the FontForge guys to help out, either with a patch, or with an eot converter. 4. SVG could benefit from this support, or simply providing a reliable and consistent way to use SVG fonts (not SVG CEF fonts) instead of @font-face would be awesome, and make @font-face support less necessary (though again, SVG would benefit from @font-face too). Ok I threw those last ones in there for good measure.

Exactly, I am surprised to see this discussion starting in 2001 and still on, but no open source developer has still done anything. I use fire fox myself but for reasons that are different. Normally .eot files and dynamic fonts are used either by language specific websites or websites owned by publishers in regional languages. Like I work as webmaster for one publisher who has paid for the dynamic font and uses the same for publishing the print version as well as for displaying some exclusive content on website. Surely one cannot ask them to retype the text based on .eot in fonts and styles supported by Mozilla in Firefox. It would end up as extra hours for the publisher. Now I have been forced to place an Image on website asking website visitors to USE IE and not Mozilla and other open source browsers if they want better feel of the site.This needs to be seen to bug as if you say you comply by CSS2.0 features then dynamic fonts need to be supported else Mozilla should publish this information on there Browser page that we are sorry but we cannot support Dynamic fonts, so at least, one can go for alternate solutions that solves there problem. One should look at this bug from viewers side also and not just from developers point of view.

Embedded fonts should *not* be used for internationalization issues. If you need font embedding for that, whoever runs your web server doesn't know what he's doing. This is *only* a design feature.

(In reply to comment #61) > Embedded fonts should *not* be used for internationalization issues. If you > need font embedding for that, whoever runs your web server doesn't know what > he's doing. This is *only* a design feature. > It's not that simple. In several cases, such as polytonic Greek and pointed Hebrew, system standard fonts do not properly support the language and its writing system. Either Unicode characters are missing from the fonts (for example the Greek Extended characters in the Microsoft core fonts), or diacritics are positioned all over the place (as with Hebrew vowel points in the same fonts). Firefox uses font substitution to provide some sort of solution to the first problem, but other browsers do not; there is no solution to the second. The only way to get the text in these languages to display properly with all systems and browsers is to specify a particular font which does properly support the language. Hopefully this problem will recede as improved fonts are bundled with systems, as apparently with Windows Vista, but it will be many years before this issue goes away.

> The only way to get the text in these languages to display > properly with all systems and browsers is to specify a particular font which > does properly support the language. Regarding polytonic Greek and pointed Hebrew, have you tried with Arial Unicode MS (ARIALUNI.TTF) which is available and installable for Windows system ? Arial Unicode MS is considered as "a complete Unicode font." http://support.microsoft.com/kb/287247

(In reply to comment #63) > Regarding polytonic Greek and pointed Hebrew, have you tried with Arial Unicode > MS (ARIALUNI.TTF) which is available and installable for Windows system ? Arial > Unicode MS is considered as "a complete Unicode font." > > http://support.microsoft.com/kb/287247 > Yes, Gérard, I have tried Arial Unicode MS. It is by no means "a complete Unicode font" as it supports only Unicode 2.1 whereas Unicode is not up to version 5.0, and I think Microsoft has made a deliberate decision not to update it because it has better strategies for proper Unicode support. Although it may offer glyphs for all of the Hebrew characters in Unicode 2.1 (and the ones added more recently are very rare), it does not have the intelligence to combine the vowel points and accents except in the very simplest ways. I think its only advantage over regular Arial for Hebrew is that it provides glyphs for the accents, but these accents do not combine at all with base characters. If you are not happy for your name to be written Ge´rard, you will understand what Hebrew readers will think of any text in Arial Unicode MS, or for that matter in any of the Microsoft standard Hebrew fonts.

Using CSS to load a custom font for the sake of compatibility is silly, because there will always be browsers which don't support @font-face. This feature is for the sake of presentation, to offer a different look for browsers which are nice enough to support this feature. Ultimately it's up to the browser to discover what characters can't be printed in a font, and to properly substitute another font if it has a better one. And of course Mozilla can already do that much. Naturally some user agents won't be able to view some characters (e.g. your mobile phone probably doesn't have Han code points unless it was actually sold in a country which uses them) but that's an accepted part of life.

(In reply to comment #65) > Ultimately it's up to the browser to discover what characters can't be printed > in a font, and to properly substitute another font if it has a better one. In a perfect future world in which Unicode coverage is complete, and in which people never want to refer directly to glyphs rather than to characters, and in which mathematicians stop inventing symbols, maybe people will no longer need to use their own fonts. Today there are still many Web pages that you can only see if you download particular fonts, and places where there are incompatible fonts, so to go from Web page to Web page in the same language you must alternately install and uninstall different fonts. Having said that, presentation is of course important. Text is the user interface of the intellect, and fonts are the implementation of that user interface. In some cultures there are very strong associations with particular font styles, so that the font becomes an important part of the content.

"Using CSS to load a custom font for the sake of compatibility is silly, because there will always be browsers which don't support @font-face. This feature is for the sake of presentation, to offer a different look for browsers which are nice enough to support this feature." Not completely as I run into the problem of missing characters on computer systems frequently. The letters Yogh and Wynn are a good example of poorly supported characters. Not even all of Deja Vu's fonts support these characters. Yet they are ones that I use frequently. That is why I am supporting this feature request.

Your site has to work without CSS. Sites are also supposed to be developed such that missing CSS features degrade gracefully. Full stop, end of story.

Trejkaz, to say, "Your site has to work without CSS." is not an argument against supporting CSS features. I don't think Mozilla has support for SVG fonts either yet, and it should.

Liam, I don't believe he was against the feature, he was against using the feature for handling font compatibility issues, which I agree with. That said, the @font-face feature in CSS is something I was hoping would have made it into gecko a long time ago. Sadly, it's an extremely impressive tool that's been missing for too long. I would like to see an even higher priority and a set milestone target for @font-face, if possible.

This bug has been opened in 2001. Why hasn't anyone commenced work on this?

Because there's more important stuff for people that are able to do it? Anyway, I'm thinking whether it would be easier if SVG fonts get implemented (for SVG, bug 119490) and then WebFonts (@font-face) with SVG fonts. This will free us from dealing with various hacks needed to use system font api for that purpose but has the following disadvantages: * SVG fonts may not be expressive (like OpenType) enough for some scripts (indic?). I'm not sure about this one. * slower - system font drawing will always be faster. Using GPU accelerations will definitely help about this. This depends on cairo library. * no hinting (but with modern displays with increasing dpi this is not so crucial) http://weblogs.mozillazine.org/tor/archives/2007/04/smil_animation_and_svg_fonts.html has some info.

Firstly I'll admit I can't contribute anything to the application coding/development/implementation side of things. However, from a networking point of view I think the font-download feature (whatever format the font files are) should follow the same rules as other HTTP content/resources in that the files should be cachable, allowing HTTP headers to dictate how the browser cache treats font files. I'm not saying the font files have to live in the main cache system, they can still be seperate (that's an implementation issue). All I'm saying is that font files should be treated like CSS, JS, and image files with regards to HTTP. The main thing would be to support conditional GET requests and handle the corresponding HTTP 304 Not Modified responses. I assume that's simpler to start with than full blown Cache-Control handling. On a personal note, as a web developer I'd very much like to see this bug result in a usable feature. AS I'm sure most of you know, the ability to have custom fonts in browsers (in an open source, cross-platform/cross-browser way) has been missing or tricky for some time. There are a significant number of projects where the visual designers *insist* that a specific "look" for text is needed (and I can appreciate the value of this). However, at present the only reliable way to do that has been to use some form of image replacement, which brings accessibility and usability issues (Images aren't text, so can't be synthasised by a text-to-speech engine. One example of usability problems is that the text isn't selectable or resizable - for those that know a bit about modern image replacement techniques yes there are methods to produce scalable/resizable text essentially as an image to allow custom fonts (such as sIFR), but that requires things like javascript to be available, which comes back to accessibility). So, my point being that allowing fonts and text to work properly (allowing designers to have whatever font they want, while still only using plain text in the source code) isn't just a nice visual/design feature, it impacts accessibility too. I suggest that this warrents a status of something beyond "would be nice to have" to an important feature which would remove the need to develop and use ever more complex image replacement techniques.

I agree with Lee's comment about the importance of the ability to download fonts. In adition to being very important for accessibility and design, this is perhaps the missing piece that would allow web browsers to be able to be the interface for applications. Imagine all of the text editors for content management tools, for Google's and other word processing applications, etc. being able to use more than a handful of fonts now possible. The work that Eric Meyer (http://www.meyerweb.com) and the Zen Garden folks work on to make CSS a true powerhouse for design can truly be realized. Instead we are stuck with Flash plugins and unwieldy gif and jpg workarounds. This "bug" should be about the top feature for the 3.0 version. It would push Firefox as the premiere browser for a long time.

Other points are reducing page weight, text is far smaller than images. User style sheets are able to over-ride custom-fonts. Thinking about accessibility beyond people with particular needs, obviously accessibility is more than that. Having fully accessible pages would mean improved google rankings while still allowing fussy visual designers to control exactly how the otherwise plain text should look. As for promoting firefox as the premier browser (if it had this feature), I think it could do more, if it seriously improved firefox's adoption rate, as well as encouraging site authors to do things properly (styled text rather than images) this could do wonders for the standards movement, and finally give MS a good kick up the **** it needs (they hate to not be the "leading" product).

That previous comment should have read "they hate not to be the *only* product" :-) Given the comments by moz developers so far (or rather, lack of them) I would expect to see this feature in Opera and Safari first, so I don't think it will help FF adoption at all.

The current trend in web design averts from using embedded fonts, mainly due to the fact that this feature is not available on all browsers. Furthermore it provides complications on how each browser will perceive to render these fonts, as each browser might render them different, as there is no standard on how to go about this, thus many web developers will avoid this feature even if implemented. But, what would be beneficial is for XULRunner based application developers, where fonts can be embedded into the application without the need to install them on the target platform.

Anand Aiyer - given the popularity of SIFR I think it's clear that there's a huge demand for font embedding in browsers. Whether adding that feature into Firefox or not would increase it's market share I don't know, but it would make a huge impact on the web, ad you're be able to use WEFT for IE, and another method for standards-based browsers. Lee Carré - I find your comment regarding 'fussy visual designers' both insulting and short-sighted. Typography is quite an old craft and there's nothing fussy about wanting to use high quality, legible fonts in your designs, it will dramatically improve the quality of text on the web.

(In reply to comment #76) > That previous comment should have read "they hate not to be the *only* product" :-) haha, probably true! I remember not too long ago (2006?) that some MS exec (I can't remember his name, have a look in the WaSP news archive) said something to the effect of "MS has won the desktop, we won the server, and we will win the web". You can imagine the response from the standards advocates! I was quite horrified myself, and from then on, refused to use workarounds for IE's short comings. If users want to see the full version of a site (not just the content) they need to switch to a more capable browser (such as Firefox) I'm afraid - IE is holding the web back. > Given the comments by moz developers so far (or rather, lack of them) I would > expect to see this feature in Opera and Safari first, so I don't think it will > help FF adoption at all. Sadly also probably true. I was trying to give them some incentive *wink* From my point of view, I know I'd probably favour the browser which implements this first, because I can then do away with all those damn images replacing text in inaccessable ways.

(In reply to comment #78) > Anand Aiyer - given the popularity of SIFR I think it's clear that there's a > huge demand for font embedding in browsers. Whether adding that feature into > Firefox or not would increase it's market share I don't know, but it would make > a huge impact on the web, a[n]d you're be able to use WEFT for IE, and another > method for standards-based browsers. Very much agree. The root problem is the (lack of) availability of a cross-browser solution. But the idea is highly desired. The simple fact of having to create a new image to change any detail about a text-image is a huge draw-back. Doing things properly (plain text styled with CSS) allows far greater flexibility, both font and content (ie the actual text) can be changed much more quickly. (In reply to comment 77) > Furthermore it provides complications on how each browser will perceive to render > these fonts, as each browser might render them different, as there is no standard on how to > go about this, thus many web developers will avoid this feature even if implemented. That's the flexible nature of the web. You never know how things are going to be rendered on a user's machine. They can disable CSS, JS, images, and all manor of other things. Fonts are no exception. Besides, how would custom fonts be any less predictable than the existing methods of only being able to specify common fonts? Surely the ability to actually provide your own fonts (to ensure they've available) means things are actually more predictable? But still, a user can configure their browser to ignore anything the author specifies, so this whole issue is rather a moot point. > Lee Carré - I find your comment regarding 'fussy visual designers' both > insulting and short-sighted. Typography is quite an old craft and there's > nothing fussy about wanting to use high quality, legible fonts in your designs, > it will dramatically improve the quality of text on the web. Good point, I appologise. To clarify I'm not against high-quality design at all; it's something I actually respect because I can't do it myself. I'm all for high-quality, that's why I'm commenting on this bug. My real point was about designers not understanding/respecting/appreciating the limitations of the medium. I agree that it's nice to have custom fonts. But until such a feature is implemented, they can't be achieved in an accessible way (eg, they won't appear if say, JS or images are disabled; depending on the replacement method). The web, like any medium, has limitations. Much the same as the limitation of a magazine to contain a video on it's pages. My critacism is of designers who don't take this into account, and *demand* this that or the other (usually with the backing of management, who understand visual design better than accessibility). So in summary, I agree entirely that this is a Good Thing™.

Webkit now supports font-face : http://webkit.org/blog/124/downloadable-fonts/

(In reply to comment #81) > Webkit now supports font-face : http://webkit.org/blog/124/downloadable-fonts/ > Would be nice to support the vision Hakon Wium Lie's proposal as per the article in A List Apart (http://www.alistapart.com/articles/cssatten) That's what seems to have motivated hyatt. From the date of the article in ALA to the update of webkit, just over a month has gone by. If someone had that much time and picked this one up now, we could have this for Firefox 3.0. Then it would be only IE holding us back again, but we are kind of used to that ;)

(In reply to comment #82) Full ACK!

Gecko 1.9/Firefox 3.0 has feature freeze since months so it's not possible for Firefox 3.0.

G 1.9/FX 3.0 has feature freeze but it might be good to consider an exception for this: a) FX 3.0 had a nice push forward in terms of accessibility within browser. @font-face offers to web artists ways to embellish their design without breaking accessibility. b) If an agreement can be reached between opera/apple/mozilla to commit each company into implementing @font-face in their next major version (opera 9.5, firefox 3.0, safari 3.0(?)), it could have a real impact in browser market % for these 3 browsers.

Exception can't be even thought of without tested code.

There is no way this will go in for Gecko 1.9. The security implications of downloading a file off the net and just passing it off the the OS scare me a lot. Although the quick implementation won't be difficult, this needs to be thought through very carefully.

How would the security implications be any different from downloading an image file or a .ICO file and passing that off to the OS?

(In reply to comment #89) > How would the security implications be any different from downloading an image > file or a .ICO file and passing that off to the OS? Decoding and display of ICO files is handled by Mozilla code, images are decoded before being displayed via calls to the OS: http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/bmp/ I don't think the issue here is adding support using a font that is downloaded. The more difficult issue is validating that the font is not malicious, as both Stuart and dbaron have mentioned. Both TrueType and OpenType fonts include instructions that are interpreted by the font rasterization engine at a relatively low level within the OS. For an example of the kind of nastiness that a font can bring with it, consider the fonts described here: http://cg.scs.carleton.ca/~luc/opentypecrash.html Given that this page is dated 2003 by guess is this has probably been fixed by now but it's a good example of the kind of attack vector folks are concerned about. roc has proposed working around this by including FreeType with Mozilla so that we have the ability to control the code and assure that downloaded fonts are validated before rasterization. But that's a much bigger task than simply enabling the use of downloaded fonts. Support for dynamic fonts is a really fantastic idea but we need to be sure that downloaded fonts cannot be harmful to a user's system. One other thing to note is that Microsoft is currently in the process of opening up the Embedded OpenType format (eot), postings on the W3C CSS Style mailing list indicate that this is currently under legal review. Maybe there are features of this format that allow easy validation?

An easy solution to TrueType instructions problem is to just strip them before passing the file to OS. It is just one more processing if my suggestion to rename the font before passing to OS is used: bug 52746, comment 137. SVG Fonts don't have hinting so they are "safe" in this regard, and they may actually be much more easier to implement, given that OS is not involved at all but Mozilla SVG renderer is used: bug 119490.

(In reply to comment #90) ... > roc has proposed working around this by including FreeType with Mozilla so that > we have the ability to control the code and assure that downloaded fonts are > validated before rasterization. But that's a much bigger task than simply > enabling the use of downloaded fonts. > Would pango help here? This renders fonts without going through the OS, and is already supported in some way according to bug 214715, see also bug 251219. In reply to Ognyan's comment 91, stripping TrueType instructions is likely to disable any kind of complex script processing, kerning etc etc. This would largely defeat a major purpose of supporting @font-face which is to support fonts with unusual features.

I'm 99% sure that stripping hinting instructions won't affect any OpenType feature, only rendering will be uglier when font size is small.

stripping hinting isn't enough as any malformed part of a font could cause the OS to get upset. pango does not parse/render text, it uses the platform parts to do this. we could use freetype to do validation after a security audit.

Adding freetype could have other uses, besides just security uses. When you rotate fonts in SVG in Windows, they currently look horrible, at least on Windows. Freetype could probably be used to help with that (by using unhinted rendering for rotated fonts, or some other rendering method). Exposing some of these hinting properties through some -moz- css extensions could be useful too (so that you can turn it off if needed - Adobe's Flash IDE, and Flex currently expose some of those kinds of controls for their font hinting/antialiasing in their CSS implementation). Hinted text is great for reading large blocks of text on screen, but it's not always (well not even usually) good for type used as graphic elements. In addition, allowing SVG encoded glyphs to be used in HTML document contexts would be great. This would be useful for touchy higher end font producers, since they could then have a format that could subset fonts, and at the very least make it difficult to re-use the fonts for other purposes. It's the same idea with font-obfuscation in pdfs, and custom formats in swf files - they make it hard enough to get at the raw font files, which keeps people honest, and helps type designers feel secure enough to license fonts for use in embedded situations (this may or may not be a real concern for tool makers - however it is at least a side benefit of using an SVG based container for HTML font embedding). Just out of curiosity, if you have the functionality to use SVG glyphs, what would be involved with converting ttf, and otf fonts to SVG in memory, and just using that? Sorry to get too off topic.

Embedding original TrueType & ttf OpenType fonts through CSS @fontface is apparently now supported in Opera & WebKit - see e.g.: <http://webkit.org/blog/124/downloadable-fonts/> <http://tekkie.flashbit.net/css/webkit-is-leading-the-run-for-css3> <http://www.alistapart.com/articles/cssatten> Perhaps in response to this Microsoft are apprently now offering to give their .EOT ("Embedded OpenType")font format to the W3C as an "open format". see: <http://blogs.adobe.com/typblography/2007/11/web_fonts_1.html> Since EOT fonts offer very little extra in the way of security - the only real advantage I can see is that creating EOT fonts allows for subsetting. Anyway it seems cross platform font embedding is starting to happen and, one way or another, I guess it is inevitable. Re IPR issues - TrueType fonts and OpenType fonts contain a License field - so text of a font license can be embedded right in the font so there is no need for a seperate file. Of course the user needs some way to display this information. If original font files can be "embedded" or linked it of course makes it quite easy to for font creators to discover illegitimate use of their fonts. Original Fonts "embedded" on websites would be very public and verifiable. This part at least might be seen as an advantage by font vendors. Commercial fonts would probably need re-licensing in order for web developers to leagally embed them on web pages. The same is of course true for copyright thext or images. - chris

Is this a duplicate of bug 52746? Given that this bug refers to the CSS3 @font-face property, perhaps this one is better worded than 52746, in which case that earlier bug might be considered a duplicate of this one.

I asked the same thing in Comment #33.

@font-face support should be added to Mozilla 1.9. I vote for this. I have made a plugin extension (Windows platform only) that loads an .eot font in your web page using Windows API. This plugin works in FireFox 2.0.0.x but interestingly enough it is not working in FireFox 3 Beta 3. Visit http://pakdata.com/products/pdms-weft-plugin

(In reply to comment #100) > I have made a plugin extension (Windows platform only) that loads an .eot font > in your web page using Windows API. This plugin works in FireFox 2.0.0.x but > interestingly enough it is not working in FireFox 3 Beta 3. Visit > http://pakdata.com/products/pdms-weft-plugin > Kashif, is there a published spec for .eot fonts available? - Chris

(In reply to comment #101) > (In reply to comment #100) > > > I have made a plugin extension (Windows platform only) that loads an .eot font > > in your web page using Windows API. This plugin works in FireFox 2.0.0.x but > > interestingly enough it is not working in FireFox 3 Beta 3. Visit > > http://pakdata.com/products/pdms-weft-plugin > > > > Kashif, is there a published spec for .eot fonts available? - Chris > I dont think so, I only used embed API (t2embed.dll) to load eot files.

This is affecting Acid3 results, so we should uhm, like fix in the very near future. That's mainly because uhm, Firefox 3 is like almost in RC, so like, yeah. Seriously, if we want this in 1.9, we need to hurry it up. b5 is baking. I guess maybe we wont make it. So, this is gonna be in Gecko 2. Unless some code falls out of the sky and lands before the first RC.

Um, yeah, so like, we feature froze like forever ago. This won't be in Gecko 1.9 and won't be added to a release after that until significant work can be done to ensure security of downloading and parsing fonts from the net.

darn

I don't think this has been mentioned yet, but of the group: Firefox, Internet Explorer, Opera and Safari; Firefox is the *ONLY* browser that does not yet have at least partial support for @font-face... (granted, some of them only in development versions, but still) Frankly, people - this is embarrassing. I'm not the worlds most experienced developer, but if ANYONE can offer to answer questions I have on the internals of the codebase in general, and specifically the nsCSS* part, I am willing to put in a great deal of time and effort to write and test this feature.

Stuart Parmenter wrote: > ... > This won't be in Gecko 1.9 and won't be added to a release after > that until significant work can be done to ensure security of > downloading and parsing fonts from the net. Please explain just what are the security risks in fonts? (or the potential security risks?) I've been making and looking at fonts for many years, and while years ago I encountered one or two badly made or highly complex fonts which could hang a couple of MS Windows graphics applications if you were using particular graphics cards & drivers, I'm not saying they dont exist - but I've never encountered a font that posed a threat. Is this real or potential danger equal to or greater than than diverent kinds of graphics, sound or video files or of svg, vrml files etc? Since font file formats are very well documented, and all the widely used font formats have been around for years, it should also be reasonably straightforward to tell whether a file is a font, or something else masquerading as a font. - Chris

(In reply to comment #107) > Please explain just what are the security risks in fonts? (or the > potential security risks?) Parser, of course. It can have buffer overflows of all kinds and when dealing with raw files off the net, every single one of them is likely to be exploitable. Such code will definitely require strict security review.

It's worse than that. Truetype actually defines bytecode programs that can be used to compute hinting. There's a little virtual machine in there.

Has the W3C CSS working group resolved the issue regarding .ttf fonts versus .eot fonts? If not, I think it's premature to expend any resources on implementation.

IE already supports .eot, Safari and Opera already support .ttf (and .otf?). Since it's going to be a lot of work pretty much from scratch anyway, why not just implement both? The same one library would presumable provide validation in some form for both formats (freetype). Additionally, I'd like to resuggest using SVG glyph as an embedded format. It's currently possible to subset and embed fonts as SVG glyphs (I'm not sure of Mozilla's status on utilizing that in SVG though). It'd be great to be able to embed fonts using that technology as well as either eot or ttf. I don't want to start another long thread on licensing, but in the interests of coming up with the best tool I'll say that allowing embedding only .ttf is not optimal, because high quality font makers will not likely ever provide licenses that allow that kind of "redistribution" as they see it. I do believe they would allow "embedding" in web pages, a concept that is easier to explain if the fonts are subsetted, and converted into some format (like EOT or SVG glyphs) that cannot be easily installed on the end users' systems. This would provide protection for their IP that is on par with current embedding solutions (like Flash or PDF), protection that is strong enough (to end users at least) that it would allow them to license their high quality fonts for "web page embedding", which would substantially increase the usefulness of this tool.

(In reply to comment #107) > Please explain just what are the security risks in fonts? (or the > potential security risks?) Please see comment #90 above, particularly the link he gives. I remember when that hit Bugtraq; I tested it out and bluescreened my computer.

Grab this for now, will start investigation once blockers are cleared.

@Christian Sonne: I can hire you to implement this feature if you think you can do it :-)

Re comment #114: Once again, an old bug has been closed as a duplicate of a newer bug. Is this an attempt to improve the statistics on how long bugs remain unresolved?

(In reply to comment #116) > Re comment #114: Once again, an old bug has been closed as a duplicate of a > newer bug. Is this an attempt to improve the statistics on how long bugs > remain unresolved? Nothing to do with stats, just better to consolidate discussion in one bug. Unless you feel these two are distinct somehow?

(In reply to comment #116) > Re comment #114: Once again, an old bug has been closed as a duplicate of a > newer bug. Is this an attempt to improve the statistics on how long bugs > remain unresolved? I think it's more to do with the fact that there are interesting points of discussion on this bug and the other one is pretty much stagnated.

As I've had private inquiries about this, I'd like to confirm I will interview anyone who feels they can implement this feature :-)

(In reply to comment #119) > As I've had private inquiries about this, I'd like to confirm I will interview > anyone who feels they can implement this feature :-) > /* Basically, I think it’s not difficult to get a font file from network and make it available to a text layout engine (especially if Freetype is around), I did it already. Now, the difficult comes that it has to be done in Mozilla-*! Even grabbing the source code is over complicated here :) So, I’ll take some days to read the source & related threads at http://lists.w3.org/Archives/Public/www-style/ before I decide if I can say : "I feel I can implement this feature". */ Now the actual question : "Is there a plan or at least an idea of how you want it to be implemented that one who is willing to write the feature should base his work on?"

FYI, yes @font-face as shown on http://www.alistapart.com/articles/cssatten is implemented in Safari 3.1 on OSX and Windows. But no, on this day, it is not implemented in Opera9 current released version : http://www.opera.com/docs/specs/opera9/css/ The problem is even further embarassing is that latest Safari is also implements the SVG font : doh ! Those two things makes a huge visual difference on website :( Plus, as a remember Both of these are part of Acid3. Scores of current releases version on Win32 are : 75/100 for Safari 3.1, 54/100 for Firefox 2.0. And upcoming Safari and Opera are anticipated to be near 100/100 ! Guys, is there nobody here with the right skills to implements this ? Because IMHO, by not implementing this, there is a risk that Gecko(Firefox) momentum will be weakened, because some of the early adopters and power users (developper, graphists) will move to Webkit(Safari) as reference platform and no more Firefox. Gecko/Firefox need to stay at the bleeding edge of CSS.

(In reply to comment #121) This feature is under development. As I start to work on things I'll post patches. Comments on those are most welcome but more general discussions are probably better suited to the mailing lists.

Brad Lassey forwarded this patch that he put together a couple years ago.

It is good to hear that this feature is under development. When implementing this feature the developer can load .eot files using 't2embed.dll' (TTLoadEmbeddedFont). This dll will be on user's computer if they have IE installed. For other environments, the developer can easily load .ttf files.

Which of the many mailing-lists do you suggest? I'd like to follow the development process closely. > This feature is under development. As I start to work on things I'll post > patches. Comments on those are most welcome but more general discussions are > probably better suited to the mailing lists.

(In reply to comment #125) > Which of the many mailing-lists do you suggest? I would suggest the www-style@w3.org mailing list: “This mailing list is for /technical discussion/ on Cascading Style Sheets (CSS) and its specifications. All posts to this list must be about the development of the CSS specification itself. This list is also the preferred place for discussing working drafts that are published by W3C’s CSS Working Group.” You can find the list archive at <http://lists.w3.org/Archives/Public/www-style/>. The drafts that you’ll need for discussion are: CSS3 Web Fonts Module: <http://www.w3.org/TR/css3-webfonts/> (2002-08-02) CSS3 Fonts Module (Editor’s Draft): <http://dev.w3.org/csswg/css3-fonts/Fonts.html#font-resources> (2008-05-23) * * Apparently, the Web Fonts module was merged into the Fonts module. By the way, someone might want to update the bug’s “URL” field to reflect one of the more up‐to‐date drafts. The CSS2 specification hasn’t been worked on since 2003-07-24 (prior to the latest Web Fonts module draft) considering the last errata revision date.

See also the Microsoft submission to W3C of the Embedded OpenType (EOT) format, together with MicroType font compression from Agfa/Monotype, http://www.w3.org/Submission/2008/01/ This implementation of CSS Webfonts is currently supported by Internet Explorer (and has been for years of course). If this becomes a W3C Recommendation, Microsoft and Monotype have both indicated that they would grant a royalty-free licence to relevant patents. An advantage of EOT is that it meets the needs of many font vendors, and of many corporations and organizations that are unwilling to put their fonts on the Web unless they are restricted by domain. Yes, the encryption can easily be defeated, but doing so puts things in a clearer situation for legal action. I don't know whether EOT supports the Type 1 outline format of OpenType, or only the TrueType -- we've only recently published this submission and I have not been able to review it in detail.

I believe that EOT is incumbered by patents held by Bitstream and recommend Mozilla not implement it until the patent threat posed by EOT is clarified.

(In reply to comment #126) > > Which of the many mailing-lists do you suggest? > > I would suggest the www-style@w3.org mailing list: Actually I meant which _Mozilla_ mailing list, a question that arose in scope of John Daggett's message ("This feature is under development. As I start to work on things I'll post patches. Comments on those are most welcome but more general discussions are probably better suited to the mailing lists.") I was not so much interested in the css3 developement process, but the progress the Gecko engine does in supporting @font-face.

You probably want the dev-tech-css mailing list then. Alternatively, you can use the newsgroup with same name (dev.tech.css) on news.mozilla.org

(In reply to comment #130) Great, thanks, that's what I meant! :-)

Set this to P1. Daggett, please change if this doesn't make sense.

I'm excited about my shiny new Firefox 3, and looking forward to @font-face support. Thanks for all the developers' work. The mentions in this thread of Microsoft's EOT technique seem confusing, since it was an approach to "embedding" fonts that (as I understand it) doesn't relate to @font-face. By the way, some great typefaces are specifically available for embedding in websites, including the Larabie fonts: http://www.princexml.com/fonts/larabie/index.css and those from Jos Buivenga: http://www.josbuivenga.demon.nl/ ( License: http://exljbris.wordpress.com/2008/03/19/license-update-ii/ )

EOT is the mechanism used by Internet Explorer to support @font-face. It has been submitted to W3C for possible standardisation in the future.

(In reply to comment #128) > I believe that EOT is incumbered by patents held by Bitstream and recommend > Mozilla not implement it until the patent threat posed by EOT is clarified. > Dave Crossland Isn't EOT Microsoft's font embedding technology and Bitstream's PFR? Microsoft's Embedded OpenType (.EOT) Font Format Submission Request to W3C: <http://www.w3.org/Submission/2008/01/> MS Embedded OpenType (EOT) File Format: <http://www.w3.org/Submission/EOT/> Monotype MicroType Express (MTX) Font Format: <http://www.w3.org/Submission/MTX/> - chris

Chris, software idea patents are not linked to implementations. Any web-font DRM system is encumbered by patents help by Bitstream in my opinion. I note that Bitstream isn't a W3C member in the CSS-WG, so the patent protection the W3C offers does not apply here.

Montgomery, the use of the word "embedding" in this context is a propaganda term designed to avoid the term "DRM" - I suggest using the term "font linking" rather than "embedding."

(In reply to comment #137) > use of the word "embedding" in this context is a propaganda > term designed to avoid the term "DRM" Not sure what you mean by "propaganda term"; but yes, I'd like to avoid DRM, and just use those fonts with licenses that allow it. > - I suggest using the term "font linking" rather than "embedding." Okay, let's call it "font linking". Whatever it's called, support for @font-face will be wonderful.

I think @font-face is fundamental for next firefox release (3.1) because it allows web developers to be very very more creatives about website development.

Can anyone confirm that this proposed solution is going to support TTF fonts? If not then it's useless.

There are security issues with TTF font linking, explained in comment #90. I think that supporting SVG fonts for font linking is the most practical direction: it seems to be substantially easier that TTF/OTF support: no platform-specific code and mostly using other parts of Gecko. On the negative side, probably not sufficient for complex layouts (Indic and others) and no sharp hinted images for smaller sizes. But it would be great progress anyway, and designers will love it.

I, like most users of such a system, will have a very specific font in mind and SVG formats for that font are just not available and will likely never be available. TTF is all I have and If you don't support it then your browser is useless to me. TrueType support in part of the spec at www.w3.org and security and the other issues you mention are just implementation details. For me and plenty of others I'm sure supporting half the spec will be of zero use, and you may as well not bother. For a system like this to work you need the fonts to be available in the supported format, if you are only going to provide SVG then the system will be as useful as a Betamax video recorder, ie. great quality but never mind that nothing is available for watch on it.

Whether it's TTF or SVG glyphs is almost a non-issue. You can currently embed ttf into SVG using a number of tools, and that embedded font can be used in the SVG - there's no reason that can't be extended to HTML (after implemented in Mozilla). The minute FF has support for SVG fonts in HTML pages, you'll see converter after converter hit the streets. This only leaves the legal issue with "embedding" vs. "linking". If you have to convert the font into an SVG format, then you are essentially embedding, and then linking. This is more of a non-issue than the above technical problem, because this isn't a technical problem. This implementation does not need to be concerned with any legal problems with embedding/linking fonts in webpages, any more than it needs to be concerned with legal problems with embedding/linking, text, images, sounds, music, etc. that is also all copyright protected. There are plenty of public domain, or publicly licensed text, images, fonts, videos, music, etc. The legal issues involved with embedding are not an issue with the implementation. It doesn't even need to be considered.

While the font licensing issues are probably of no direct concern for Mozilla, for this enhancement to be useful web designers need to be able to "embed" fonts without breaking the license of those fonts. The reason it may be good to support the EOT font format is that this format offers some (limited) degree of intellectual property protection and so some commercial font vendors may allow "embedding" fonts in this format but not embedding of the the original TrueType / OpenType font file. For example EOT fonts should only work from a particular domain, may be sub-setted, and should only temporarily installed on the client ~ dependent on the flags in the original (TTF / OTF) font file. Of course for GPL or OFL licensed fonts this is not an issue since the original (TTF/OTF/PFB ...) font files may be embedded. - chris

(In reply to comment #136) > Chris, software idea patents are not linked to implementations. Any web-font > DRM system is encumbered by patents help by Bitstream in my opinion. I note > that Bitstream isn't a W3C member in the CSS-WG, so the patent protection the > W3C offers does not apply here. Dave, What particular "software idea" patent(s) does Bitstream claim to hold on font linking / embedding? Im not a lawyer but if there is such an "idea patent", IMO the patent claim seems to be pretty frivolous ~ in that how is linking a font file to an HTML file any different to linking to other media or data files such as graphics, sound, flash or java files? Once someone had the idea of linking any type of media file to HTML linking other types of media files would seem to be *obvious* and hence it would seem that there is no real "invention" or new idea involved. Otherwise every time someone comes up with a new media file format someone can claim they have had the idea to link it to HTML. If there is such a patent and if it had any real basis one would have expected Bitstream to have gone after Microsoft for WEFT / EOT font embedding which has been supported in IE for many years. Are Microsoft paying Bitstream a license fee? - Chris

Christopher, "some (limited) degree of intellectual property protection" means DRM, which I think would be an awful thing to introduce to the web. If a font editor allows people to open EOT fonts and edit them, will its authors be sued or scared into no longer developing that program? I note that Silverlight and Flash both permit web designers to include fonts that can be easily extracted without any DRM - and Silverlight even ignores the TrueType DRM flags. I agree that it will be useful web designers need to be able to "embed" fonts without breaking the license of those fonts, but that means the license of the fonts must allow redistribution of the fonts, not that the web ought to have DRM. Additionally, please consider not using the term "Intellectual Property" because (a) it lumps together a few laws which have nothing in common in all their important details and (b) it suggests that the monopoly rights the laws set up ought to be thought about like property, which is also misleading. Instead, please be specific about which law you are talking about - here I suppose you mean copyright law.

The benefits of EOT mentioned in Comment #144 can be echoed for SVG glyph fonts (minus the domain restrictions). Also note (it hasn't been mentioned here before) that EOT fonts don't always perform as well as we'd like (in IE at least) - though this may a limitation of the use of postscript outline fonts with WEFT (and might be due to cleartype) and not the format itself. EOT made from postscript fonts tend to be blurry and unusable. Some fonts (TTF) work just fine though.

Honestly, I thought EOT was a dead proposal, and am surprised to see anyone promoting it. "DRM ... would be an awful thing to introduce to the web." Agreed. There already fonts available for @font-face linking (e.g. the Larabie and Jos Buivenga collections, and free fonts), and that's before the more popular browsers support it. Professional designers already make sure that their logos, stock images, illustrations, any music or videos are properly licensed. Why treat fonts differently?

Stop spamming this bug; take your discussion elsewhere.

All @font-face related work is wanted1.9.1, P1

Thanks, John. Marking.

why did you minus it if it is wanted?

Mistake from Damon.

Yep. Meant +.

You missed it again...

Yep. Meant +.

> "DRM ... would be an awful thing to introduce to the web." The W3 specification specifically states "Downloaded fonts should not be made available to other applications." I take this to mean that the font should only be used withing the page, and not be made available outside of the browser on the client system. One would like to be able to assume that the website owner has properly licensed all of the content on his site.

Whether a site contains plagiarism is impossible to verify for a computer program and has nothing to do with support for advanced document formatting. Sites can currently contain stolen images, music, or indeed text. So if one argues that support for custom fonts would promote unauthorized use of copyrighted fonts, it's the same argument as saying that the existence of the internet promotes unauthorized distribution of copyrighted articles and books.

Exactly my point. And the browser doesn't have to if it implements the specification as written. No copies are made that can be used outside of the browser, the font is limited to displaying the content of the web page.

It's always possible to read the page source and find the font's URL and download it directly. And I think caching the font on disk would make a lot of sense. In my view what is meant by: > "Downloaded fonts should not be made available to other applications." ...is that the font should not be put into the system font paths, where it may interfere with other apps' fonts.

This is a hot request. There are now 156 votes for this feature. Internet Explorer and Safari have it already, so the web is ready for web fonts. Do you have any information about plans or even progress? Many thanks!

The relevant comments in this bug (which are getting harder to find amongst the noise thanks to ones like yours) and the bugs marked dependent on this one answer your questions. Please don't spam this bug if you don't have a contribution to make to it. All it does is annoy people and make it harder to find the important posts in it. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

(In reply to comment #16) > > Note that there are intellectual property issues here. > Sure. But these IP issues are certainly not an issue for mozilla, but for the > website owners. Please, there are enough legal issues around mozilla, don't add > this one... > > So technically, there are three issues here: > 1. Extend the CSS parser to recognize the src attribute of font-face > descriptors, and download the font. > 2. Make the downloaded font available to the rendering engine. > 2. Add support for other font formats. > > While (1) is certainly almost trivial, my question in comment #13 was whether or > not (2) is easy to do for supported font formats. If it is, then (3) shouldn't > completely inhibit the implementation of this feature. Would the difficulties of implementing @font-face with the exception of the src attribute with url, until the src attribute with url can be implemented be worth the trouble of doing it? This way we would have at least partial support of sites that use @font-face, minus the src attribute with url. But having src with local still. For example these at-rules: @font-face { src:local("Times New Roman Bold"); font-weight:700,600; font-family: "Times New Roman",serif; } ^ above would allow Firefox users to still be able to see pages that would use similar at-rules and later use font-family:"Times New Roman Bold"; in a selector. @font-face { src:local("Example Font"), url("http://fontsite.example/example.font"); font-family:"Example Font",sans-serif; font-style:italic; font-weight:700,600; } ^ Even without url support, we can still at least see the author's intentions to have the font be bold and italic. ----------- And with this we could also support the some of @font-face's CSS3 capabilities, like in the example at http://www.w3.org/TR/css3-webfonts/ @font-face { src: local("Palatino"), local("Times New Roman"), local("New York"), local("Utopia"), url("http://somewhere/free/font"); font-family: serif; font-weight: 100, 200, 300, 400, 500; font-style: normal; font-variant: normal; font-size: all }

Try server build (Mac/Win): http://tinyurl.com/5b3ghd Caveats: - Windows: Postscript-style OTF fonts (i.e. CFF fonts) don't load - Mac: Every now and then font load will fail and fallback font will show, investigating - same-site origin restriction enabled by default (site A can't refer to fonts on site B) - restriction can be disabled with gfx.downloadable_fonts.same-site-origin.enabled in about:config - with restriction disabled, A List Apart article examples will load correctly: http://www.alistapart.com/articles/cssatten - use of access control headers to allow cross-site usage not yet implemented - Linux: not yet working, see bug 449356 - for now, fonts are stored in mozfontxxx.ttf files in system temp directory. These may not get cleaned up if a crash occurs. - unicode-range not yet implemented If you run into problems, please note them in bug 441473 along with clear steps on how to reproduce.

Wine code for dynamically loading fonts using FreeType: http://source.winehq.org/source/dlls/gdi32/freetype.c#L1160 Has some interesting checks for various TT tables.

Latest try server build: http://people.mozilla.com/~jdaggett/webfontslatest This will redirect to the latest try server build and to the latest nightly once the patch for 441473 is checked in. Caveats: - Windows: Postscript-style OTF fonts (i.e. CFF fonts) don't load - same-site origin restriction enabled by default (site A can't refer to fonts on site B) - restriction can be disabled by setting gfx.downloadable_fonts.enforce_same_site_origin to false in about:config (setting name changed!) - use of access control headers to allow cross-site usage not yet implemented - Linux: not yet working, see bug 449356 - unicode-range not yet implemented Interesting test pages: A List Apart article http://www.alistapart.com/articles/cssatten PrinceXML webfonts test page http://www.princexml.com/howcome/2008/webfonts/ Ralf Herrmann's webblog: http://opentype.info/blog/2008/08/05/10-great-free-fonts-for-font-face-embedding/ (lots of .otf fonts, works on Mac but not on Windows yet)

Hey. I tried slapping font-face into: http://m8y.org/tmp/testcase63.xhtml It works great, except under OSX, where the text shadows get screwed up on the font load. Windows does not have this problem.

Shouldn't this bug be marked fixed now that it seems to be working now in current trunk build?

(In reply to comment #169) > Shouldn't this bug be marked fixed now that it seems to be working now in > current trunk build? The depends list still has a bunch of bugs that need to be fixed before this is considered done. Mainly things like Linux support, .otf support on Windows, use of access control headers, etc.

Does our implementation handle the entire spec at this point? Currently the doc only covers absolute basics (font-family and src, with no descriptors), and I want to be sure it covers everything we support.

helpwanted, qawanted were added way back in 2004-05-03 without a comment. Are these still needed? What help or QA support is wanted?

I find it a little a bit ironical that the one and only MDC example for @font-face is not working both with Shiretoko and Minefield. <a href="https://developer.mozilla.org/@api/deki/files/2935/=webfont-sample.html">https://developer.mozilla.org/@api/deki/files/2935/=webfont-sample.html</a> <a href="https://developer.mozilla.org/en/CSS/@font-face">https://developer.mozilla.org/en/CSS/@font-face</a> It seems like some ttf-files won't work. See my test case <a href="http://klebom.se/stellan/css/font-face/vera2.html">http://klebom.se/stellan/css/font-face/vera2.html</a>. This testcase uses all 10 font files in the Bitstream Vera font family. Firefox fails to load 4 of them. As far as I know they are all standard true type fonts.

The example on MDC is working fine for me in the latest nightly of Shiretoko.

Well I'm at the latest Shiretoko too... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090310 Shiretoko/3.1b4pre Slightly strange? I tried with a fresh empty prfoile just in case. Same result. What did you see with my vera2 testcase?

According to the error console, there are errors occurring parsing your HTML, with invalid values specified for several things. You may want to check that.

When I try https://developer.mozilla.org/@api/deki/files/2935/=webfont-sample.html , nsFontFaceLoader::OnStreamComplete for http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf gets called with aStatus=0x805303f4 (a failure that I don't recognize). mCanceled is 1 in nsHttpChannel::OnStopRequest. I wonder whether url("https://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf") or url("/@api/deki/files/2934/=VeraSeBd.ttf") may work better, but I don't know.

http://silver.warwickcompsoc.co.uk/mozilla/misc/nserror?0x805303f4 sez that's NS_ERROR_DOM_BAD_URI. A glance at nsCSSScanner::NextURL doesn't show anything odd, so I suspect the code to create a URL from the resulting string doesn't like the unescaped character, maybe.

(In reply to comment #176) > According to the error console, there are errors occurring parsing your HTML, > with invalid values specified for several things. You may want to check that. My test cases all validate for HTML 4.01 strict and CSS3. The messages you are referring to are CSS warnings for http://klebom.se/stellan/css/font-face/vera.html not for http://klebom.se/stellan/css/font-face/vera2.html that I asked you about. In the "vera2" case Shiretoko only loads 6 out of 10 font files in windows version. In the "vera" case Shiretoko is generating CSS-warnings for valid CSS3. That's because full standard isn't implemented. For example "font-weight: all" or "font-style: all" etc is unsupported by Gecko. Gecko also don't regonize a list of values per spec. e.i. "font-style: oblique, italic" or "font-weight: 400, 500, 600".

This is almost certainly fodder for a new bug rather than posting more messages to this one and subjecting everyone CCed to it to this. Please file a new one and mark it as blocking this one.

(In reply to comment #173) > It seems like some ttf-files won't work. > See my test case http://klebom.se/stellan/css/font-face/vera2.html . > > This testcase uses all 10 font files in the Bitstream Vera font family. Firefox > fails to load 4 of them. As far as I know they are all standard true type > fonts. When I load this testcase in a DEBUG build, I see 4 occurrences of this warning printed to the console: WARNING: invalid font (bad checksum): file /home/dbaron/builds/mozilla-central/mozilla/gfx/thebes/src/gfxFontUtils.cpp, line 809

(In reply to comment #181) > WARNING: invalid font (bad checksum): file > /home/dbaron/builds/mozilla-central/mozilla/gfx/thebes/src/gfxFontUtils.cpp, > line 809 Too bad!! I just did some research on the vera fonts. Bitstream donated them to open source through the gnome foundation. The four font files are broken from the source... That means there are no correct files to be found, and also that almost every linux installation have the faulty files, and of course this also means that Gecko needs to render fonts even with invalid checksum as in the vera font case, since these broken fonts render fine with Safari for windows for example. The files VeraBd.ttf, VeraIt.ttf, VeraSe.ttf, VeraSeBd.ttf all have checksum error in their "head" table.

(In reply to comment #182) > (In reply to comment #181) > > > WARNING: invalid font (bad checksum): file > > /home/dbaron/builds/mozilla-central/mozilla/gfx/thebes/src/gfxFontUtils.cpp, > > line 809 > > Too bad!! I just did some research on the vera fonts. Bitstream donated them to > open source through the gnome foundation. The four font files are broken from > the source... > > That means there are no correct files to be found, and also that almost every > linux installation have the faulty files, and of course this also means that > Gecko needs to render fonts even with invalid checksum as in the vera font > case, since these broken fonts render fine with Safari for windows for example. > > The files VeraBd.ttf, VeraIt.ttf, VeraSe.ttf, VeraSeBd.ttf all have checksum > error > in their "head" table. Wern''t you asked in comment 180 to stop spamming this bug and to file a new bug on this issue?

I filed the checksum issue as bug 483459.

Using the 3.5b5pre build from 2009-05-01 on Ubuntu 9.04: In these demos: http://www.princexml.com/howcome/2008/webfonts/ , the text renders as unknown-character glyphs (i.e. the character code inside a box), after showing briefly in a local font while the page loads. I assume those fonts are unusable. However, Firefox doesn't fall back to a font with a renderable character. Is this the intended behaviour?

(In reply to comment #185) > Using the 3.5b5pre build from 2009-05-01 on Ubuntu 9.04: > > In these demos: http://www.princexml.com/howcome/2008/webfonts/ , the text > renders as unknown-character glyphs (i.e. the character code inside a box), > after showing briefly in a local font while the page loads. > > I assume those fonts are unusable. However, Firefox doesn't fall back to a font > with a renderable character. Is this the intended behaviour? That is bug 489445, that should land on gecko 1.9.1 (Fx 3.5b) soon.

The sample for @font-face on MDC used to work but stopped working at some point fairly recently. Can someone take a look at it and let me know what's wrong with it? http://tinyurl.com/brohuv

(In reply to comment #187) > The sample for @font-face on MDC used to work but stopped working at some point > fairly recently. Can someone take a look at it and let me know what's wrong > with it? > > http://tinyurl.com/brohuv The test case uses Vera Serif bold, which seems to have bad checksums. See bug 483459.

If you are downloading a font via @font-face Firefox will first render the text with a standard font before downloading and then re-rendering the text using the correct font. This is pretty ugly and doesn't happen in Safari, it would also seem to be a waste of CPU time to render things twice.

@Comment #189: I would hope that Mozilla doesn't follow the Safari approach. It's very bad when you're on dial-up and have to sit there waiting for content just because someone feels that function should follow form. (And, contrary to an apparently popular misconception, not everyone in the world has broadband or even has it available.) For an example of what I mean, try looking at the examples at <http://www.alistapart.com/articles/cssatten> on a dial-up connection in Safari. You sit there staring at a blank box for a long time (i.e., up to 10 seconds) while you wait for a very small amount of text to display. In terms of rendering time, that's ridiculous. (And, to top it off, the fonts are less readable than the standard system fonts.)

@Comment #189 and comment #190 The current behavior seems reasonable to me. It's not that much different than alt text being shown before images load or an interlaced PNG/GIF. I wouldn't be averse to an about:config pref, though. (On the author side, JavaScript should be able to handle it.)

I am searching for a bug about @font in SVG. Should one be opened. Testcase: http://devfiles.myopera.com/articles/593/webfonts_in_svg.svg It works in Safari and Opera.

(In reply to comment #192) > I am searching for a bug about @font in SVG. Should one be opened. Bug 119490 P1 and blocker for Firefox.next

Lars, I'm a bit confused SVG fonts is unrelated to CSS fonts in SVG. The testcase you linked to, the CSS font embedded in the SVG works just fine in Firefox. http://m8y.org/tmp/testcase124.svg A simpler testcase, also tested data URI embedded font, does *NOT* work in Opera 10 - I'm actually a bit puzzled by this. It also fails in Safari 4. It does, however, work just fine in Firefox. ;)

Re #193: The test case I was referring to is not about SVG fonts. It is about using the CSS declaration @font-face in SVG files, like so: @font-face { font-family: tuffy; src: url(ryanlerch_-_Tuffy_Bold.ttf) format("truetype"); } Comment #192 was probably badly worded. Re #194: The test case does indeed fail in Firefox 3.5 and Minefield. I will attach a screen grab.

Only a couple of the fonts are "failing" Given this bug, if you scroll back through the many many comments, discusses various bugs in true type fonts, and given the Tuffy font loads, I'm inclined to suspect the fonts that don't load are proooobably buggy. BTW, Lars, did you try my http://m8y.org/tmp/testcase124.svg in Opera? I'm about to file a bug against Webkit.

This was originally brought to my attention from by Erik Dahlström of Opera and the SVG WG. He knows way much more about this than I do, and I will bring this discussion to his attention. It is over my head, and I frankly do not have the time to debug this right now. The testcase at m8y.org does fail in Opera 10 beta. (P.S. Sorry for my bad spelling. Absent minded while typing...)

(In reply to comment #192) > I am searching for a bug about @font in SVG. Should one be opened. > > Testcase: http://devfiles.myopera.com/articles/593/webfonts_in_svg.svg > > It works in Safari and Opera. Lars, please file a new bug. Be sure to note the platform you're testing on.

In which Gecko version has this been fixed?

@font-face is in Gecko 1.9.1. Were you asking about something more specific?

Then this capability should be in SeaMonkey 2.0, which uses Gecko 1.9.1.4. Is that correct?

(In reply to comment #202) > Then this capability should be in SeaMonkey 2.0, which uses Gecko 1.9.1.4. Is > that correct? Yes. See http://www.seamonkey-project.org/releases/seamonkey2.0b1/changes (Ctrl-F for "font-face")