Closed Bug 324706 Opened 14 years ago Closed 13 years ago

Wrong fonts used in cairo builds (Bitmap fonts not used)

Categories

(Core :: Graphics, defect, major)

All
Windows XP
defect
Not set
major

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)

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.
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.
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
s/my default monospace./my default./
upgrading to major...
This really sux on the mozillazine forum that uses Courier to display [code]....[/code] parts
Severity: normal → major
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"?
Summary: Some monospace fonts don't render in cairo builds → Bitmap fonts don't render in cairo builds
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.
Blocks: 328421
*** Bug 328422 has been marked as a duplicate of this bug. ***
Assignee: nobody → pavlov
No longer blocks: 328421
Depends on: 329259
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.
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.
(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.

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
Blocks: 327879
(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.
Attached patch patchSplinter Review
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)
awesome! let me poke at that tomorrow and get it in!
*** Bug 330309 has been marked as a duplicate of this bug. ***
*** Bug 330357 has been marked as a duplicate of this bug. ***
*** Bug 330295 has been marked as a duplicate of this bug. ***
No longer blocks: 330295
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
Hmm... That's strange.
BTW, bitmap fonts don't render at all instead of "off by 29" on my build without a patch.
Attachment #214995 - Attachment is patch: false
Attachment #214995 - Attachment mime type: text/plain → image/png
I could reproduce the "off by 29" problem by setting system locale to English.
I'm investigating...
is this also caused by this bug? -> http://img454.imageshack.us/img454/3208/bugged22nt.th.jpg
sorry for the post above......put up the wrong screeenshot. This is the correct one-> 
http://img454.imageshack.us/img454/3208/bugged22nt.jpg
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.
Filed as bug 330715.
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.
Attachment #214819 - Flags: review?(pavlov)
The use of GetGlyphIndices is having side effects see bug 330208  
Flags: blocking1.9a1?
*** Bug 330927 has been marked as a duplicate of this bug. ***
Attached patch Cheap Hack Workaround (obsolete) — Splinter Review
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.
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.
*** Bug 332593 has been marked as a duplicate of this bug. ***
(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
(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.
*** Bug 328786 has been marked as a duplicate of this bug. ***
Whiteboard: cairo → cairo - See comment 27 for possible explanation of cause
Attached patch hack workaroundSplinter Review
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+
Whiteboard: cairo - See comment 27 for possible explanation of cause → cairo, [comment 27 has possible explanation of cause]
*** Bug 332485 has been marked as a duplicate of this bug. ***
Updating summary for new situation.  
Summary: Bitmap fonts render wrong glyphs in cairo builds → Wrong fonts used in cairo builds (Bitmap fonts not used)
Blocks: 329971
(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?
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.
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.  
Blocks: 334728
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.
Depends on: 340590
fixed as part of 340590
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The hack workaround originally checked in for this now needs to be removed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
huh?  I did remove it as part of 340590.  re-closing
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
(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.
Flags: blocking1.9a1?
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 → ---
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
anybody have regression range
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre ID:2007061909

all testcases -> success
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.
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
(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)
(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
(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.
ok I can reproduce this now and I know what the problem is.  Can we just kill off bitmap fonts?
Flags: blocking1.9+
Blocks: 382570
Attached patch fixSplinter Review
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+
Status: REOPENED → RESOLVED
Closed: 14 years ago13 years ago
Resolution: --- → FIXED
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
Oh I bet I know why, space is 0x20 but that code is only for 0x21-0xff....
Justin, did you file a bug on the space thing?  We should fix that.
I have now, bug 386389
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.