From: Brett Zamir (brettz9@yahoo.com)
Date: Tue Jan 19 2010 - 22:09:56 CST
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.
Sure...
>>
>> ... 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.
> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
>
> Our experience on Unicode.org 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
coverage).
Brett
This archive was generated by hypermail 2.1.5 : Tue Jan 19 2010 - 22:47:17 CST