49669 - Incorrect rendering of diacritical chars

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Miros/law Baran]

When using styles, the diacritical chars are rendered in an incorrect way:
they're bolder than other chars (even in the same word). Rendering of diacriticals
is broken probably with all encodings, but I have tested it only for ISO-8859-2.

Comment 1

[Eric S. Smith]

Seems to display fine on NT (2000081808).

Comment 2

[Hixie (not reading bugmail)]

Attachment: stylesheet for saved version of site

Comment 3

[Miros/law Baran]

Attachment: grabbed page showing example of bad rendering

Comment 4

[Hixie (not reading bugmail)]

Attachment: web page saved locally since webserver is so slooow. ;-)

Comment 5

[Hixie (not reading bugmail)]

This is a pp (platform parity) problem, since it doesn't occur on Win2K
(commercial bits 6.0.18.2000082104).

The problem is probably font selection -- I'm guessing we are choosing a
different font for the accented characters, and it happens to be bolder.

How do Opera/Netscape4/Konqueror render that page?

Comment 6

[Miros/law Baran]

Attachment: the same page rendered by Netscape 4.7x

Comment 7

[Miros/law Baran]

testcase page moved to http://fatagnus.hell.pl/ ;-)

Comment 8

[Erik van der Poel]

We implement the CSS2 font matching algorithm, which specifies that the
implementation must search the font-family list *for each character* in the
element. This means that we don't look ahead to see if some characters might be
coming that are not in the current font. So we will sometimes end up with font
changes. I believe that MSIE looks ahead (ignoring the CSS2 spec), but I don't
know how well MSIE works on Unix, which has rather poor fonts (leading to the
font changes in Mozilla).

In short, I doubt that we could fix this quickly.

Comment 9

[Karl Ove Hufthammer]

Does MSIE support font substitution at all?

Comment 10

[Erik van der Poel]

Yes, WinIE supports "font substitution". They call it "font linking". (If I am
understanding you correctly.)

Comment 11

[Frank Tang]

reassign to bstell and keep it future

Comment 12

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 13

[kill this account]

--> ftang

Comment 14

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 15

[Jungshik Shin]

comment #5 and comment #8 explainted the cause. With necessary fonts installed
and configured for Centeral European langgroup, there's little problem. On
'modern' Unix, ISO-8859-2 fonts (with family names lised in the CSS of the page)
are available. 

If 'look-ahead' is regarded as necessary, it has to be a separate
'enhancement'(?) request.

It's hard to decide which one to use, 'fixed, invalid, wfm, wontfix'. I'm just
using 'worksforme'.