Incorrect handling of orientation when printing PDF files

Bug #1243484 reported by Stephane Peter on 2013-10-23
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
CUPS
Confirmed
Medium
Poppler
Fix Released
Medium
cups-filters (Ubuntu)
Undecided
Unassigned
poppler (Ubuntu)
Undecided
Unassigned

Bug Description

There seems to be some problems in the CUPS filters handling PDF files, which can be shown without having an actual printer hooked up (this seems to be independent of the driver in use).

This happens on the latest Ubuntu 13.10 but I believe the real culprit is in the cups-filters 1.0.40 package.

This happens when trying to print a PDF file (such as the CUPS test page in /usr/share/cups/data/default.pdf) and trying to change its orientation with the 'landscape' option, as such :

lp -d queue -o landscape /usr/share/cups/data/default.pdf

The result right now would be that the job is upside down, instead of being in a landscape orientation.

This happens regardless of the driver. The same behavior doesn't happen for documents such as PostScript files, which works as expected, at least with a PS printer.

The easiest way to test this is to set up queues that print to file (enable FileDevice in the CUPS config first) and look at the resulting files with a document viewer such as evince :

- Create a new Generic Postscript queue using the default drivers, set it to print to a URI such as file:///tmp/test.ps
- Send a PDF job to the queue with the landscape option
- Look at the output in evince or Ghostview

I strongly suspect something is amiss with the pdftopdf filter's handling of these options, especially in v1.0.40. Fedora 19 didn't exhibit the same problem until the cups-filters package was brought up to the same version just today.

I also suspect that more than the orientation options are affected, we have had reports from customers having trouble with options handled through the Collate PPD options.

Problem description:

with LibreOffice 3.5.3.2
Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80

print 2 pages per sheet on a brother MFC-J6510DW:
- OOO uses by default orientation landscape. print output: sheet=portrait with 1 1/2 pages (1/2 is truncated) centered in portrait orientation.
- change orientation manually to portrait: print output: sheet=portrait with 2 pages centered in portrait orientation.

Brother_MFC-J6510DW is a strange printer! paper feed an ADF is rotated by 90° against each other.
but only the printer should be interested in that.

print 2 pages per sheet from a pdf-file printed with okular (kde pdf-reader) works fine.

Steps to reproduce:
1. ....
2. ....
3. ....

Current behavior:
sheet=portrait with 1 1/2 pages (1/2 is truncated) centered in portrait orientation.

Expected behavior:
sheet=landscape with 2 pages in portrait orientation

Platform (if different from the browser):

Browser: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Created attachment 61672
current and expected behavior

I'm experiencing this bug too. When printing two pages per sheet, the output is misoriented, such that the two pages are [partially] printed in landscape where the sheet has portrait orientation. That is, the text is restricted (and truncated) to a band across the middle of the sheet.

The printing engine is not rotating the text appropriately in order to fit two pages on one sheet.

The printing error happens exactly the same regardless of the setting of Paper Orientation in the printer Properties, whether portrait or landscape is used there.

Incidentally Bug #46341 sounds like the same bug.

Works perfect with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8d39b7]" (tinderbox: W2008R2@16-minimal_build, pull time 2012-06-20 04:38:46) and Oki 14ex (others not tested).

@Drew Parsons
With info concerning OS, LibO version, Printer and so on your Comment 2 would have been much more valuable.

@Reporter:
that 2 pages per sheet function also is available for Calc, Draw, ... . Is your problem really limited to Writer?

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

the problem occurs also in impress!
so involved component of reported bug should be changed to "Printing" ???

problem still exists with:

with LibreOffice 4.0.0.3 under Linux (openSUSE 12.2 with all patches)

works fine when creating a normal (non-multipage) PDF and printing PDF with Okular or AdobeReader.

PDF multipage test:

Since the build-in PDF creator does not support printing multipage, I printed a PDF using CUPS and Ghostscript.
So one could utilize the regular LibreOffice Print dialog.

There, printing 2 pages per sheet worked fine.

So the multipage printing problem persist when directly printing to (certain) printers.

PS: Me too, having a brother MFC (MFC-8460N).
    However, multpage printing with other programms works.
    (Okular, AdobeReader, Kwrite, etc.)

Version is the oldest version that we see the issue, not the latest we've tested. We just use comments to say we've tested on a newer release and it's still a problem.

