512619 - Auto-retrieve Unicode fonts from Mozilla server in absence of font-face or built-in support

Status: UNCONFIRMED

(Core :: General, enhancement)

Description

[Brett Zamir]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Hi,

While @font-face is a wonderful means of allowing developers to get their pages to display as they wish, I feel that the basic ability to read at least some form of a character should not be left to developers needing to obtain and manage font files (unless they so wish).

Might it be possible for Mozilla to host a common denominator of free/open-source fonts on its servers (no specially decorated fonts, just one readable version fully covering each non-natively supported range) which can be automatically called for download when a user encounters a page containing characters for which their installed fonts are missing support (and for which no remote @font-face directive is provided by the site)?

I would think this could give the best of both worlds in not adding to the Firefox install size, the servers would only be taxed when a page using such obscure characters was opened (and then the font could be stored indefinitely so the server would not be called again by that user), web developers could focus on content, and users could enjoy full access to any language supported by Unicode.

Thank you...

Reproducible: Always

Comment 1

[spiralofhope]

> Might it be possible for Mozilla to host a common denominator of
free/open-source fonts on its servers ...

Would it be better to just bundle such fonts with the browser?

Comment 2

[Brett Zamir]

It would be nice, but from what I've been told, the file size of the fonts could get pretty hefty to support all of Unicode's 100,000+ already assigned characters. And I know Firefox is always trying to keep the install size down... And many of these are obscure characters most people would never encounter anyways...

But it still seems to me that viewing such pages ideally wouldn't depend on individual developers knowing how to add such support; a humble document creator (albeit one probably knowledgeable about languages) should be able to use any Unicode character and have it "just work"...If they want to get fancy with specific fonts (or non-standard glyphs), then of course, it makes sense that a developer would be needed...

Btw, I also hope this will work for Firefox extensions (e.g., my Unicode Input Tool/Converter extension for viewing Unicode characters in a chart, etc.).

Comment 3

[Brett Zamir]

According to http://www.alanwood.net/unicode/fonts.html , Arial Unicode MS, one of the fonts that supports almost 39,000 characters (all those in Unicode 2.0), is over 22 MB on my system, so reaching 100,000+ coverage would of course require storage that is too high to include natively in Firefox (unless downloaded optionally and asynchronously after download).

Comment 4

[R McGowan]

Aaagh! It'll never work "correctly". By "correctly" I mean downloading only once per machine that needs it, a particular font from a particular server. Sounds to me like another potential nightmare for people who have important websites that lots of people want to refer to and download from "automatically" in web pages. See what the W3C says about DTD downloading.
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
(And our experience on Unicode.org has been similar with the DTDs for LDML.)

Comment 5

[Brett Zamir]

Hello...

It seems to me that there are some important differences in this case:

For one, access to the server would not be triggered by a URL reference (as used in HTML/XML-based DTDs)--a behavior which might tempt generic parsers or software to treat it as something to always resolve (or tempt individuals viewing the source code to visit). The idea is for this to be done automatically by the browsers and not with any document triggering mechanism like a DTD.

Secondly, while admittedly, there would be an even more compelling demand to obtain access to such a server for XML as well as HTML (because supporting fonts are essential to full document viewing unlike DTDs or even entities and since applications can easily store DTDs locally for common languages like HTML via their own DTD catalog, or at least a copy of an X/HTML (or LDML?) DTD, whereas the number of potential fonts could be larger for light clients to package), the system would only make fonts available for infrequently used character ranges. 

Admittedly, if tools were developed poorly, a tool could make such a request upon each page load with such characters (their users would probably complain pretty quickly though as, unlike for DTDs, they wouldn't want to wait for a large font file to download each time they visited a page), but again, this would only be for documents using rare characters in such scripts as Old Italic, etc. Of course the server would need to be able to handle a significant load, but it should still be quite a bit less than if browsers like Firefox were to bulk itself up with these fonts from the beginning.

As I see it, if anything, the now already supported @font-face might be slightly more likely to add such a burden, however, as I don't see any indication in the MDC documentation that the browser should store fonts it finds indefinitely (or unless the font is modified). I would guess here that, as with scripts and style sheets, the browser may only cache them temporarily. @font-face can, with, (deliberately chosen) HTTP access control, also allow cross-domain access, so the potential for the trouble of a DoS-causing dependency for its consumers is there as well.

Of course, Firefox (or whatever other major browsers might attempt it) would need to implement this competently, but I think that's basically a given, and again, I wouldn't imagine that even small vendors could really get away with such a poor implementation.