Safari 3 beta has severe rendering issues on German and Dutch installs of Windows.
An example is the the homepage of the German tv station www.zdf.de
On Safari 3 beta for Mac it renders just fine: http://www.kerz.org/files/safari3_mac.png
This is what is produced on Safari 3 beta on Windows XP German (with all latest patches): http://www.kerz.org/files/safari3_win.png
The English version of Windows renders the page correctly: http://www.kerz.org/files/zdf.de-safari3.png
This bug was confirmed on Dutch installations of Windows, too.
Created attachment 14969[details]
Example of rendering problem on Dutch Windows XP
Added an example of the broken rendering on a Dutch Windows XP installation
Problem occurred on a US install as well (on one system not the other).
It occurred on the system that had the regional settings set to 'Dutch' and 'Netherlands'. Changing the unaffected system to those settings didn't change, which might indicate the setting affects the installer in some way.
Attaching a screenshot of badly rendered site on US Windows Vista
It might be, but I don't think so, because the same bug occurred on similar installation of vista, only configured differently (Regional Settings) at the time of setup.
Changing that setting afterwards has no effect.
Wouldn't 14070 occur regardless of Regional Settings?
I have tested 14070 only on a german installation, so I (In reply to comment #8)
> It might be, but I don't think so, because the same bug occurred on similar
> installation of vista, only configured differently (Regional Settings) at the
> time of setup.
>
> Changing that setting afterwards has no effect.
>
> Wouldn't 14070 occur regardless of Regional Settings?
>
When submitting 14070, I only tested on a german installation of Windows (2000 in this case). I guess I should have written that in there… (I added it now)
Created attachment 15017[details]
Use the PostScript name when the full name lookup fails.
This patch adds an additional step when the creation of a CGFontRef fails. If the creation does fail using the full name (which can be localized on non-English installs), we will get the font data of the font and find the PostScript name.
We cache a mapping from localized names to PostScript names so that subsequent lookups don't have to grovel through the font data again.
In my limited testing this fixed my issues. I tested with Russian and Swedish so far. I think this should largely fix the "bold/italic" missing text issues.
Comment on attachment 15017[details]
Use the PostScript name when the full name lookup fails.
In addition to irc comments:
+ if (bufferSize != 0) {
should be
+ if (bufferSize) {
While this patch does look "sane" (in as much as that's possible in this case) i'd prefer sfalken/maciej to have a look at it as well.
Created attachment 15029[details]
Improve to try to avoid disappearing text always
Even though we'll assert in debug builds if we fail to find a CG font via the PostScript name, this patch adds further bulletproofing to ensure that we fall back to the next font in the list.
Created attachment 15031[details]
Fix the memory leaks of CFStrings, add code to guard against malformed/malicious font data.
Fix leaks and guard against the data in the name table being malicious.
Comment on attachment 15031[details]
Fix the memory leaks of CFStrings, add code to guard against malformed/malicious font data.
+ if (bufferSize < 6)
+ return NULL;
+ if (bufferSize < stringsOffset)
+ return NULL;
These early returns, and others further on in the function, leak the contents of "buffer".
Comment on attachment 15033[details]
Fix storage leaks by using a Vector. Do more cleanup and more guards against malicious data.
r=me, with the two changes we discussed in person
2007-06-12 02:29 PDT, Martin Kerz
2007-06-12 02:29 PDT, Niels Leenheer (HTML5test)
2007-06-12 02:30 PDT, Martin Kerz
2007-06-12 02:31 PDT, Martin Kerz
2007-06-12 02:55 PDT, Sander Rijken
2007-06-14 02:32 PDT, Dave Hyatt
2007-06-14 13:42 PDT, Dave Hyatt
2007-06-14 14:21 PDT, Dave Hyatt
2007-06-14 14:41 PDT, Dave Hyatt