Closed
Bug 324706
Opened 18 years ago
Closed 17 years ago
Wrong fonts used in cairo builds (Bitmap fonts not used)
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: polidobj, Assigned: pavlov)
References
()
Details
(Whiteboard: cairo, [comment 27 has possible explanation of cause])
Attachments
(8 files, 1 obsolete file)
1.25 KB,
text/html
|
Details | |
1.63 KB,
text/html
|
Details | |
953 bytes,
text/html
|
Details | |
1.44 KB,
patch
|
Details | Diff | Splinter Review | |
15.77 KB,
image/png
|
Details | |
35.75 KB,
image/png
|
Details | |
768 bytes,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
1.14 KB,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060125 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060125 Firefox/1.6a1 Two monospace fonts that don't render are Courier and Terminal. Reproducible: Always Steps to Reproduce: 1. View URL. 2. 3. Actual Results: Terminal and Courier examples are blank. Expected Results: All fonts are visible. You can also see this on bulletin boards like Mozillazine. Code blocks use the Courier font.
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Whiteboard: cairo
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 I see this too although changing to { font-family: monospace; } works.
Comment 3•18 years ago
|
||
I tried Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060126 SeaMonkey/1.1a, which is a trip/cairo build, on Mandriva 2006, and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060126 SeaMonkey/1.5a, which is latest trunk, on SuSE 10.0. On both, attachment 209619 [details] incorrectly renders all text the same in my default monospace. I saved the testcase to disk, and made a few adjustments. These 4 files are in the form b324706*.html currently at http://mrmazda.no-ip.com/tmp/ and all render exactly as expected, as does http://www.codestyle.org/css/font-family/sampler-Monospace.shtml
Comment 4•18 years ago
|
||
s/my default monospace./my default./
Comment 5•18 years ago
|
||
upgrading to major... This really sux on the mozillazine forum that uses Courier to display [code]....[/code] parts
Severity: normal → major
Comment 6•18 years ago
|
||
It's bitmap fonts, not monochrome fonts (Courier New, which is monospace but not bitmap works, and MS Sans Serif, which is bitmap but not monospace doesn't work). Can someone with privs please change summary to "Windows bitmap fonts don't render in cairo builds"?
Comment 7•18 years ago
|
||
Updated•18 years ago
|
Summary: Some monospace fonts don't render in cairo builds → Bitmap fonts don't render in cairo builds
Comment 8•18 years ago
|
||
For what it's worth, old-style Windows vector fonts like Script and Modern show up as blank too in a Cairo build, but a non-Cairo trunk build shows the text with the default font. IE uses the correct fonts.
Comment 9•18 years ago
|
||
*** Bug 328422 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → pavlov
Comment 10•18 years ago
|
||
My debug console emits a lot of messages when loading testcase. _cairo_win32_scaled_font_init_glyph_metrics:GetGlyphOutlineW: Could not complete the call to this function (Actually in Japanese, message may be not precise) Apparently GetGlyphOutline won't support raster fonts.
Assignee | ||
Comment 11•18 years ago
|
||
yeah, we don't really need to use GetGlyphOutlineW at all.. with the patch in 329259 we avoid ever doing that and bitmap fonts render.. but the glyphs indices are 29 off... if anyone has a clue about that one, lemme know.
Comment 12•18 years ago
|
||
(In reply to comment #11) > yeah, we don't really need to use GetGlyphOutlineW at all.. with the patch in > 329259 we avoid ever doing that and bitmap fonts render.. but the glyphs > indices are 29 off... if anyone has a clue about that one, lemme know. > But at least the vector fonts render correctly with that patch.
Assignee | ||
Comment 13•18 years ago
|
||
updating summary to reflect new reality
Status: NEW → ASSIGNED
Summary: Bitmap fonts don't render in cairo builds → Bitmap fonts render wrong glyphs in cairo builds
Comment 14•18 years ago
|
||
(In reply to comment #11) > yeah, we don't really need to use GetGlyphOutlineW at all.. with the patch in > 329259 we avoid ever doing that and bitmap fonts render.. but the glyphs > indices are 29 off... if anyone has a clue about that one, lemme know. > I found this documetnation: http://support.microsoft.com/default.aspx?scid=KB;en-us;q65123 Based on that, I would surmize that the glyph indicies being off by a constant would likely be caused by incorrect handling of dfFirstChar and dfLastChar, but that is only a guess.
Comment 15•18 years ago
|
||
GetGlyphIndices doesn't seem to get the correct glyph indices about bitmap fonts. With this patch, all testcases work fine.
Attachment #214819 -
Flags: review?(pavlov)
Assignee | ||
Comment 16•18 years ago
|
||
awesome! let me poke at that tomorrow and get it in!
Comment 17•18 years ago
|
||
*** Bug 330309 has been marked as a duplicate of this bug. ***
Comment 18•18 years ago
|
||
*** Bug 330357 has been marked as a duplicate of this bug. ***
Comment 19•18 years ago
|
||
*** Bug 330295 has been marked as a duplicate of this bug. ***
No longer blocks: 330295
Assignee | ||
Comment 20•18 years ago
|
||
Comment on attachment 214819 [details] [diff] [review] patch I don't see any difference with this patch... my glyphs in most of the tests in this bug are still off by 29
Comment 21•18 years ago
|
||
Hmm... That's strange. BTW, bitmap fonts don't render at all instead of "off by 29" on my build without a patch.
Updated•18 years ago
|
Attachment #214995 -
Attachment is patch: false
Attachment #214995 -
Attachment mime type: text/plain → image/png
Comment 22•18 years ago
|
||
I could reproduce the "off by 29" problem by setting system locale to English. I'm investigating...
Comment 23•18 years ago
|
||
is this also caused by this bug? -> http://img454.imageshack.us/img454/3208/bugged22nt.th.jpg
Comment 24•18 years ago
|
||
sorry for the post above......put up the wrong screeenshot. This is the correct one-> http://img454.imageshack.us/img454/3208/bugged22nt.jpg
Comment 25•18 years ago
|
||
That's not a bitmap font, so it's a different issue. The font with all those symbols is Marlett, which comes with Windows and is used to draw the window controls like minimize, X, etc. When I go to that page, those sections of text draw with the Code2000 font. Those lines of text are surrounded by <strong> tags, so it seems the font selection code is finding the wrong font for bold in that case. I'll see if I can make a testcase and file a separate bug.
Comment 26•18 years ago
|
||
Filed as bug 330715.
Comment 27•18 years ago
|
||
Per MSDN, glyph indexing only applies to TrueType fonts. http://msdn.microsoft.com/library/en-us/gdi/fontext_2ks4.asp?frame=true GetGlyphIndicies() seems to return the glyph indices as if System font is selected when raster fonts are actually selected. On English Locale, System font character 0x20 corresponds to 3, 0x21 to 4, and so forth. This is the reason for "off by 29". You can simply treat characters value as glyph indices for raster fonts.
Updated•18 years ago
|
Attachment #214819 -
Flags: review?(pavlov)
Comment 28•18 years ago
|
||
The use of GetGlyphIndices is having side effects see bug 330208
Updated•18 years ago
|
Flags: blocking1.9a1?
Comment 29•18 years ago
|
||
se also bug 330927 bug 311335 bug 94519
Comment 30•18 years ago
|
||
*** Bug 330927 has been marked as a duplicate of this bug. ***
Comment 31•18 years ago
|
||
Probably obvious, but for those who are rolling their own builds, this patch does font substitution for the problematic fonts. Not a fix, just a workaround. I have been running with this for about 3 weeks now with no problems.
Comment 32•18 years ago
|
||
A coupla other manifestations of this same problem (I think): Briefly - In 2006032703, I started seeing bitmap font problems - not in rendered HTML, but in Firefox menus and dialogs. http://alice.eng.level3.net/traceroute/traceroute.cgi?site=chi1&target=www.google.com shows an interesting version of the problem where the original rendering is wrong, but selecting the text fixes the rendering for any lines included in the selection. More details - I came back from a coupla weeks of vacation, jumping from build 2006030704 to 2006032703 and starting seeing this problem (which is odd, 'cause this bug was open 2006-01-25 and I've run a number of versions between then and now). I use a somewhat idiosyncratic theme on XP (see Bug 328786) which used MS Sans Serif (a bitmap font) in menus, dialogs, etc. I switched this to Microsoft Sans Serif (the truetype version of the same font) and suddenly I could read my menus. As 328786 points out, Cairo was rendering text in my menus as black of black. I guess the two main possibilities here are a) that the invisible text had the wrong glyph problem b) that Cairo was ignoring some of my color & font prefs and whatever fixed 328786 started picking up my menu text color pref AND my menu text font pref (Cairo had certainly been ignoring the former before). If a tree falls in the forest, &c. The next attachment illustrates the selection-fixes-rendering phenomenon.
Comment 33•18 years ago
|
||
Comment 34•18 years ago
|
||
*** Bug 332593 has been marked as a duplicate of this bug. ***
Comment 35•18 years ago
|
||
(In reply to comment #32) > http://alice.eng.level3.net/traceroute/traceroute.cgi?site=chi1&target=www.google.com > shows an interesting version of the problem where the original rendering is > wrong, but selecting the text fixes the rendering for any lines included in the > selection. Couldn't reproduce. Just looks ugly, selected or not. Deer Park 2 nightly, 20060403 Firefox/1.6a1
Comment 36•18 years ago
|
||
(In reply to comment #35) > Couldn't reproduce. Just looks ugly, selected or not. > Deer Park 2 nightly, 20060403 Firefox/1.6a1 I still see it in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060404 Firefox/1.6a1 build 2006040405 but your response prompted me to do some experimentation. I get different results when I increase and decrease the text size (CTRL/+ (well, CTRL/=, really) and CTRL/-). Sometimes the text is OK before selection, sometimes I get the behavior I got before, sometimes the text is still broken after selection. I'm gonna guess the variation has to do (in part) with Ffox' font matching algorithm (in conjunction with the set of fonts I have on my system), but that's just a WAG.
Comment 37•18 years ago
|
||
*** Bug 328786 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Whiteboard: cairo → cairo - See comment 27 for possible explanation of cause
Assignee | ||
Comment 38•18 years ago
|
||
this will force us to only load truetype fonts.
Attachment #215973 -
Attachment is obsolete: true
Attachment #217600 -
Flags: review?(vladimir)
Comment on attachment 217600 [details] [diff] [review] hack workaround r=me; this will lead to "wrong font" bugs, but at least the fonts will be readable instead of the current situation. Let's revisit this once there's more time.
Attachment #217600 -
Flags: review?(vladimir) → review+
Updated•18 years ago
|
Whiteboard: cairo - See comment 27 for possible explanation of cause → cairo, [comment 27 has possible explanation of cause]
Comment 40•18 years ago
|
||
*** Bug 332485 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 41•18 years ago
|
||
Updating summary for new situation.
Summary: Bitmap fonts render wrong glyphs in cairo builds → Wrong fonts used in cairo builds (Bitmap fonts not used)
Comment 42•18 years ago
|
||
(In reply to comment #41) > Updating summary for new situation. If this bug is now about the fact that the wrong fonts are picked, should there be another (lower-priority?) bug opened on the incorrect display of bitmap fonts? Part of bug 324560 seems to be related to the bitmap font problem and it may be an issue for some of the bugs duped to this one. More concretely: Does anyone know of such a bug? (I looked for one and found none) If so, could you put a reference to it here? If not, would anyone object to me opening one?
Comment 43•18 years ago
|
||
IMHO bugs should not be morphed. This bug is about incorrect glyphs for bitmap fonts. A new bug should be opened for the incorrect fonts issue and it shoudl be set to block this bug.
Reporter | ||
Comment 44•18 years ago
|
||
Like comment #13 I adjusted the summary to show what's the current reality and in response to comment #39 to help avoid new bugs being filed about font problems from the hack that was put it. The issue to be dealt with is still the bitmap fonts problem. The hack will be removed when that problem has a fix ready. We don't need another bug just for removing the hack.
Comment 45•18 years ago
|
||
I know what's going on here. Fonts are being created with a multiplicative factor called WIN32_FONT_LOGICAL_SCALE. The value of this scale factor is 32. This means that when you request a bitmap font like MS Sans Serif at size 16, you actually create a LOGFONT with a height of 16*32 = 512. This size is actually considered too large to accommodate a bitmap font, so when you select this font into the device context it fails and gives you Arial instead. I do not really understand the motivation for the multiplicative scale. Changing the scale value to 1 will allow the bitmap font to work. BTW, you can still ask a bitmap font for glyph indices etc and you can still call ExtTextOut with ETO_GLYPH_INDEX, use GetCharI to get character widths via glyph indices, etc. so disregard earlier comments that implied that you can't. The issue is entirely just that the size range of a bitmap font is limited and so it won't work with this huge multiplicative default scale factor. I'd suggest just eliminating the use of the scale factor, but I suppose it has some purpose that I'm not aware of.
Assignee | ||
Comment 46•18 years ago
|
||
fixed as part of 340590
Assignee | ||
Updated•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 47•18 years ago
|
||
The hack workaround originally checked in for this now needs to be removed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 48•18 years ago
|
||
huh? I did remove it as part of 340590. re-closing
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Comment 49•18 years ago
|
||
(In reply to comment #48) > huh? I did remove it as part of 340590. re-closing > Oh. Looks like you did revert the code, but neglected to remove the XXX comment. That is kind of what had me confused. SO, just the comment needs to be removed.
Updated•18 years ago
|
Flags: blocking1.9a1?
Comment 50•17 years ago
|
||
Seems like this has regressed. I'm not seeing bitmap fonts on Windows and Linux. All testcases fail.
Status: RESOLVED → REOPENED
Flags: in-testsuite?
OS: Windows XP → All
Hardware: PC → All
Resolution: FIXED → ---
Assignee | ||
Comment 51•17 years ago
|
||
I see bitmap fonts on Windows. Also please don't move platforms when you reopen bugs. File a new bug for linux if you want.
OS: All → Windows XP
Comment 52•17 years ago
|
||
anybody have regression range
Comment 53•17 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre ID:2007061909 all testcases -> success
Comment 54•17 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre All testcases fail -- I always get the default font. Same on a WinXP box.
Comment 55•17 years ago
|
||
Well, I don't think the testcases are expected to succeed on Linux, because they specify Windows bitmap fonts by name. And as Stuart said this was a Windows bug to begin with. That said, the tescases also fail for me on WinXP. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre ID:2007061904
Comment 56•17 years ago
|
||
(In reply to comment #53) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 > Minefield/3.0a6pre ID:2007061909 > > all testcases -> success > that should have been ->fail (dono why I typed success)
Comment 57•17 years ago
|
||
(In reply to comment #55) > Well, I don't think the testcases are expected to succeed on Linux, because > they specify Windows bitmap fonts by name. And as Stuart said this was a > Windows bug to begin with. Ok, I thought Courier would be available on Linux ... but anyway, this doesn't work here either: data:text/html;,<span style="font-family:monospace">abc
Comment 58•17 years ago
|
||
(In reply to comment #55) > Well, I don't think the testcases are expected to succeed on Linux, because > they specify Windows bitmap fonts by name. And as Stuart said this was a > Windows bug to begin with. The expectation probably comes from Linux bug 327879 comment 7. That bug is marked as dependent on this one. If that comment is wrong, then it should be unblocked.
Assignee | ||
Comment 59•17 years ago
|
||
ok I can reproduce this now and I know what the problem is. Can we just kill off bitmap fonts?
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9+
Assignee | ||
Comment 60•17 years ago
|
||
this is sort of a hack, but all bitmap fonts on my machine claim to only suppor t 0x21 - 0xFF (and they all claim to support that full range even if some of the glyphs are blank or .s or whatever.
Attachment #269725 -
Flags: review?(robarnold)
Comment on attachment 269725 [details] [diff] [review] fix r=me; just add a comment giving the other way to do this if assuming 0x21-0xff becomes a problem down the line (taking the string of 0x21-0xff and converting to glyphs)
Attachment #269725 -
Flags: review?(robarnold) → review+
Assignee | ||
Updated•17 years ago
|
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
Comment 62•17 years ago
|
||
Hmm, the spaces in the Courier testcase aren't taking up a full character cell, so the monospace-ness is broken - is it using another font for the spaces or something? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070626 Minefield/3.0a6pre ID:2007062604
Comment 63•17 years ago
|
||
Oh I bet I know why, space is 0x20 but that code is only for 0x21-0xff....
Comment 64•17 years ago
|
||
Justin, did you file a bug on the space thing? We should fix that.
Comment 65•17 years ago
|
||
I have now, bug 386389
Updated•9 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•