174461 - the role of language group in font selection and its priority

Status: VERIFIED INVALID

(Core :: Internationalization, defect)

Description

[Shanjian Li]

This issue was found while I was working on bug 154885. The specified website
"www.chinabyte.com" use following css specification to choose font.
body {FONT-SIZE: 12px;font-family:Verdana,Arial,ËÎÌå;}
On linux system, this lead to a very ugly display. Some of the chinese
characters is displayed using japanese font, and some of them is displayed with
chinese font. The direct reason is very simple, there is a japanese font with
the name "Verdana", and thus this font take priority of the chinese font. Of
cause, not all chinese characters can be found in chinese fonts, and that leads
to the ugly inconsistent font use. 

I proposed a patch in bug 154885. In that patch, I tried the search the font
with specified font family within document language group first. If no font
belong to document language group match the font family name, alternative font
will be tried first in this language group instead of trying font in other
language group. This way, if we could not find "Verdana" font in gb2312
encoding, "Arial" and "ËÎÌå" will be tried before "Verdana" font in jis encoding
is searched. 

This patch resolved the problem perfectly. But as bstell pointed out, this
approach is somewhat conflicting with CSS specication. In CSS level2, font matching:

15.5 Font matching algorithm
2. At a given element and for each character in that element, the UA assembles
the font properties applicable to that element. Using the complete set of
properties, the UA uses the 'font-family' descriptor to choose a tentative font
family. Thus, matching on a family name will succeed before matching on some
other descriptor. The remaining properties are tested against the family
according to the matching criteria described with each descriptor. If there are
matches for all the remaining properties, then that is the matching font face
for the given element.
...
7. If there is a matching font face, but it doesn't contain glyph(s) for the
current character(s), and if there is a next alternative 'font-family' in the
font sets, then repeat from step 2 with the next alternative 'font-family'. The
'unicode-range'  descriptor may be used to rapidly eliminate from consideration
those font faces that do not have the correct glyphs. If the 'unicode-range' 
descriptor indicates that a font contains some glyphs in the correct range, it
may be examined by the UA to see if it has that particular one. 
...

My interpretation of this paragraph is that if the current character's glyph can
be found in a font with matching family name, it will be used regardless of its
language group. In an example of CSS1, the intention is better stated:
"BODY { font-family: Baskerville, "Heisi Mincho W3", Symbol, serif }

The glyphs available in the "Baskerville" font (a font that covers only Latin
characters) will be taken from that font, Japanese glyphs will be taken from
"Heisi Mincho W3", and the mathematical symbol glyphs will come from "Symbol".
Any others will come from the generic font family 'serif'."

So suppose the document is in japanese, and all those ascii characters will be
displayed in a latin font "Baskerville". That might be fine for rendering roman
characters and kanji. But following example will be unacceptable to render to
japanese user:
"BODY { font-family: Song, "Heisi Mincho W3", Symbol, serif }
Because some of the character will be rendered in chinese font and some will be
rendered in japanese font. 

The same problem exist in western font as well.

Comment 1

[Boris Zbarsky [:bzbarsky]]

ccing people who may be able to comment on what the CSS spec means here (and may
be able to convince people to change it if it makes no sense in the real world).

Comment 2

[Hixie (not reading bugmail)]

This is invalid. Get the CSS WG to change the spec and then we can talk. :-)

Comment 3

[Yuying Long]

Mark as verified per comment above.