374141 - Borders of various form controls are not rendered on print preview

Status: VERIFIED FIXED

(Core :: Print Preview, defect, P2)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase.
When looking at the testcase in print preview, I don't seen any border of the various form controls. I'm on windowsXP, using the classic theme.

This regressed between 2007-02-13 and 2007-02-14:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-13+04&maxdate=2007-02-14+08&cvsroot=%2Fcvsroot
I think a regression from bug 369834.

Comment 1

[Eli Friedman]

Yeah, actually a regression from bug 177805.  It's just that now it affects print preview as well as printing.  The issue is simply that theme renderig isn't getting scaled up for printing; therefore, the borders are too thin to be visible.

Reassigning to self, but I'm not planning on working on this for a while.

Comment 2

[Worcester12345]

Attachment: broken print preview

Comment 3

[Worcester12345]

Not only do the borders not show, but the text is huge and overlapping. I haven't used print preview in a while, so don't know when this happened. My only extensions are Adblock and Paste and Go.

Comment 4

[Martijn Wargers (dead)]

(In reply to comment #3)
> Not only do the borders not show, but the text is huge and overlapping. 

That's bug 372838.

Comment 5

[Martijn Wargers (dead)]

Also, the print output doesn't show any borders on the testcase. This seems serious enough to be blocking 1.9 for me.

Comment 6

[Mike Schroepfer]

Eli can you take a look at this since it was a regression from your check-in?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

probably better if I take it

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I tried this out. Some borders are missing at some scale factors (usually when we're shrinking) --- that's just because we snap to pixels when drawing. If you scale up enough the borders are there.

I'm in a VM, but if I set up a dummy Postscript printer and use it to generate Postscript, the borders seem to be there too.

Martijn, am I missing something? Try scaling print preview up to 200% or 400%? Can you give me a screenshot of your print preview? Or has this been fixed recently?

Comment 9

[Martijn Wargers (dead)]

I tried print previewing to 200%, in that case, the majority of the borders are there.
Printing seems to be busted again for me in current trunk build, nothing shows up on the page.

Comment 10

[Martijn Wargers (dead)]

Attachment: print preview with 200% zoom

This is what I see on print preview with 200% zoom.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In my test, print DPI is 600 and screen DPI is 96, so print preview scales everything by 0.16. When we zoom by 200%, everything is scaled by 0.32. When we paint a native-themed widget, we paint it just as a large widget scaled down by 0.32 --- so a 1px device-pixel theme border becomes 1/300 of an inch, which is why borders seem thin and often disappear on the screen.

One way to fix this would be to make "device pixels" for printing bigger. That's not a great solution, but maybe it's the best available. Actually I'm not sure how we get device pixels that small for printing in the first place, we're supposed to be using 72dpi... 

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh, Windows printing just uses the dpi of the printer.

I'll see if I can change the Windows printing DPI to 72.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That requires code changes in multiple places to adjust the surface size, maybe risky.

As an alternative, I'm thinking of hacking nsNativeThemeWin to scale theme borders by some amount.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This seems to work and it's a small patch, although it feels a little scary.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There's a bit of a problem; the device pixel size not only affects theme rendering, but also font metrics and character placement because GDI and Uniscribe return all glyph positions and text measurements in device pixels. So 72dpi isn't good for Windows because character positions get aligned to 72dpi and that makes glyph positioning look chunky.

I'd change the print dpi to 144 before checking in ... that will be more forgiving for text but still let native theme pixels be reasonably large.

A longer-term fix probably requires us to modify nsNativeThemeWin so that when the device pixel size is different from the screen's device pixel size, we scale all theme drawing and measurement to suit. That would be quite a lot of risky work. We might decide to do that on all platforms, in fact.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK Stuart, you marked this P2, does that mean you're going to review the patch? :-)

Comment 17

[Stuart Parmenter]

Comment on attachment 301615 [details] [diff] [review]
fix

this patch scares me, but lets go for it.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 19

[Steve England [:stevee]]

This looks like it caused bug 418428. I don't have a printer, so I can't confirm the bug, but someone should probably take a look at it since it has a range and a testcase.

Comment 20

[Carsten Book [:Tomcat]]

i cannot verify this bug, because i still see problems with the border rendering on print preview, i filed Bug 432739 for this.