448186 - Canvas drawWindow with context.scale does not scale bitmap fonts

Status: RESOLVED WORKSFORME

(Core :: Graphics: Canvas2D, defect)

Description

[Hans Schmucker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072503 Minefield/3.1a2pre
Build Identifier: Gecko/2008072503 

This bug breaks one of the major features of current trunk builds (so I marked it major), namely the Ctrl+Tab visual tab selection. When any page with a bitmap font is drawn onto a scaled canvas context, the letters are drawn at the scaled position, but at their original size, resulting in unreadable garbage. A simple testcase is attached. (however you'll have to open it from your harddisk as it needs to request chrome privileges).

Reproducible: Always

Steps to Reproduce:
1. Go to the given url.
2. Press Ctrl+Tab on 3.1/pre to bring up the visual tab selector
Actual Results:  
The page is displayed correctly, but the code segments (font: Courier) are way too big and overlaping

Expected Results:  
You should see an exact mini-replica of the page.

Comment 1

[Hans Schmucker]

Attachment: Sample testcase (requests chrome priviledges, so save to HD)

Comment 2

[Hans Schmucker]

Since Dão added this as blocking Bug 329693, I assume it is confirmed, but it would be great if somebody also changed the status accordingly.

Comment 3

[Joshua Cranmer [:jcranmer]]

I can, in fact, confirm that the effect happens using my Linux Firefox 20081108 build. The same font is causing problems on two separate pages.

Comment 4

[Ginn Chen]

I can reproduce this issue on OpenSolaris with a slightly modified example. (use rgb(255,255,255))
The result is also a bit different, on Windows, the bitmap font can be scaled up, (i.e. 200%), but not scaled down (i.e. 50%); on Solaris, the bitmap font is not scaled up or down, the font size is the same, but positioned at scaled position.

This bug is also appeared when you print preview or print a page with bitmap fonts and non 100% scaling.
So the print result of some pages are unreadable with the default "Shrink to fit page" setting.
See https://bugs.freedesktop.org/show_bug.cgi?id=18001
The problem is still not fixed.

I think the reason is cairo_scale doesn't scale bitmap font correctly.

This is a regression of Firefox 3.
Firefox 2 doesn't have this issue since it doesn't use cairo for this.
I hope we can get it fixed in Firefox 3.1.

Comment 5

[Ginn Chen]

Attachment: possible fix for cairo-ft-font.c

This is a possible fix for cairo-ft-font.c
It solved the test case here and print preview of bitmap fonts with scaling.
It looks good on the screen.

But it has a problem with ps surface, the A1 mask makes the result look bad, actually unreadable with scaling below 100%.

Comment 6

[Ginn Chen]

Comment on attachment 361739 [details] [diff] [review]
possible fix for cairo-ft-font.c

Adrian, is the idea correct?

I've no idea if it still works if ctm is not simple scaling.

For PS printing with 50% scaling, we could somehow improve the result by using a smaller threshold.
But I feel we could never make it readable if we scale down 12px bitmap font to 6px size and use imagemask glyphs in PS.

We might want to ignore bitmap fonts in this case.

Comment 7

[u285178]

I am not familiar with the FT backend. I suggest asking on the cairo list for feedback on your patch. Providing a simple C test case demonstrating the problem would also help.

One possible solution to the bitmap scaling problem in PS output is to use cairo user fonts. This would allow you to draw each glyph with the unscaled original and specify the scale with the font matrix. In the PS output the glyph bitmaps will be in their original resolution and the font matrix used to scale the glyphs. This works well and is used by Poppler for display and printing of Type 3 fonts.

Comment 8

[Ginn Chen]

Comment on attachment 361739 [details] [diff] [review]
possible fix for cairo-ft-font.c

filed a bug in cairo
https://bugs.freedesktop.org/show_bug.cgi?id=23539

Comment 9

[Peter Magyari (Desktop QA)]

Since this is a very old report and I cannot reproduce the issue I'm going to close it as worksforme

Feel free to reopen if necessary.