On Sat, 20 Dec 2003, Edward H. Trager wrote:

> On Saturday 2003.12.20 15:06:11 +0100, Jan Willem Stumpel wrote:

> > > Actually, no. I think I already explained this.
> >
> > Yes, you did (on 15 December). Sorry. I stand corrected. So: the
> > default language group is determined by the UTF locale (which

   s/UTF// :-)

> > incidentally also determines MozillaÂs GUI font). On Linux, the
> > default language group determines the fonts which Mozilla tries to
> > use (by preference) for displaying all Unicode characters. On

  Yes, unless there are other pieces of information that are more
relevant.


> > Windows, the preferred font is determined by the code range, which
> > seems more sensible, and in your bug report you propose to have
> > the same mechanism on Linux also.
>
> I second that: Regardless of what mechanisms are used, it would be very nice
> if Mozilla worked identically on Linux and on Windows.
.... (moved below)
> Also, I assume that it would lead to some slight simplification of
> the Mozilla code base,

  Nobody would ever disagree with you. Do you seriously believe Mozilla
developers would make their tasks more difficult not doing what you
wrote? However, the reality is not that simple. Note that on Linux/Unix
alone, we have a few different toolkits/font technologies to support that
are very different in their characteristics (XLFD vs fontconfig). Aside
from Linux, gecko-based browsers run not only on Win 9x/ME and Win2k/XP
(they're different OS' in many aspects) but also on several Unix', OS2,
Mac OS X, Qnx, and VMS (and an unknown number of embedded devices). There
might (or might not) be a way to abstract away all these platform/toolkit
dependencies, but the current level of the abstraction in Mozilla is not
there yet.  If we could use 'fontconfig' (+ pango or ICU) _everywhere_,
it'd be easy to do that. However, we'd not want to ask Mozilla
users on Windows or Mac OS X to install fontconfig + pango or ICU.
Including them into Mozilla is obviously out of question because Mozilla
without them is already too 'fat'.

> That makes it much
> easier for developers who have to test whether web pages look the same on
> different platforms.

  Well, the platform-dependent font availability is another important
factor that makes the platform parity hard to achieve.


> > Probably not :-( , because when I try it on Win98 with Mozilla
> > 1.5, accessing a page with <span lang=ru>ÐÑÑÐÐ </span> ÐÐÑÑÐÐ,
> > Putin is in the Cyrillic preferred font, while Yeltsin is in the
> > Western font. Exactly the same as in Linux.

 There's another factor I didn't mention that affects when/whether
'Unicode char. to script' mapping kicks in. Mozilla-Win tries to stay in
the currently selected font as much as possible to avoid 'ransom note'
style (which looks horrible in some cases) rendering. Therefore, as long
as the current font can cover Cyrillic letters, I believe it wouldn't
switch.  However, I guess 'lang=ru, xml:lang=ru' is regarded as a strong
indication of the authorial intent that warrants the font switching.
(it's been a while since the last time I looked at that part of the code
so that I'm just writing from memory.)

  BTW, Mozilla doesn't do any 'global optimization' [1] in the
font selection as might be done by some word processors or other rendering
engines/libraries (e.g. Pango or ATSUI on Mac OS X). That is, its text
drawing/measuring routines can take only a small text chunk (sometimes
just a single character) at a time and doesn't know anything beyond that.


> > So I _still_ donÂt understand it (including your bug report).
> > Apologies in advance if I have overlooked something obvious..

  You don't have to apologize. It's complicated and the only
way to understand it fully is to read the code and work on it. Although
I worked on Windows and Gtk (Linux/Unix) ports of Mozilla's text
drawing/measuring routines for a while, I don't claim to know every
gory detail. What's certain is that Mozilla developers try to match
what's stipulated in the CSS specification (http://www.w3.org/TR/CSS2)
[2]. Whether they're successful or not is another matter, though.

 Jungshik


[1]
http://www.ifi.unizh.ch/groups/mml/people/mduerst/papers/PS/FontComposition.ps.gz
[2] See, for instance, http://bugzilla.mozilla.org/show_bug.cgi?id=227889
--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/

Reply via email to