Re: glyph selection for Unicode in browsers

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
catch-22.

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.

ugh!

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
Unicode.

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


jameskass@att.net 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   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Wednesday, 25 September 2002 21:11:31 UTC