Closed Bug 49669 Opened 20 years ago Closed 17 years ago
Incorrect rendering of diacritical chars
7.32 KB, text/css
20.89 KB, image/png
4.72 KB, text/html
26.85 KB, image/png
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 126.96.36.1990082104). 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?
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
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
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.