Closed Bug 49669 Opened 20 years ago Closed 17 years ago

Incorrect rendering of diacritical chars

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: baran, Assigned: ftang)

References

()

Details

(Keywords: fonts, platform-parity)

Attachments

(4 files)

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.
Seems to display fine on NT (2000081808).
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?
Assignee: pierre → erik
Keywords: fonts, pp
testcase page moved to http://fatagnus.hell.pl/ ;-)
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Does MSIE support font substitution at all?
Yes, WinIE supports "font substitution". They call it "font linking". (If I am
understanding you correctly.)
reassign to bstell and keep it future
Assignee: erik → bstell
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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...
QA Contact: chrisd → ian
--> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
bulk move NEW FUTURE bug to ASSIGN
Status: NEW → ASSIGNED
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'.


Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.