From: Ed Trager (ed.trager@gmail.com)
Date: Wed Jun 16 2010 - 16:29:07 CDT
Hi, Marc,
On Tue, Jun 15, 2010 at 5:52 PM, Marc Durdin
<marc.durdin@tavultesoft.com> wrote:
> Ed,
>
> Couldn't you do this just using font fallback in CSS, and just leave it to the user agent to sort out? Two examples:
>
> P { font-family: Code2000, MyCode2000; }
> @font-face { font-family: MyCode2000; src: url('code2000.ttf'); }
>
> Or:
>
> P { font-family: MyCode2000; }
> @font-face { font-family: MyCode2000; src: local("Code2000"), url('code2000.ttf'); }
>
Yes, that works exactly as expected and, in most circumstances, would be enough.
However what I'm working on is a bit more complicated and so I want my
Javascript to know definitively whether the user agent has a font for
rendering scripts that are less common or only recently added to
Unicode (such as Lanna, inter alia). If I only needed to check just a
few scripts, letting the user agent do it all via statically-defined
CSS rules as you have above would be enough. But in my case I may
need to check more than just a few scripts, and so I want to use
Javascript to set up additional @font-face rules dynamically on an
as-needed basis.
I cannot conclusively say at this point whether my planned "dynamic"
solution is better than a more static "let the UA figure it out"
approach, but I'm going to try it and see how it goes.
However, if I can't think of a good way to dynamically investigate the
monospaced scripts, of which there are at most 10 (in ISO 15924: hang,
hani, hans, hira ... etc.), then I might just set up static CSS rules
for the monospaced script subset while handling the less-common
non-monospaced scripts in a dynamic fashion.
- Ed
> The first method is the only that will work with IE (using EOT fonts of course); both methods work with most other browsers.
>
> Another (somewhat evil) option is to use Flash to enumerate system fonts and pass that back to your Javascript code.
>
> Marc
>
> -----Original Message-----
> From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] On Behalf Of Ed Trager
> Sent: Wednesday, 16 June 2010 4:14 AM
> To: Unicode Mailing List
> Subject: Using Javascript to Detect Script Support in a Browser
>
> Hi Unicoders,
>
> Suppose that we write Unicode text in a web page that we create. We
> are worried that our viewers' computers lack a font for proper display
> of the script in which our text is written. Obviously it will not be
> good if our users only see square boxes or question marks instead of
> the text that we want them to be able to see and read:
>
> □□□□□□□□□ ... <= Bad! :-(
>
> We want a solution to this problem.
>
> Until very recently, apparently the best we could do was to warn the
> user of the possibility of unrenderable text. For example Wikipedia,
> on pages related to Indic languages, says:
>
> “This article contains Indic text. Without proper rendering support,
> you may see question marks or boxes, misplaced vowels or missing
> conjuncts instead of Indic text.”
>
> But now that “good” browsers support @font-face, we can envision a
> better solution: If the browser does not have a font for rendering a
> specific script, we can dynamically supply one.
>
> I have written some simple Javascript to detect whether a user's web
> browser can display Unicode text in a specific ISO 15924 script.
> Here's how it works, using Javascript:
>
> * Create two divs on the page but set the CSS opacity to zero so
> the user doesn't see them.
> * In one div, place a relatively narrow letter from the target
> script. For example, for Latin one might choose "i".
> * In the other div, place a relatively wider letter from the target
> script. For Latin, "w" is an obvious choice.
> * If the width of the two divs is identical, then the letters were
> rendered as square boxes or question marks.
> * Otherwise, if the widths differ, then the browser has found a
> system font capable of rendering the text.
>
> In the case of a negative result where the widths are the same, we can
> then dynamically add an @font-face rule to the page to download an
> appropriate font. I have an experimental web application that already
> does exactly this to support Tai Tham (Lanna) script. As Lanna is a
> fairly recent addition to Unicode, only a very few people will have a
> Lanna font available on their machines.
>
> Astute unicoders on this list will probably already have recognized
> one or more shortcomings of this method. This method works perfectly
> for most scripts, but of course it fails for monospaced scripts like
> Chinese, Japanese, Korean, Yi, and possibly some others like Phags Pa.
>
> For monospaced scripts, I tried doing this:
>
> * In the first div put U+FFFE. Every browser I tested rendered
> U+FFFE as a square box.
> * In the second div put a representative character from the
> script, such as "中" or "文" for Chinese.
>
> In theory, the U+FFFE will always be rendered as a box with a fixed
> width, and one would expect that there is a fairly good probability
> that the fixed width of any Chinese font on the machine will not be
> exactly the same as the width of the fallback square box.
>
> But in practice, based on my tests, this does not work. One problem
> is that Firefox's fallback square boxes contain the Unicode code point
> hex digits -- and these fallback square boxes can actually be of
> different widths depending on the hex codes contained therein. Also
> it might just happen that the fixed width of the Chinese glyph is
> exactly the same width as that of the fallback box used to render the
> U+FFFE.
>
> It would be very nice to come up with a reliable solution for scripts
> that are traditionally monospaced. Does anyone have any brilliant
> ideas?
>
> - Ed Trager
>
>
>
>
This archive was generated by hypermail 2.1.5 : Wed Jun 16 2010 - 16:33:28 CDT