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)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dopefishjustin, Assigned: smontagu)

References

()

Details

Attachments

(4 files)

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.
Blocks: 334728
*** Bug 364925 has been marked as a duplicate of this bug. ***
This is taken from http://www.columbia.edu/kermit/utf8.html, modified to use Courier font for all the examples.
Attached patch PatchSplinter Review
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.
Assignee: nobody → smontagu
Status: NEW → ASSIGNED
Attachment #249687 - Flags: review?(pavlov)
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+
How about adding a pitchAndFamily to gfxFont::Metrics? It seems like a useful thing to have around...
Fix checked in. I opened bug 365080 on caching tmPitchAndFamily.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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).
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)
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.
Attachment #249832 - Flags: review?(pavlov) → review+
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.

Attachment

General

Created:
Updated:
Size: