211092 - Absolute CSS units (millimeters, points etc.) are broken on printout

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Manko]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

Sizes pointed in millimeters are increased by 20% on printout. See demo
(100x100mm square is printed as 120x120).

Mozilla 1.3.1 and below prints OK.

Marking major because this bug completelly brokes printing a forms in our
intranet applications.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Manko]

Attachment: Testcase (100mmx100mm square). Print it to see bug.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Worksforme... do you have incorrect DPI settings set somewhere?

Comment 3

[Jim Davis]

I just upgraded from 1.3 to 1.4 (release) here.  I printed the attachment out
this morning, it was right at 10cm.  Now, with 1.4, I get a 12cm square.

I haven't changed any dpi-related settings anywhere that I'm aware of.

Comment 4

[Roland Mainz]

Just curious: Did you disable the "shrink to fit" option in the "page setup"
dialog ? If not Mozilla will try(=the functionality is partially broken... ;-( )
to scale the page dynamically...

Comment 5

[Jim Davis]

I just tried disabling "Shrink To Fit" and printing it, and got the same 12cm
result.

Comment 6

[Manko]

Same problems with 1.4 release, alas.

Comment 7

[Mathieu CARTOIXA]

*** Bug 215397 has been marked as a duplicate of this bug. ***

Comment 8

[Manko]

Changing summary according of bug 214654 and bug 214755: not only millimeters
are broken but any absolute CSS units.

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK, I just tested with Linux builds.  1.2, 1.3, and current trunk all print
identically.

Sounds like this is a Win32-specific problem.  Someone who can run Windows
builds should try to get a reasonable regression range (reasonable == "a few
days"); that would help immensely with fixing the bug.

At the very least, test the 1.4a and 1.4b milestones; if 1.4b does not show the
bug, also test the 1.4 pre-releases?

Comment 10

[Skewer]

This appears to be related to dpi. Here are my results (WinXP 2003080404):

Lexmark Optra C, 600dpi: 120mm.
HP OfficeJet d145, 600dpi: 95mm.
HP OfficeJet d145, 1200x600dpi: 120mm. (Same print, same printer, two different
sizes depending on quality level.)
Epson Photo 900: Printed perfectly, 100mm. (Don't know how many dpi it was using.)

It seems like the communication with the printer is causing the problem. Either
2 out of 3 printers disobey what they're told or we're messing something up.

Also scaling (100%, scale to page, etc.) does not affect the size as evidenced
by print preview.

If I print to PDFWriter the square in the PDF is a perfect 100mm, but printed in
Acrobat always gives me 95mm even on printers that gave me 120mm before.

Comment 11

[Mathieu CARTOIXA]

As noted on bug 215397, the print preview rendering is broken too, but is 
coherent with the printout. So the problem occurs before sending data to the 
printer. (WinNT 4.0 SP6 / 20030624)

Comment 12

[Manko]

Still persists in 1.5b.

Our customers are forced to use 1.3.1 or even MSIE to work with our Intranet
applications because of this bug.

Comment 13

[Malcolm Rowe]

This regressed between 1.4a and 1.4b (tested with a clean profile). Trying to
narrow the regression window now...

Note that I do *not* see the 'zooming' in print preview noted in comment 11.

Also note that it's not just the square that's scaled incorrectly, the header
and footer text also appears to be scaled about 1.2x. I've no idea whether the
headers and footers are scaled with absolute units, though.

[For the record, I see a 120mm x 120mm square, and I have a Lexmark Z65]

Comment 14

[Malcolm Rowe]

*** Bug 214755 has been marked as a duplicate of this bug. ***

Comment 15

[Malcolm Rowe]

*** Bug 214654 has been marked as a duplicate of this bug. ***

Comment 16

[Malcolm Rowe]

Bug 214654 and bug 214755 are duplicates, not dependents.
Still working on the regression window. 20030418 appears broken.

Comment 17

[Michael B. Venezia]

The zooming issue exists in the print preview with the testcase from bug 214654.

At least for me :)

Comment 18

[Malcolm Rowe]

The testcase on bug 214654 is far from 'simplified'. It's hard to see whether
there are additional problems at work. (but yes, I see that it's screwed up in
print preview, too, only I can't tell whether it's just this bug).

Build from 20030409 (that is, pull as at 2003-04-09 00:00 PST) is still broken,
assuming my build environment is ok.

Comment 19

[Malcolm Rowe]

This bug was caused by the checkin of nsDeviceContextWin.cpp, version 3.106, in
bug 199159 (attachment 119533 [details] [diff] [review]).

Build 20030404 is fine, but rolling forward to version 3.106 causes the bug to
appear. Likewise, trunk is broken, but rolling back to 3.105 fixes it.

roc: all yours!

Comment 20

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

Indeed.

Screens need their twips-to-pixels value to be an integer. Otherwise we have all
sorts of problems. So we tweak the dpi a bit.

The problem is that for hi-res devices such as printers, the twips to pixels
ratio (1/1440in) is close to 2 or 1, so rounding it makes a huge difference.

The right fix is the comprehensive units overhaul.

The stopgap fix is to round the twips-to-pixels to an integer only for screens.
However, this could screw up print preview. Someone with Windows will have to
test the following patch...

Comment 21

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

taking

Comment 22

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

Attachment: fix??

Try this! See how well print preview works. I think it will still round in
print preview. I'm not sure how to deal with that.

Comment 23

[Malcolm Rowe]

Comment on attachment 130700 [details] [diff] [review]
fix??

This fixes the problems on printing for me. With this patch, the printout is
the scaled the same as with version 3.105.

I don't see any differences in Print Preview with or without this patch (it
seems correct regardless).

Comment 24

[Mathieu CARTOIXA]

Attachment: Print preview testcase

This new testcase is adapted from the previous one : it will print a square
180mm x 180mm.

1. Make sure A4 (210mm x 297mm) is your default paper format.
2. In the page setup menu, set all margins to 0.
3. Open the file in Mozilla.
4. Print preview.

The square should largely fit in the page, but print preview shows it truncated
on its right (180mm * 1.2 = 216mm > 210mm).

Mozilla/5.0 (Windows; U; WinNT4.0; fr-FR; rv:1.4) Gecko/20030624

Comment 25

[Mathieu CARTOIXA]

Attachment: Print preview testcase

This new testcase is adapted from the previous one : it will print a square
180mm x 180mm.

1. Make sure A4 (210mm x 297mm) is your default paper format.
2. In the page setup menu, set all margins to 0.
3. Open the file in Mozilla.
4. Print preview.

The square should largely fit in the page, but print preview shows it truncated
on its right (180mm * 1.2 = 216mm > 210mm).

Mozilla/5.0 (Windows; U; WinNT4.0; fr-FR; rv:1.4) Gecko/20030624

Comment 26

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

Comment on attachment 130700 [details] [diff] [review]
fix??

Well, this patch is probably a good stop-gap measure. Let's see what dbaron
thinks.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 130700 [details] [diff] [review]
fix??

r+sr=dbaron, although I prefer construction-style casts, i.e. replacing

>+  mPixelsToTwips = (float)NSIntPointsToTwips(72) / ((float)::GetDeviceCaps(aDC, LOGPIXELSY));

with:

mPixelsToTwips = float(NSIntPointsToTwips(72)) /
		 float(::GetDeviceCaps(aDC, LOGPIXELSY));

Comment 28

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

Comment on attachment 130700 [details] [diff] [review]
fix??

alright, let's go for 1.5 approval

Comment 29

[Asa Dotzler [:asa]]

Comment on attachment 130700 [details] [diff] [review]
fix??

a=asa (on behalf of drivers) for checkin to Mozilla 1.5

Comment 30

[John P Baker]

Is there any chance that this can be fixed on the 1.4 branch
as well?

Comment 31

[Mike Kaply [:mkaply]]

Comment on attachment 130700 [details] [diff] [review]
fix??

a=mkaply for 1.4.1. I'll get this in.

Comment 32

[Mike Kaply [:mkaply]]

checked into branch.

Comment 33

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

Checked in

Comment 34

[John Coonrod]

I downloaded the nightly 2003090704 and the 180mm test now prints at 175mm on my
HP4000 pcl6 driver, which is definitely much better than 1.5b printing 216mm.

Comment 35

[Boris Zbarsky [:bzbarsky]]

*** Bug 213179 has been marked as a duplicate of this bug. ***

Comment 36

[Saulius Gurklys]

*** Bug 209507 has been marked as a duplicate of this bug. ***

Comment 37

[Oleg Sidletskiy]

*** Bug 219744 has been marked as a duplicate of this bug. ***

Comment 38

[rcummins]

*** Bug 212011 has been marked as a duplicate of this bug. ***

Comment 39

[rcummins]

*** Bug 209191 has been marked as a duplicate of this bug. ***

Comment 40

[Pat Tressel]

I just now downloaded both 1.5 and 1.6a, and the problem still occurs
in both.  This is on ---> Linux <---.

Was the fix somehow restricted only to Windows builds?
Was it not included in 1.5 and 1.6a?  Which version *does* have it?

-- Pat

Comment 41

[Christian :Biesinger (don't email me, ping me on IRC)]

this was a windows bug and a windows fix. if you see this on linux, search for
another bug or file a new one if no bug is alraedy filed.