From: vanisaac@boil.afraid.org
Date: Mon Nov 02 2009 - 03:05:24 CST
-----Original Message-----
> Well, for one thing, you are not answering the question asked and did not
> quote it either. It was: “Is there a way within a JavaScript program to
> enumerate all of the available fonts on a system and then to check them for
> support for a particular Unicode character?” To my knowledge, the correct
> answer is “No,” but JavaScript exists in many versions and implementations,
> some of them with some tricky ways of extracting information from the
> system, though perhaps blocked from that by security settings.
> That does not answer the question, though it might answer a question that
> might be asked after hearing the answer to the first question.
Admittedly, I was proceeding on the assumption that Stephen Siebert's response
was accurate and that from there, we still needed to answer the underlying
problem of ensuring that the character is diplayed.
> However, WEFT hasn’t got much popularity (you can hardly find pages that
> really use it, as opposite to trivial pages created just to demonstrate, in
> a simple setting, that WEFT “works”). One reason to this is the common
> experience that when you try to use it for real, you run into
> difficulties—odd problems and limitations. Another reason is that it is a
> Microsoft-only technology, which hasn’t been developed much in the recent
> years.
I can't speak to those kinds of issues, which was part of the reason why I
strongly suggested that anybody refer to the community forum that is linked on
the WEFT main page.
> The font embedding techniques as defined in CSS 3 drafts sound more
> promising. They are supported by newest versions of Firefox and Opera, and
> using suitable utilities you can convert a font to the format required by
> WEFT and thereby cover IE as well. For an introduction, check e.g.
> http://randsco.com/index.php/2009/07/04/p680 . However, this is not
> something I would do in a case like this.
>
> If you only need to use one character that is not commonly available in
> fonts that people have, it would be rather inefficient to embed the Arial
> Unicode MS font or the Code2000 font (both of which are rather large) just
> for that. Many visitors just wouldn’t wait.
I would not suggest such a large font, no. I believe there are, however,
mathematical fonts that support a large subset of the mathematical characters
available in Unicode, and would probably be fairly small, at least in relation
to Arial or Code2000. That having been said, I think there are a number of
technologies that can be used, and I do not suggest that WEFT is the only, or
even the most appropriate technology for any given situation, merely that it is
an option.
> In the case of CUBE ROOT, there’s the additional problem that if the user’s
> system has a font containing it, then the font is most probably Arial
> Unicode MS (shipped with Microsoft Office and other products). In that font,
> the glyph of the character is barely legible in the font size used (on a
> high-quality display, though looked at with by less than high-quality eyes).
>
> My conclusion is that in cases like this, an author should create a suitable
> image of the character, in the intended environment–in practice, a button of
> the same style as those based on characters when rendered in a typical way.
> That is, to take an image of the button rendered using some nice font
> (DejaVu Sans?) and edit it in a graphics program to make it somewhat more
> legible.
There is one big problem with this approach, which is that images don't
generally scale. Therefore every user, each with their own browser, operating
system, screen resolution, etc. would have the same cube root image,
independent of how that computer renders the text. By using scalable text for
your cube root symbol, you bypass that problem.
> --
> Yucca, http://www.cs.tut.fi/~jkorpela/
>
>
Van
This archive was generated by hypermail 2.1.5 : Sun Nov 01 2009 - 22:08:11 CST