Changing version back.

I confirm that the problem still exists with:
4.0.3.3 LibreOffice on Linux x86_64 and HP printer.
OpenOffice 3.3 doesn't have this bug.
I use OpenOffice to print, or (as was written above) export to pdf and print pdf 2-in-1.

Why is it marked assigned now? Who is it assigned to?

4.1.1.2 The problem still exists. Solve, please.

Patches are more than welcome....feel free to dig into the code which is ready to be hacked at

4.1.1.2 The problem still exists. Solve, please.
The situation as in attachement
https://bugs.freedesktop.org/attachment.cgi?id=61672

97 comments hidden view all 119 comments
Till Kamppeter (till-kamppeter) wrote :

Tim, can it be that this problem is caused by your most recent changes concerning landscape PDF handling?

Tim Waugh (twaugh) wrote :

It exposed a pre-existing bug in pdftopdf. Run it through just the pdftopdf fliter and you'll see the same output (or at least I do).

Tim Waugh (twaugh) wrote :

Note: if you change the behaviour of pdftopdf, please make sure it keeps its output in the correct orientation ready for rasterization.

Till Kamppeter (till-kamppeter) wrote :

Tobias, can you have a look into this?

Stephane Peter (megastep) wrote :

Also see a somewhat tangential issue I reported with pdftopdf, which may be part of this :

https://bugs.linuxfoundation.org/show_bug.cgi?id=1167

Till Kamppeter (till-kamppeter) wrote :

Stephane, thanks, I have fixed this duplex issue upstream now.

Stephane Peter (megastep) wrote :

Any progress for a resolution of this orientation bug?

Till Kamppeter (till-kamppeter) wrote :

Can be caused by Poppler, I am currently investigating this.

Please follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

