Closed
Bug 353756
Opened 18 years ago
Closed 18 years ago
Bitmap fonts claim to support Unicode characters when they don't really
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dopefishjustin, Assigned: smontagu)
References
()
Details
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
pavlov
:
review+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
pavlov
:
review+
|
Details | Diff | Splinter Review |
Spun off from bug 324560 - when a bitmap font is specified, font substitution for Unicode characters not in the font doesn't seem to occur, and boxes appear. See attachment 227976 [details] for a testcase.
Assignee | ||
Comment 2•18 years ago
|
||
This is taken from http://www.columbia.edu/kermit/utf8.html, modified to use Courier font for all the examples.
Assignee | ||
Comment 3•18 years ago
|
||
This fixes the Uniscribe case in IsMissingGlyphs() after a lot of trial and error with the different flags in SCRIPT_FONTPROPERTIES. The non-Uniscribe case is harder: http://www.undocprint.org/winspool/fonts says that GetGlyphIndices has a bug for bitmap fonts and suggests "Use GetFontUnicodeRanges and compare each character to the list of supported ranges". That would be s-l-o-w even with a binary search, so I just bail to Uniscribe when encountering a bitmap font in non-ASCII text.
Comment 4•18 years ago
|
||
Comment on attachment 249687 [details] [diff] [review] Patch Do you know how expensive GetTextMetrics is? I worry that it might be somewhat expensive... We could cache tmPitchAndFamily in the FontEntry at startup, although we then need a better way to get that from the textrun/font. hm. we can do that later though...
Attachment #249687 -
Flags: review?(pavlov) → review+
Assignee | ||
Comment 5•18 years ago
|
||
How about adding a pitchAndFamily to gfxFont::Metrics? It seems like a useful thing to have around...
Assignee | ||
Comment 6•18 years ago
|
||
Fix checked in. I opened bug 365080 on caching tmPitchAndFamily.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 7•18 years ago
|
||
A couple issues remain: 1. A few Latin characters, like the Ε‘ in the Slovenian example, show up as boxes. (That character is one of the ones in Windows-1252 but not ISO-8859-1 - Courier only has the ISO-8859-1 repertoire.) 2. Vector fonts like Modern show the same behaviour as Courier pre-patch (testcase coming up) - I notice in the patch that TMPF_VECTOR and TMPF_TRUETYPE are treated the same, which probably shouldn't be the case (unless I'm misunderstanding what TMPF_VECTOR means).
Reporter | ||
Comment 8•18 years ago
|
||
Assignee | ||
Comment 9•18 years ago
|
||
Oops, that was sloppy of me, thanks for testing. I don't reproduce issue 1 exactly with my version of the Courier font, but I do still see boxes for some characters, e.g. the Euro symbol. IsMissingGlyphs() evidently still needs tweaking.
Attachment #249832 -
Flags: review?(pavlov)
Assignee | ||
Comment 10•18 years ago
|
||
So, I was trying to understand why the old Windows font code didn't have the problem with boxes for some characters, and it turns out there was a special workaround for it: see bug 134733. I think the root cause of the problem may be that the fonts were designed for older versions of the Windows "ANSI" code pages, and the GDI functions are assuming that a bitmap font can render any codepoint supported by the *current* versions of the relevant code page.
Updated•18 years ago
|
Attachment #249832 -
Flags: review?(pavlov) → review+
Assignee | ||
Comment 11•18 years ago
|
||
Comment on attachment 249832 [details] [diff] [review] Handle vector fonts the same as bitmap fonts Checked in.
You need to log in
before you can comment on or make changes to this bug.
Description
•