Bug 23119
| Summary: | Provide a way for the fonts to prohibit complex text handling | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brett Wilson (Google) <brettw> |
| Component: | Platform | Assignee: | Brett Wilson (Google) <brettw> |
| Status: | NEW | ||
| Severity: | Normal | CC: | aroben, jshin, mitz |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Brett Wilson (Google)
I'm trying to fix a not uncommon crash in Chromium which probably also affects Safari on Windows:
http://code.google.com/p/chromium/issues/detail?id=3950
It happens inside Uniscribe and is a bug in Windows when doing complex text shaping on bad fonts. Mozilla worked around this bug, and we probably want to do the same. See https://bugzilla.mozilla.org/show_bug.cgi?id=418384
The solution is to (1) detect if a font is Type1 and don't do shaping on it, and (2) if placement ever fails on the complex script path, force the font to use the non-complex code path.
I think having a flag to Font that is queried when determining how to draw the text should be sufficient. Each port can be in charge of setting the flag (or not) as necessary.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Brett Wilson (Google)
Actually, it looks like Chrome already handles the "placement error" case reported in the Mozilla bug (by just not showing the text), so it shouldn't crash. I assume our crashes are a result of doing this on PostScript fonts?
mitz
A test case (probably involving a font attached to the bug or otherwise obtainable) will be helpful.
Brett Wilson (Google)
I tried the Mozilla test case on my Vista computer and it worked OK. It could be MS fixed the bug in very recent versions. I'm going to look for an older computer to try.