Re: Auto-retrieving Unicode fonts from centralized server in absence of @font-face or built-in support

From: Brett Zamir (
Date: Tue Jan 19 2010 - 22:09:56 CST

  • Next message: spir: "Re: unicode string representation in PL"

    On 1/20/2010 3:34 AM, Rick McGowan wrote:
    > Brett Zamir wrote:
    >> allowing one to specify a font on one's website which supports the
    >> characters needed by the page, as the browser might not have built-in
    >> font support for more obscure characters).
    > Also sounds like a substantial potential security risk, so you'd want
    > that to be a trusted authority, so I expect most people would want to
    > turn that feature off, or at least make it ask and have certificates,
    > etc, etc.


    >> ... to house a central repository of basic (open-source or otherwise
    >> licensed) fonts which can be used by browsers to automatically
    >> download the fonts not already supported in the browser
    > 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.
    > Our experience on has been similar with the DTDs for LDML,
    > so we went to use of non-URL-like DTD specs to eliminate that
    > excessive traffic. And yet, people *still* download, sometimes several
    > hundred times in one day on one machine, old DTDs for previous
    > out-dated LDML specs.

    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.

    Although I see you mention you went with a non-URL-like DTD specs, it
    seems the issue you had continued to experience was still a result of
    your older DTDs being available via URL.

    Secondly, while admittedly, there would be an even more compelling
    demand to obtain access to such a server for XML as well as HTML--since
    supporting fonts are essential to full document viewing unlike DTDs for
    validation or even entities (which can be potentially handled
    server-side) 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 too large 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.

    > In my personal opinion, the best way to assure that people everywhere
    > have basic fonts that "cover Unicode" is to release systems with at
    > least a basic coverage set built into them.

    Yes, I believe that should stay the same. Again, this would only be for
    character ranges the participating browser vendors believed to be rare
    enough to avoid bringing support for by default (or which OS' did not
    support by default).
    > And hopefully also allow users of prior software/font versions to
    > upgrade them.

    Yes (and thankfully browsers already do so, at least as far as their own
    software). I'm not sure how browsers handle font updates if they do at
    all (or how they might be able to query such a proposed repository to
    poll for last modified dates if the updates were not pushed to the
    clients at some point).

    > I think that's happening to some extent, and it will improve in the
    > future. As time goes on, the problem becomes less acute.

    Despite the above, I don't see that the issue will improve on its own
    for the rarer characters for which this proposal was intended (except to
    the extent that bandwidth for delivering wide-coverage fonts becomes
    less of an issue or operating systems pre-package fonts with complete


    This archive was generated by hypermail 2.1.5 : Tue Jan 19 2010 - 22:47:17 CST