1120490 - Linux : "Print to File" with PS format & landscape orientation ends up mis-rotated (with content running off the page)

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Bradley]

Attachment: supposed to be landscape: d00024-001 - from /var/spool/cups

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

Installed OS (Scientific Linux 6.4; can't change for corporate reasons).
We are using this version of Firefox:
https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/31.3.0esr/linux-x86_64/en-US/firefox-31.3.0esr.tar.bz2


Open page to be printed in Landscape. 
Select print, then selected Landscape
Selected Page Setup to ensure "Format for:"  pointing to correct printer, and apply
Visually, my page in the print preview appears correct in landscape, and the page content is complete.
Select "Print", then press "Print" button


Actual results:

Page prints in portrait, but missing right half of page content. 

I have added the file that Firefox sends to cups, and I believe it is not formatted correctly at this stage.   I used Okular to view the file.


Expected results:

It should have printed correctly in Landscape.

Comment 1

[Bradley]

Attachment: d00025-001 was same page printed in portrait

d00025-001 was printed in portrait to illustrate similarities when same document was attempted to print in Landscape (d00024-001)

Comment 2

[Bradley]

Comment on attachment 8547661 [details]
supposed to be landscape: d00024-001 - from /var/spool/cups

This and the other file were from /var/spool/cups, to see what was being sent to cups.

cupsctrl PreserveJobFiles=yes

Comment 3

[:Gijs (he/him)]

Can you download and run a tarball of a more recent version to see if it's fixed there? (e.g. https://nightly.mozilla.org/ )

Comment 4

[Bradley]

I have crunched through the versions and I have determined that versions are all working up to and including v29.0b8

From that point, v29.0b9 to the latest/most recent v36.0b1 are all exhibiting the errors with landscape.

So I am hoping that now armed with this knowledge - the offending code will present it's self.
*grin*

Comment 5

[:Gijs (he/him)]

This looks likely to have been caused by bug 991767, which was landed after b8 and before b9... roc/matt, does that seem plausible?

Comment 6

[:Gijs (he/him)]

b8 to b9 pushlog: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=3437e5663d9e&tochange=da279b9f523a

Comment 7

[:Gijs (he/him)]

Hmm, that got backed out for 29.0.1 - Bradley, can you doublecheck if you see this problem in 29.0.1? If *not* (while it did happen in 29, and 30), that means it probably really was that change, and although it was removed temporarily for 29.0.1, it would be there in 30 and later releases, it would seem...

Comment 8

[Matt Woodrow (:mattwoodrow)]

(In reply to :Gijs Kruitbosch from comment #5)
> This looks likely to have been caused by bug 991767, which was landed after
> b8 and before b9... roc/matt, does that seem plausible?

Yeah, seems likely.

Comment 9

[Bradley]

I have double checked that 29.0.1 is working.    Hmm, it looks like I may have originally overlooked 29.0.1 when I discovered 29.0b9 failed.    

Excellent detective work, gentlemen !

Comment 10

[Bradley]

So i am not getting any joy out of esr31.5 either... 
printing Landscape is still not working correctly. 
Its been 2 months, what else can be checked or done to get the Landscape print to work ??

Comment 11

[Jeff Norden]

Almost 8 months and still no progress on this?  This bug occurs in 38.2.0esr as well.  I guess this sort of thing is why more and more people are moving to chrome.

Comment 12

[:Gijs (he/him)]

Milan, seems this was regressed by a graphics bug. Any chance someone from your team could look at what happened here?

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

I'll change it to Graphics so that we don't lose track of it; if it isn't graphics, I'll send it back.  Andrew, can you reproduce this problem?

Comment 14

[Andrew Comminos [:acomminos]]

I couldn't reproduce when trying to print this bug's page with 2015-08-24's nightly nor the provided 31.3.0 build. I'm using CUPS 2.0.3-10 on Debian testing.

Comment 15

[Daniel Holbert [:dholbert]]

It looks like we don't have a publicly-visible testcase that can be used to test this bug yet. The attached printouts seem to be from some internal-corporate-intranet page ("http://inband/timesheet/2015-01-02")

Jeff / Bradley, can you reproduce this on any publicly-visible website which we can use to test/investigate? If not, perhaps you could save a copy of the internal website which triggers the problem, strip out any private data from the saved source, and post that on this bug (or somewhere where a Mozilla developer can take a look)?

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: trivial testcase (File|Print, "Print to File", & choose PS format & Landscape orientation in Page-Setup tab)

(This doesn't happen with every page; for example, here's a simple HTML file [with contents copypasted from a lorem ipsum generator] which doesn't reproduce this bug for me.  And :acomminos tried out this actual bugzilla page as a more-complex testcase & can't reproduce.

So - to proceed, we need a testcase or a public URL that does actually reproduce the bug.)

Comment 17

[Jeff Norden]

For me, this bug occurs printing any page - the firefox start page is good
enough.  It occurs when printing directly to a physical printer (mine happen
to be HP laserjets, but I doubt that is relevant).  If I use "print to file"
the resulting pdf is correctly oriented and it prints fine.

I have now concluded that this problem occurs for me because I'm running a
very non-standard linux setup that I've customized quite a bit but which still
includes a rather ancient version of CUPS (1.4.3).  However, firefox is the
only application which seem to have printing problems in this environment.  I
wouldn't have bothered to post a comment for this bug if it wasn't still
marked as open/unconfirmed.  This is surely not right at this point.  I tried
out 38.2esr from a linux-mint live-cd and there was no problem printing in
landscape mode.

---

However, if you'd like to reproduce the bug, here is a procedure that will
work. First, download an old ubuntu image from:
  http://old-releases.ubuntu.com/releases/10.04.4/ubuntu-10.04.4-desktop-amd64.iso
Boot this image, either in a virtual machine (that is the easiest thing to do)
or by burning it to media and re-starting your computer.  Just choose "try
ubuntu" so that you won't have bother with an install.  Click
system->administration->printing, and add a printer.  From a virtual
environment, it will probably be easiest to use a networked printer.  Then
download firefox-38.2.0esr.tar.bz2 (you can use the included old version of
firefox, or just open a terminal and use wget).  Upack the archive, run
firefox/firefox, click menu->print, switch to landscape mode, and print to the
printer you installed.  You will find that the page prints in portrait
orientation on the top 8.5in of the page, with the right-hand part of the page
cut off.

---

As far as history goes, I decided to check out some older firefox versions
that are still floating around on my disk.  Versions 29.0.1 and 17esr print
fine in landscape mode in my environment, but 31 has this issue.

---

Let me reply in advance to the inevitable criticism that I shouldn't be
running old "outdated" software.  I suppose that I'm a Luddite in a certain
sense.  But not in the traditional way --- I don't have any fear of new
technology.  Rather, I refuse to blindly adopt new technology **simply because
it is new!**  I don't accept the idea that software is better simply because
it has been labeled with a lot of buzzwords and branded as "modern."  Especially
when the new software lacks functionality that I use on a daily basis and
doesn't add any new functionality that I have any need or desire for.  I would
actually be happy to stay with firefox-17 if it weren't for safety issues.
The new pdfjs bug, in particular, seems really worrisome.  (My cups server
doesn't accept nework connections so that isn't a worry for me.)

Comment 18

[Charles Robertson]

Hi. I was recently hired as a Firefox maintainer for SUSE and I've been looking into this issue for some time now. We have several major customers who use landscape printing but are unable to print landscape and need a fix as soon as possible. As I am not very familiar with Firefox code (let alone the printing code) I hope with the information I provide here someone can point me in the right direction for a solution. I can readily reproduce this issue with Firefox 30 and up by choosing landscape orientation (of course), press "print" and choose "Print to File" and printing to a Postscript file and using Gostscript (gs) to view the Postscript file as it should actually be printed. The correct display for landscape orientation should show the text and objects rotated vertical. But this is never the case. Firefox 30 and up the Gostscript view shows things in horizontal orientation. So it appears that the new printing code in Firefox 31esr and above does not rotate the contents of the Postscript output even though the Postscript header declares "%%Orientaion: Landscape"

For Firefox 31esr to fix this printing landscape issue we had to apply the following patch:
=========================================================================================================
diff --git a/gfx/src/nsDeviceContext.cpp b/gfx/src/nsDeviceContext.cpp
--- a/gfx/src/nsDeviceContext.cpp
+++ b/gfx/src/nsDeviceContext.cpp
@@ -389,21 +389,17 @@ nsDeviceContext::CreateRenderingContext(
     // and EndPage().  But we can get away with fudging things here, if need
     // be, by using a cached copy.
     if (!printingSurface) {
       printingSurface = mCachedPrintingSurface;
     }
 #endif
     nsRefPtr<nsRenderingContext> pContext = new nsRenderingContext();
 
-    RefPtr<gfx::DrawTarget> dt =
-      gfxPlatform::GetPlatform()->CreateDrawTargetForSurface(printingSurface,
-                                                             gfx::IntSize(mWidth, mHeight));
-
-    pContext->Init(this, dt);
+    pContext->Init(this, printingSurface);
     pContext->ThebesContext()->SetFlag(gfxContext::FLAG_DISABLE_SNAPPING);
     pContext->Scale(mPrintingScale, mPrintingScale);
 
     return pContext.forget();
 }
 
 nsresult
 nsDeviceContext::GetDepth(uint32_t& aDepth)
=========================================================================================================

(NOTE: Searching through the changesets using "hg log" I found one developer applied the exact same patch to fix a bug. See changeset: 200022:07e9f010bf08.)

However, now we are trying to support Firefox 38esr on SUSE Enterprise for our customers and have discovered the printing code has been significantly rewritten where the above patch will no longer apply. 

For Firefox 38esr, since it appears the rotation of the postscript contents is no longer performed with the new printing code can someone look into this and possibly provide an answer on how this can be done?


P.S. Printing with CUPS<1.6 will print the landscape oriented postscript as portrait. CUPS>=1.6 I found out several base printing filters were moved out of the CUPS sources into the separated "cups-filters" software that is provided by the OpenPrinting workgroup of the Linux Foundation. These third-party filters have the capability of reformatting the Postscript data which is why the printouts come out correctly in landscape even when the Postscript contents are not rotated.

Comment 19

[:Gijs (he/him)]

Daniel, can you confirm/investigate using the steps at the top of comment 18 (and/or taking into account the note at the bottom of that comment) ?

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Charles Robertson from comment #18)
> (NOTE: Searching through the changesets using "hg log" I found one developer
> applied the exact same patch to fix a bug. See changeset:
> 200022:07e9f010bf08.)

To be clear, here Charles is referring to this changeset: https://hg.mozilla.org/releases/mozilla-esr31/rev/07e9f010bf08
which is "Backout bug 991767 for causing bug 1003707. a=lsblakk "

(This is the bug that Gijs identified in comment 5, FWIW.)

mattwoodrow is a better person to look into this & suggest something for ESR38, given that he authored patches for both of the bugs mentioned in this commit message. (bug 991767, bug 1003707)  Punting needinfo to him.

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] (less responsive Oct 9-12 & 15-18) from comment #20)
> To be clear, here Charles is referring to this changeset:
> https://hg.mozilla.org/releases/mozilla-esr31/rev/07e9f010bf08
> which is "Backout bug 991767 for causing bug 1003707. a=lsblakk "

Notes on timeline/changeset history:
 * This ^ backout landed on mozilla-release, in the Firefox 29 timeframe.
 * Bug 991767 was landed (separately) on Aurora for Firefox 30 as https://hg.mozilla.org/releases/mozilla-aurora/rev/668a99c8678e
 * That eventually merged to release for Firefox 30 and then was in mozilla-esr31 (with the same changeset ID), so the CreateDrawTargetForSurface call is there in ESR31's latest nsDeviceContext.cpp version.
 * SO: SUSE was basically re-taking Firefox 29's backout on ESR 31, after the patch was re-landed in Aurora for Firefox 30. Or something like that.

In any case, the main issue here is what to do about ESR38 now, I guess.

Comment 22

[Daniel Holbert [:dholbert]]

Also: I *can* reproduce this after all, using e.g. my attached testcase or about:home.  The relevant bit of STR that I was missing was that you need to print *to PS format* (NOT pdf, the default for me).

I'm using Ubuntu 15.10 beta with Firefox Nightly.

Comment 23

[Daniel Holbert [:dholbert]]

(So presumably the CreateDrawTargetForSurface call quoted in comment 18 is faulty in some way -- perhaps because mWidth & mHeight need to be swapped if we're in landscape mode, and/or because we need to apply a rotation somewhere if we're in landscape mode.)

[Marking esr38 as affected per comment 18 & Nightly 44 as affected per comment 22.  Assuming supported versions in between are affected, too; I spot-checked current release (41) and confirmed that it's affected, too.]

Comment 24

[Matt Woodrow (:mattwoodrow)]

Looks like we're missing this code:

https://hg.mozilla.org/releases/mozilla-esr31/file/07e9f010bf08/gfx/thebes/gfxContext.cpp#l90

Comment 25

[Matt Woodrow (:mattwoodrow)]

Attachment: ps-printing-fix

I don't have a linux env handy right now so haven't tested this, but I think it should fix the problem.

Comment 26

[Charles Robertson]

Thank you for the quick response. I took your patch and applied it to my copy of mozilla-esr38 and got the following build error:

.../gfx/src/nsDeviceContext.cpp:433:47: error: conversion from ‘const nsIntSize’ to non-scalar type ‘mozilla::gfx::IntSize’ requested
...IntSize size = printingSurface->GetSize();
                                        ^

On line 433 of your fix does IntSize need to be nsIntSize?

Comment 27

[Daniel Holbert [:dholbert]]

The attached patch is for mozilla-central, but I'm betting Charles is still building with mozilla-esr38. (And some backport tweaks will likely be required to make whatever mozilla-central patch we take here apply on mozilla-esr38.)  The build issue Charles is seeing is likely due to a mass nsIntSize/IntSize conversion that happened sometime recent-ish.

In any case, focusing on mozilla-central for the moment -- I can build with the attached patch successfully, but it doesn't help -- it makes the printed output going from being awkwardly rotated/cut off to now being completely blank.

Comment 28

[Matt Woodrow (:mattwoodrow)]

Attachment: ps-printing-fix v2

Does this work better? I had the transform order wrong.

Comment 29

[Daniel Holbert [:dholbert]]

Comment on attachment 8674012 [details] [diff] [review]
ps-printing-fix v2

Yup, that fixes it! Thanks!

(Charles, if you want to test this on ESR38, I think your suggested adjustment in comment 26 is the right way to get it to build there.)

Comment 30

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/036e241fd1b4

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/036e241fd1b4

Comment 32

[Charles Robertson]

(In reply to Daniel Holbert [:dholbert] from comment #29)
> Comment on attachment 8674012 [details] [diff] [review]
> ps-printing-fix v2
> 
> Yup, that fixes it! Thanks!
> 
> (Charles, if you want to test this on ESR38, I think your suggested
> adjustment in comment 26 is the right way to get it to build there.)

Sorry, I was out of town for a few days. I manually applied your patch to mozilla-esr38 with the adjustment IntSize->nsIntSize and it worked perfectly. We also came up with a patch that does the same thing but slightly different. Since you have already resolved this issue I'll just post it here in the comment for your review if interested:
(applies to mozilla-esr38)
================================================================================================
diff --git a/gfx/src/nsDeviceContext.cpp b/gfx/src/nsDeviceContext.cpp
--- a/gfx/src/nsDeviceContext.cpp
+++ b/gfx/src/nsDeviceContext.cpp
@@ -411,17 +411,30 @@ nsDeviceContext::CreateRenderingContext(
                                                              gfx::IntSize(mWidth, mHeight));
 
 #ifdef XP_MACOSX
     dt->AddUserData(&gfxContext::sDontUseAsSourceKey, dt, nullptr);
 #endif
     dt->AddUserData(&sDisablePixelSnapping, (void*)0x1, nullptr);
 
     nsRefPtr<gfxContext> pContext = new gfxContext(dt);
-    pContext->SetMatrix(gfxMatrix::Scaling(mPrintingScale, mPrintingScale));
+
+    gfxMatrix transform;
+    if (printingSurface->GetRotateForLandscape()) {
+      // Rotate page 90 degrees CW aroung the origin and move the result by its
+      // height to draw landscape page on portrait paper
+      // (the Y axis grows downwards, hence the opposite sign for rotation)
+      gfxMatrix rotate(  0,  1,
+                        -1,  0,
+                       printingSurface->GetSize().height, 0);
+      transform *= rotate;
+    }
+    transform.Scale(mPrintingScale, mPrintingScale);
+
+    pContext->SetMatrix(transform);
     return pContext.forget();
 }
 
 nsresult
 nsDeviceContext::GetDepth(uint32_t& aDepth)
 {
     if (mDepth == 0 && mScreenManager) {
         nsCOMPtr<nsIScreen> primaryScreen;
================================================================================================

Thank you for jumping on this so quickly and coming up with a solution.