Changed in poppler (Ubuntu):
status: New → Incomplete
Changed in cups-filters (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package poppler - 0.24.3-0ubuntu2

---------------
poppler (0.24.3-0ubuntu2) trusty; urgency=low

  * debian/patches/pdftops-origpagesizes-fixes.diff: Output of "pdftops
    -origpagesizes" was broken, especially PDFs which have a rotation set
    (for example from the pdftopdf from cups-filters) are turned into
    PostScript files without this rotation. This leads to problems with
    Landscape-oriented printouts, especially on mobile devices where only
    Poppler is available and no Ghostscript for doing PDF->PS conversion
    (Red Hat bug #768811, LP: #1243484, LP: #1247740).
 -- Till Kamppeter <email address hidden> Tue, 3 Dec 2013 18:01:33 +0100

Changed in poppler (Ubuntu):
status: Incomplete → Fix Released
10 comments hidden view all 119 comments
Download full text (3.5 KiB)

Created attachment 90227
pdftops-origpagesizes-fixes.diff

In reality the fix is in the PostScript output device, but there is no appropriate item to select as component.

There are some distro bug reports about Landscape-oriented page printing with CUPS (1.6.x or newer), cups-filters, and PDF->PostScript conversion with Poppler's "pdftops":

https://bugzilla.redhat.com/show_bug.cgi?id=768811
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1243484
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1247740

As a quick workaround distro package maintainers have removed the "-origpagesizes" from the call of Poppler's /usr/bin/pdftops by the /usr/lib/cups/filter/pdftops filter of cups-filters. I have not taken this workaround patch upstream into cups-filters as the real problem is in Poppler's PostScript output device.

When printing with CUPS 1.6.x or newer print jobs in PDF format are first treated by the pdftopdf filter (of cups-filters). One thing this filter does is rotating Landscape-oriented pages by 90 degrees for printers which take their paper only short-edge first (portrait orientation). For this rotation not the actual file content is rotated, but a rotation field is set (usually incremented by 90). You can see it by running "pdfinfo" on the input and on the output of pdftopdf. If the first page of the PDF file is Landscape-oriented, the "Page rot:" entry will change by 90 degrees.

I have displayed such a PDF file with several different viewers (evince, gs, gv) and the rotation field is taken into account, Landscape-oriented pages are rotated. Only when I run such a file through

pdftops -origpagesizes

the rotation is not taken into account and in the resulting PostScript file the Landscape-oriented pages appear unrotated, leading to wrong printouts when the /usr/lib/cups/filter/pdftops filter calls "pdftops -origpagesizes". This was leading to the wrong printouts the users complained about in the bug reports. The workaround of dropping "-origpagesizes" works well if all pages of the input document are of the same size but if they are variable sizes, pages can get cut or squeezed (this is why I contributed the "-origpagesizes" mode to Poppler earlier).

I looked into the implementation of "-origpagesizes" and realized that I forgot to take the rotation field into account. I also realized that the paperMatch mode of the normal PostScript output mode (if you run pdftops without "-paper", "-paperw", and "-paperh") is very similar to "-origpagesizes" and takes the rotation field into account.

So my attached patch folds the "-origpagesizes" mode implenmentation into paperMatch and only does slight modifications. The original paperMatch mode behavior is conserved to not break other programs using it.

The differences of the new "-origpagesizes" mode are the following:

1. The rotation fields of the input PDF pages are taken into account.

2. The "%%DocumentMedia: ..." and following "%%+ ..." lines are removed. Most PostScript displayers assume all pages being of the size in the "%%DocumentMedia: ..." line. Without these lines they have no problems displaying each page in the correct size.

3. The output pages are never centere...

Read more...

Created attachment 90228
CityMap-pdftopdf.pdf

Sample file:

till@till-twist:~$ pdfinfo CityMap-pdftopdf.pdf
Creator: Adobe InDesign CS3 (5.0.4)
Producer: Adobe PDF Library 8.0
CreationDate: Thu Jul 9 10:24:27 2009
ModDate: Thu Jul 9 10:24:31 2009
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 841.89 x 595.276 pts (A4)
Page rot: 90
File size: 326314 bytes
Optimized: no
PDF version: 1.4
till@till-twist:~$

As one can see at the "Page size:" and "Page rot:" entries, this file is Landscape-oriented and got rotated by 90 degrees. Without my patch the output of

pdftops -origpagesizes CityMap-pdftopdf.pdf

is not rotated, with my patch it is.

Created attachment 90229
A4-A3-A4-3-pdftopdf.pdf

This file (example for a book with a fold-out page) is created with LibreOffice and run through pdftopdf. It contains 3 pages:

1. A4 portrait, no rotation
2. A3 landscape, 90 degree rotation
3. A4 portrait, no rotation

So page size, orientation, and rotation vary.

Printing with the workaround of dropping "-origpagesizes" fails:

pdftops A4-A3-A4-3-pdftopdf.pdf

makes the second page being cropped to A4 portrait.

pdftops -paper A4 A4-A3-A4-3-pdftopdf.pdf

makes the second page being squeezed into A4 portrait.

In both cases the second page is correctly rotated.

So "-origpagesizes" is needed and without my patch

pdftops -origpagesizes A4-A3-A4-3-pdftopdf.pdf

leaves the second page unrotated and so on a printer which loads A3 paper short-edge-first the second page is not correctly printed. With my patch it gets rotated. The leaving out of the "%%DocumentMedia: ..." line in the PostScript output also assures that all PostScript viewers can cope with the changing page sizes.

Created attachment 90232
launch_leaflet-pdftopdf.pdf

This is the odd file which needs centering being suppressed when converting to PostScript with "-origpagesizes". It consists of 7 pages. The first and the last are A5 portrait but somewhat broken, the rest is A4 landscape and treated absolutely correctly with my patch already before I added the suppressing of centering. The first and last page seem to be in an invisible A4 landscape frame and in the PostScript output they are moved half out of the A5 portrait frame when centering is in place. With my patch as it is attached the PostScript output is correct.

Note that I have folded the "-origpagesizes" mode into the matchPaper mode but I have taken into account that the matchPaper mode's output does not change and the the "-origpagesizes" mode gives correct output for printing. Feel free to change the matchPaper mode so that it is equal with the "-origpagesizes" mode, but do not modify the "-origpagesizes" mode as long as it is not for fixing another odd file's output. Make sure that all the attached files keep giving the correct output.

13 comments hidden view all 119 comments

The problem is caused by the auto rotation done by pdftopdf which makes the pages rotated to print short-edge-first if the printer requires this. If your original page is portrait and you request landscape, pdftopdf rotates it by 90 degrees and after that pdftopdf applies auto rotation and rotates the page by another 90 degrees putting it upside down (180 degrees).

Please try the "nopdfAutoRotate" option:

lp -d queue -o landscape -o nopdfAutoRotate /usr/share/cups/data/default.pdf

Is this what you are looking for?

All PDF files have already defined geometries for each page and the auto-rotation of pdftopdf rotates landscape pages when the printer pulls in the paper only in portrait orientation. So simply sending a PDF file without the "landscape" option does usually the right thing.

The "landscape" option makes more sense if the input data has no ready layout, like plain text. texttopdf will layout the text on landscape-oriented pages with this option.

So why are you using the "landscape" option in your particular case?

So for text files it would make more sense if pdftopdf ignores the "landscape" option as texttopdf is already doing the job. For PDF files you usually decide in the desktop application whether it should be landscape-oriented, so here pdftopdf applying a "landscape" option is also not of much sense.

Stephane Peter (megastep) wrote :

Thanks for the clarifications, and the nopdfAutoRotate option does seem to help somehow. However, I believe the problem is still present for a couple of important reasons. The initial report used PDF files and a generic queue as a way to easily expose the problem, but it affects more than this. I generally agree with you that using landscape with stock PDF files does not particularly happen much.

- Most importantly, in most recent Linux distributions that have adopted the PDF workflow, this affects also Postscript jobs, which get converted internally to PDF and then handled by pdftopdf.
- This breaks the semantics of the job options, and our customers in turn put the blame on us (providing the PPD driver) when this stops working for queues that previously handled the 'landscape' option consistently for their jobs.

The core of the issue here is that in spite of the switch to the PDF workflow, there are still a lot of customers with legacy PS output that needs to be handled consistently, and we expect the core of the print system to not interfere with this whenever possible.

13 comments hidden view all 119 comments
12 comments hidden view all 119 comments

PostScript files are also readily layouted documents as PDF files. So if you create something printable from a desktop app which still sends print jobs in PostScript, you also determine in the app whether the pages are landscape- or portrait-oriented. So on PostScript jobs the "landscape" option also does not make much sense.

And as I said, for plain text "landscape" should determine the layout used by texttopdf.

Can you attach PostScript (or PDF) files where your customers would use the "landscape" option? And can you tell me why they use the "landscape" option? Are their printers holding A4 paper to be printed long-edge first? Or are there other reasons?

Stephane Peter (megastep) wrote :

Not to be pedantic, but while this is not very usual (especially for PS code produced by vanilla applications), it is a lot easier for PS code to be more adaptive. The CUPS test page is actually a good example of this. PDF is generally completely constrained by the page dimensions.

The main reason this came up is because of acceptance tests that the QA department of one of our customers ran with the latest versions of Linux distributions. They noticed that the behavior for certain PDF and PS files changed from what it used to be, and whether or not this is a practical everyday use, this in turn was interpreted as not conforming to the expected output. And to the extent that the format of the output changed for the same files with the exact same job options, they were technically correct...

The "landscape" option is a shortcut for the IPP standard option "orientation-requested=3" and RFC 2911 (http://tools.ietf.org/search/rfc2911) tells about the meaning of "orientation-requested=...":

----------
   This attribute indicates the desired orientation for printed print-
   stream pages; it does not describe the orientation of the client-
   supplied print-stream pages.

   For some document formats (such as 'application/postscript'), the
   desired orientation of the print-stream pages is specified within the
   document data. This information is generated by a device driver
   prior to the submission of the print job. Other document formats
   (such as 'text/plain') do not include the notion of desired
   orientation within the document data. In the latter case it is
   possible for the Printer object to bind the desired orientation to
   the document data after it has been submitted. It is expected that a
   Printer object would only support "orientations-requested" for some
   document formats (e.g., 'text/plain' or 'text/html') but not others
   (e.g., 'application/postscript'). This is no different than any
   other Job Template attribute since section 4.2, item 1, points out
   that a Printer object may support or not support any Job Template
   attribute based on the document format supplied by the client.
   However, a special mention is made here since it is very likely that
   a Printer object will support "orientation-requested" for only a
   subset of the supported document formats.
----------

Following this, pdftopdf should ignore "landscape" and "orientation-requested" and texttopdf and imagetopdf should use it for layouting the job. To server special, size-less PostScript files, the "landscape" and "orientation-requested" should also be taken by the pstopdf filter and swap width and length of the page size supplied to Ghostscript for the PS->PDF conversion. WDYT?

Stephane Peter (megastep) wrote :

I would tend to agree with your assessment. The cause of the problems right now seem to be some duplication of the handling of these options between the various involved filters, so that should probably be streamlined.

For reference, I am attaching the PS test page that was used by our customer to exhibit the issues. It is admittedly handcrafted, so it is not representative of what may be generated by an office application.

10 comments hidden view all 119 comments
Download full text (3.9 KiB)

Thanks for the patch. Generally it is better if each change is in a separate patche. It makes it easier to review and easier to git bisect if there are regressions.

> When printing with CUPS 1.6.x or newer print jobs in PDF format are first
> treated by the pdftopdf filter (of cups-filters). One thing this filter does
> is rotating Landscape-oriented pages by 90 degrees for printers which take
> their paper only short-edge first (portrait orientation). For this rotation
> not the actual file content is rotated, but a rotation field is set (usually
> incremented by 90). You can see it by running "pdfinfo" on the input and on
> the output of pdftopdf. If the first page of the PDF file is
> Landscape-oriented, the "Page rot:" entry will change by 90 degrees.

The filter is rotating landscape pages the wrong way. Landscape pages on a portrait oriented sheet should be rotated 90 degrees counterclockwise. Your filter is rotating 90 degrees clockwise.

Have a look at any book that has tables in landscape orientation. It is always rotated counterclockwise. The reason is if you rotate the book to the read the landscape page the lower page number should be at the top and you can advance to the next sheet by turning the page at the bottom.

See also the PS Language Ref Manual 3d ed. page 401: "... rotates the default user space for landscape orientation 90 degrees counterclockwise with respect to that for portrait orientation."

> The differences of the new "-origpagesizes" mode are the following:
>
> 1. The rotation fields of the input PDF pages are taken into account.

Looks ok to me. I tried it with your test cases and it fixes the problem.

> 2. The "%%DocumentMedia: ..." and following "%%+ ..." lines are removed.
> Most PostScript displayers assume all pages being of the size in the
> "%%DocumentMedia: ..." line. Without these lines they have no problems
> displaying each page in the correct size.

This one I disagree with. The bug is in poppler, not the PS viewers. Looking at the PS output of launch_leaflet-pdftopdf.pdf without your patch:

%%DocumentSuppliedResources: (atend)
%%DocumentMedia: 840x596 840 596 0 () ()
%%BoundingBox: 0 0 840 596

There is only one media size listed even though I can see different page sizes in evince and acroread:

The first page which according to acroread has a page size of 5.83 x 8.27" has this:

%%Page: 1 1
%%PageMedia: 840x596
%%PageBoundingBox: 0 0 840 596
%%PageBoundingBox: 0 0 420 596
%%BeginPageSetup
%%PageOrientation: Portrait
<</PageSize [420 596]>> setpagedevice
pdfStartPage
0 0 420 596 re W
%%EndPageSetup

Obviously there should not be two page bounding boxes. Your patch gets rid of the second one. The setpagedevice operator and one of the page bounding boxes has the correct size but the %%PageMedia is wrong.

Removing %%DocumentMedia prevents the %%PageMedia from being used so the viewer falls back to the size set in setpagedevice. This just papers over the bug.

The cause of this bug is that the first page of launch_leaflet-pdftopdf.pdf has MediaBox set to 840x596 and CropBox set to 420x596. The code that outputs the DocumentMedia lines is using the media box while the page size on each page is the ...

Read more...

> The filter is rotating landscape pages the wrong way.

OK, I will fix pdftopdf to rotate counterclockwise by default (if the PPD does not state otherwise).

>> 2. The "%%DocumentMedia: ..." and following "%%+ ..." lines are removed.
[...]
> This one I disagree with.
[...]
> The cause of this bug is that the first page of launch_leaflet-pdftopdf.pdf has
> MediaBox set to 840x596 and CropBox set to 420x596. The code that outputs the
> DocumentMedia lines is using the media box while the page size on each page is
> the crop box. This should be fixed so the sizes in the DocumentMedia/PageMedia
> is consistent with the size used by the setpagesize operator.

So should all use the CropBox here? Will you fix that?

>> 3. The output pages are never centered
[...]
> This one I also disagree with.

No problem, I can add "-nocenter" to the pdftops call in cups-filters and you leave out this last hunk of my patch.

I have fixed the pdftopdf filter in cups-filters now, rotating counter-clockwise by default and (cups-filters BZR rev. 7136) and I have added "-nocenter" to the

I have fixed the pdftopdf filter in cups-filters now, rotating counter-clockwise by default and (cups-filters BZR rev. 7136) and I have added "-nocenter" to the "pdftops -origpagesizes" call (cups-filters BZR rev. 7137).

12 comments hidden view all 119 comments

I have now tested your test-tmpl.ps file and dine some fixes on the pstopdf, pdftopdf, and pdftops filters. Now I get correct results with it. The fix will get into Ubuntu with the release of cxups-filters 1.0.43. Please test when the package gets available in Trusty (use a live CD/USB stick or a virtual machine if you do not have Trusty installed).

13 comments hidden view all 119 comments

Adrian, you taken care of this? I got lost in the middle in the discussion :D

Created attachment 90792
ensure page size takes into account rotation

The page rotation part of Till's patch.

Created attachment 90793
fix media DSC comments

This fixes the DSC media size and bbox comments to ensure they are consistent with the selected page size.

Created attachment 90794
fix center bug when using crop box as page size

I had a look at why the page centering was not working correctly with launch_leaflet-pdftopdf.pdf. The reason is the different media box and crop box sizes. If the -nocrop option is not used the crop box is assumed to be the page size. But the centering code was still trying center the page within the media box size.

While working on this I found another problem with the page size setup. With -origpagesizes setpagedevice is output twice. The first time by the pdfSetupPaper PS macro (which calls setoutputdevice) using imgURX, imgURY which is the media box size. Then setpagedevice is output with width, height.

There is also this comment

// Set page size only when it actually changes, as otherwise Duplex
// printing does not work

so I'm not sure how this can be correct since the pdfSetupPaper is unconditionally calling setpagedevice.

Till, could you look at this and see if it can be fixed to only output setpagedevice once (preferably using the pdfSetupPaper macro since that is what is used for mode = psModePS.

Adrian, I have done a test with my HP Color LaserJet CM3530 MFP now. I have used pdftops with my original patch. With the output of pdftops (both "pdftops -origpagesizes" and "pdftops -paper A4") duplex printing does not work. If I comment out the pdfSetupPaper macro calls in the PageSetup sections of each page, duplex works. so the pdfSetupPaper macro actually breaks duplex.

So what has to be done is to do a setpagedevice of the page size only if it has changed compared to the previous page. Unfortunately, I have not enough knowledge in PostScript programming to fix the macro, so I am asking you whether you could fix it.

I am not sure whether the macro only does the equivalent of

<</PageSize[595 842]/ImagingBBox null>>setpagedevice

In this case we could simply skip its call when the paper size does not change (at least when I comment it out I get a correct printout and duplex works).

Additional note: The problem of duplex not working is not only there if "-origpagesizes" is used but also in the other modes of pdftops (I tested also with "-paper A4".

Comment on attachment 90793
fix media DSC comments

Review of attachment 90793:
-----------------------------------------------------------------

::: qt5/src/poppler-ps-converter.cc
@@ +224,4 @@
> d->paperWidth,
> d->paperHeight,
> gFalse,
> + gFalse,

this is probably needed in the qt4/ one too

While fixing some more bugs I was looking into why we have the origPageSizes mode when "-paper match" seems to do the same thing. The current code, without the patches in this bug applied, does the following:

The "-paper match" option uses the media box as the paper size and the crop box as the pdf page size. The -expand -noshrink and -nocenter options change the scale and position of the pdf page within the paper. If "-nocrop" is used the pdf page size is the media box.

The "-origpagesizes" option uses the crop box as the paper size (unless -nocrop is used in which case the media box is the paper size). No scaling or translating is performed.

The problem with "-paper match" is it is using media box as the page size but the glib and qt frontends use crop box as the page size. Acroread uses the crop box as the page size for both display and printing.

The problem with "-origpagesizes" is, in addition to the rotate bug, if the crop box has a non zero origin the output will not be positioned correctly since there is no attempt to translate the origin.

My proposed solution is to make "-paper match" use the crop box as both the paper size and pdf page size. This is consistent with acroread. The -nocrop option will use the media box as the paper and page size. Then remove the psModePSOrigPageSizes mode from PSOutputDev and make the "-origpagesizes" option in pdftops.cc an alias for "-paper match". Till's patch has started moving in this direction by sharing the paperMatch code for both "-paper match" and "-origpagesizes". With the paper size and pdf page size equal to the crop box the output should be identical to what is displayed on the screen no matter what the scale or center options are set to. If this is not the case we should fix the scale/translate code instead of trying to bypass it resulting in the crop box origin bug.

(In reply to comment #15)
> I am not sure whether the macro only does the equivalent of
>
> <</PageSize[595 842]/ImagingBBox null>>setpagedevice
>
> In this case we could simply skip its call when the paper size does not
> change (at least when I comment it out I get a correct printout and duplex
> works).

That is basically all the macro does. It also checks if the setpagedevice operator exists before calling it.

So yes we could just skip calling the macro when the page size does not change. Alternatively I could change the macro to only change the page size if it is different to the previous page. This has the advanatge of preserving page independence as required by the DSC specification. ie the macro will be output for every page so pages can be printed in any order and the correct page size will be used but the macro will not alter the page size if the page size in the page device dictionary is already correct.

Created attachment 90835
pdftops-origpagesizes-fixes-qt4.patch

Missing Qt4 change.

22 comments hidden view all 119 comments

cups-filters 1.0.43 (with the fix) released upstream.

Changed in cups-filters (Ubuntu):
status: Incomplete → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups-filters - 1.0.43-1

---------------
cups-filters (1.0.43-1) unstable; urgency=medium

  * New upstream release 1.0.43:
    - pdftopdf: Fixed software copy generation logic for printers
      with hardware copy generation, but without collate support
      (LP: #1259240).
    - pstopdf: Support for the "landscape" and
      "orientation-requested" options (LP: #1243484).
  * Drop all patches:
    - PATH_MAX fix was from upstream;
    - The Fedora fix for PDF landscape printing got included
      differently.
  * Update debian/watch to prefer .xz tarballs
  * Install manpages for cups-browsed and foomatic-rip

 -- Didier Raboud <email address hidden> Thu, 19 Dec 2013 19:29:49 +0100

Changed in cups-filters (Ubuntu):
status: Fix Committed → Fix Released

The Poppler fix is still under test to make sure that there are no regressions. See

https://bugs.freedesktop.org/show_bug.cgi?id=72312

As soon as it finalizes I will look into backporting it to 13.10.

Changed in poppler:
importance: Unknown → Medium
status: Unknown → Confirmed
80 comments hidden view all 119 comments

I'm confirming this behavior persists in Draw v4.1.2.3 Build ID:410m0(Build:3).

It does _not_ require printing 2 pages per sheet: put page in landscape mode, print -> prints in portrait mode with right side clipped. Leave in landscape mode, explicitly set printer properties page orientation to landscape -> still prints in portait mode.

Title may need to be updated to reflect same behavior without printing 2sheet/page.

Successful workaround: export to PDF, print from a PDF viewer.

My printer fwiw: Brother MFC-J4700W

Fixed ?

I don't know where the problem was.
(Running LibreOffice under Linux / openSUSE 12.3)

But it looks as it has recently been fixed (somehow), either through Linux / CUPS or through LibreOffice.
I have installed all available patches to my Linux System (including apps).

The (latest) LibreOffice from the openSUSE repository is:

Version: 4.1.1.2
Build ID: 410m0(Build:2)

(Repository Version 4.1.1.2 - 1.4)

It now works with writer, calc, draw and presentation.

For me: The problem is fixed!

BTW:
It works with both of my printers:

- Brother MFC-8460N
- Samsung CLP-365

No need of PDF-work-around anymore! :-)

--NOT FIXED-- (and i guess, no one has ever done something)
with LO Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
and printer MFC-J6510DW it is still NOT working!

<email address hidden> then why not just update whiteboard with Confirmed:4.1.3.2:Linux?

why? because using the whiteboard, hanging off the wall, trying to scan the whole board and printing out each scan isn't so easy, but i will try.
sorry, joking aside: @foss: could you tell me something more about whiteboard? thanks.

24 comments hidden view all 119 comments

Ok, regtest finished, all looks good, please commit!

Changed in poppler:
status: Confirmed → Fix Released
24 comments hidden view all 119 comments

Seems to be fixed, at least I now have a successful print with 2 pages per sheet under LibreOffice 4.1.4.2 (Debian unstable), printing to HP LJ4300 via CUPS 1.7.1.

stof999 the whiteboard status does help to get a quick overview on which systems and with what versions of LO the bug does appear. There's also a script that creates a nice tabel from that whiteboard info, but the server it was on, is currently gone. So generally it is pretty useful for QA and devs.

Setting to worksforme as of Comment 21.

Please re-open if the bug persists for anybody with LO 4.2.0.4.

NOT FIXED with Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba7

i don't think, this is the way of good fixing or trying to improve a product, when regularly someone is closing the task. if there someone has something done on the code, this person should know it and resolve the task.
thanks

PS: it is also NOT working with AOO401m5(Build:9714) - Rev. 1524958
2013-09-20 11:54 - Linux x86_64

Comment 21 reported this fixed. and printer bugs are hard to verify, no one has all printer models. thanks for re-opening.

Please don't change the version - it is the oldest version that we see the issue.

Also - the workflow works given our constraints so that's not changing unless a better workflow is proposed. If we are unable to reproduce we're going to close as WFM - it is then up to the user to follow up. Our devs cannot/will not spend their valuable time - if a QA team member cannot reproduce we close as WFM and then expect users to do their part if the bug is not fixed

27 comments hidden view all 119 comments
Joshua O'Leary (jmoleary) wrote :

I have this problem in Libreoffice Writer, Impress etc. Changing the printer output format from PDF to Postscript (level 3 or 2) seems to fix it

Przemek K. (azrael) wrote :

This bug was fixed in the package poppler - 0.24.3-0ubuntu2
Can you backport it to saucy? (currently on 0.24.1-0ubuntu1)

Changed in cups:
importance: Unknown → Medium
status: Unknown → Confirmed
26 comments hidden view all 119 comments
Sebastien Bacher (seb128) wrote :

> Can you backport it to saucy? (currently on 0.24.1-0ubuntu1)

If somebody wants to work on that I can look at doing the sponsoring. I don't think the desktop team is going to work on it though, saucy is neither the current stable nor the LTS and the issue is not a security one, we would recommend updating to trusty.

--> <email address hidden>

please give an update of the bug status using latest LibO 4.3.2.2 release.
thanks for your feedback

**** not resolved !!! ***

hi

with

opensuse13.1
LO Version: 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
print via cups
2 pages per sheet
to brother MFC-J6510DW
Name : mfcj6510dwcupswrapper
Version : 3.0.0
Release : 1
Architecture: i386
Install Date: Mit 25 Jun 2014 17:47:16 CEST
Group : Applications
Size : 64256
License : 2004-2012 Brother Industries, Ltd. All Rights Reserved
Signature : (none)
Source RPM : mfcj6510dwcupswrapper-3.0.0-1.src.rpm
Build Date : Don 22 Mär 2012 09:07:35 CET
Build Host : localhost.domain
Relocations : (not relocatable)
Packager : root@localhost
Vendor : Brother Industries, Ltd.
Summary : Brother CUPS Inkjet Printer Definitions
Description :
Brother Inkjet printer CUPS Driver
Distribution: (none)

LO prints the pages still as shown in the attachment <current and expected behavior>.

thanks

and as a remember:

printing the odt as an pdf with okular (kde pdf-reader) 2 pages per sheet does the job as it should be.

thanks

sorry to hear that...

Brother printers are affected by multiple issues on LibO.
see this bugzilla query: http://snipurl.com/29cxibw

hi tommy27

as i already told, Brother_MFC-J6510DW is a strange printer! paper feed an ADF is rotated by 90° against each other. but only the printer should be interested in that.

KDE printing works.

what is the difference from LO and KDE printing? they use the same printer driver, cups, ...

i guess the problem could be somewhere in LO between prepare the print and sending it to cups?

can i do something more?
thanks

I have no experience with Linux so I can't help.

@Joel Madero
any ideas about this?

No but brother printers consistently show problems - if you do a bugzilla search you'll see quite a few hits and as far as I know we have no triagers that have a brother printer (I avoid them like the plague because it's obvious they have issues in Linux)

morris (spick) wrote :

the problem deals with the PRINTER DRIVER. SO I report the same bug affecting Kubuntu 17.04 and Brother MFC-L2700DW series with driverless cups filter 1.13. The problem is that the driver is not good.

Displaying first 40 and last 40 comments. View all 119 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.