Re: glyph selection for Unicode in browsers

From: Tex Texin (
Date: Wed Sep 25 2002 - 21:11:01 EDT

  • Next message: chuck clemens: "script detection program"

    James, thanks as always for your reply.
    The 65K limit is ugly...

    With respect to CJKT comment below, I guess it is true because of

    For example, I set my browser to default to a Unicode font. I think
    everyone would if they could-
    -it's a knee-jerk response if the solution is adequate everywhere. You
    don't have to know which fonts work for which languages.
    For Americas, and Europe, users can easily just set a Unicode font.

    However, a Japanese user might have to choose a Japanese font, if the
    Unicode font does not favor (and cannot be made to favor with language
    tags) Japanese renderings.
    So it's catch 22. They have native fonts because Unicode fonts are
    inadequate, but we can be relieved that although Unicode fonts are
    inadequate, we are lucky the users don't use them.


    So where the differences are important, users are forced to select
    native fonts instead of unicode fonts. This then creates the difficulty
    that to view a multilingual page, you need to a)acquire specialized
    fonts,(tedious and costly perhaps), b) install them, c) assign them d)
    finally view the page.

    Sadder still:
    Content developers that want to use Unicode:
    a) can invest a lot of time in declaring lang around sections of text,
    and really get no bang for it at the moment. In truth browsers do very
    little with this information as far as I can tell. (I suspect it helps
    search engines, but I need to test that assumption more).

    b) It is actually more beneficial to use native code pages than unicode,
    since the browsers seem to do a better job of font selection here. (I
    need to test this statement more. However, from my own coding experience
    on windows, knowing the code page allows easy setting of the "script"
    for the font, which has a major influence on Windows font selection. The
    language information wouldn't be available so easily for a Unicode file
    without it being carefully designed in to be passed from the markup
    layers down to the primitive font selection layers.)

    To be fair, I think font coverage for Unicode has been steadily
    improving and it is much easier today to produce multilingual docs than
    in the past. But I am disappointed in the state of the art for Browsers,
    and I suspect it is also true for other products that are not
    professional publishing software of one kind or another. I suspect at
    the heart of the problem is rendering architecture has not carried
    language (as opposed to code page) to the primitive layers, and this
    needs to be addressed throughout the architecture, since the language
    information can no longer be deduced or presumed when the encoding is

    Whatever the reason, this needs to be fixed a) so Unicode can be
    recommended as best practice and b) documents are rendered with
    appropriate glyphs, without extraordinary effort by users.

    tex wrote:
    > > Also, this approach means I have to ask each Unicode font vendor, "Which
    > > language is your multilingual font designed for?"
    > > so I know which CJKT assignment is appropriate for that font...
    > >
    > Sad but true. On a happier note, most Japanese users will already have a
    > Japanese font set as default, Chinese users will have a Chinese (Simp or
    > Trad) font installed, and so forth. Still, when you're trying to publish
    > a multilingual page which can be properly displayed anywhere, this isn't
    > much consolation.

    > Best regards,
    > James Kass.

    Tex Texin   cell: +1 781 789 1898
    Xen Master                
    Making e-Business Work Around the World

    This archive was generated by hypermail 2.1.5 : Wed Sep 25 2002 - 21:51:46 EDT