Incorrect handling of orientation when printing PDF files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
CUPS |
Confirmed
|
Medium
|
|||
Poppler |
Fix Released
|
Medium
|
|||
cups-filters (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
poppler (Ubuntu) |
Fix Released
|
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/
lp -d queue -o landscape /usr/share/
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.
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #85 |
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #86 |
Created attachment 61672
current and expected behavior
In freedesktop.org Bugzilla #49946, Dparsons-b (dparsons-b) wrote : | #87 |
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.
In freedesktop.org Bugzilla #49946, Dparsons-b (dparsons-b) wrote : | #88 |
Incidentally Bug #46341 sounds like the same bug.
In freedesktop.org Bugzilla #49946, Libreoffice-z (libreoffice-z) wrote : | #89 |
Works perfect with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8d39b7]" (tinderbox: W2008R2@
@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?
In freedesktop.org Bugzilla #49946, Libreoffice-z (libreoffice-z) wrote : | #90 |
*** Bug 46341 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #91 |
the problem occurs also in impress!
so involved component of reported bug should be changed to "Printing" ???
In freedesktop.org Bugzilla #49946, Rgloor (rgloor) wrote : | #92 |
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.
In freedesktop.org Bugzilla #49946, Rgloor (rgloor) wrote : | #93 |
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.)
In freedesktop.org Bugzilla #49946, Jmadero-dev (jmadero-dev) wrote : | #94 |
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.
In freedesktop.org Bugzilla #49946, 100megabit (100megabit) wrote : | #95 |
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.
In freedesktop.org Bugzilla #49946, Jmadero-dev (jmadero-dev) wrote : | #96 |
Why is it marked assigned now? Who is it assigned to?
In freedesktop.org Bugzilla #49946, 100megabit (100megabit) wrote : | #97 |
4.1.1.2 The problem still exists. Solve, please.
In freedesktop.org Bugzilla #49946, Jmadero-dev (jmadero-dev) wrote : | #98 |
Patches are more than welcome....feel free to dig into the code which is ready to be hacked at
In freedesktop.org Bugzilla #49946, 100megabit (100megabit) wrote : | #99 |
4.1.1.2 The problem still exists. Solve, please.
The situation as in attachement
https:/
Till Kamppeter (till-kamppeter) wrote : | #1 |
Tim, can it be that this problem is caused by your most recent changes concerning landscape PDF handling?
Tim Waugh (twaugh) wrote : | #2 |
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 : | #3 |
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 : | #4 |
Tobias, can you have a look into this?
Stephane Peter (megastep) wrote : | #5 |
Also see a somewhat tangential issue I reported with pdftopdf, which may be part of this :
Till Kamppeter (till-kamppeter) wrote : | #6 |
Stephane, thanks, I have fixed this duplex issue upstream now.
Stephane Peter (megastep) wrote : | #7 |
Any progress for a resolution of this orientation bug?
Till Kamppeter (till-kamppeter) wrote : | #8 |
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:/
Changed in poppler (Ubuntu): | |
status: | New → Incomplete |
Changed in cups-filters (Ubuntu): | |
status: | New → Incomplete |
Launchpad Janitor (janitor) wrote : | #9 |
This bug was fixed in the package poppler - 0.24.3-0ubuntu2
---------------
poppler (0.24.3-0ubuntu2) trusty; urgency=low
* debian/
-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-
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 |
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #20 |
Created attachment 90227
pdftops-
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:/
https:/
https:/
As a quick workaround distro package maintainers have removed the "-origpagesizes" from the call of Poppler's /usr/bin/pdftops by the /usr/lib/
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/
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...
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #21 |
Created attachment 90228
CityMap-
Sample file:
till@till-twist:~$ pdfinfo CityMap-
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-
is not rotated, with my patch it is.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #22 |
Created attachment 90229
A4-A3-A4-
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-
makes the second page being cropped to A4 portrait.
pdftops -paper A4 A4-A3-A4-
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-
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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #23 |
Created attachment 90232
launch_
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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #24 |
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.
Till Kamppeter (till-kamppeter) wrote : | #10 |
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/
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 : | #11 |
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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #25 |
Also reported to Debian as
Till Kamppeter (till-kamppeter) wrote : | #12 |
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 : | #13 |
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...
Till Kamppeter (till-kamppeter) wrote : | #14 |
The "landscape" option is a shortcut for the IPP standard option "orientation-
----------
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/
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-
document formats (e.g., 'text/plain' or 'text/html') but not others
(e.g., 'application/
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-
subset of the supported document formats.
----------
Following this, pdftopdf should ignore "landscape" and "orientation-
Stephane Peter (megastep) wrote : | #15 |
- test-tmpl.ps Edit (23.9 KiB, application/postscript)
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.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #26 |
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_
%%DocumentSuppl
%%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_
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #27 |
> 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_
> 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/
> 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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #28 |
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
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #29 |
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).
Till Kamppeter (till-kamppeter) wrote : | #16 |
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).
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #30 |
Adrian, you taken care of this? I got lost in the middle in the discussion :D
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #31 |
Created attachment 90792
ensure page size takes into account rotation
The page rotation part of Till's patch.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #32 |
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.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #33 |
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_
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #34 |
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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #35 |
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).
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #36 |
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".
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #37 |
Comment on attachment 90793
fix media DSC comments
Review of attachment 90793:
-------
::: qt5/src/
@@ +224,4 @@
> d->paperWidth,
> d->paperHeight,
> gFalse,
> + gFalse,
this is probably needed in the qt4/ one too
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #38 |
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 psModePSOrigPag
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #39 |
(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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #40 |
Created attachment 90835
pdftops-
Missing Qt4 change.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #41 |
Created attachment 90836
pdftops-
The patches make "pdftops -origpagesizes" (and also pdftops without any "-paper", "-paperh", and "-paperw" arguments) work well and correctly, but using any "-paper", "-paperh", and "-paperw" argument causes an immediate segfault. The attached patch fixes this.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #42 |
Created attachment 90837
pdftops-
Adrian, attached patch addresses your comment #14. pdfSetupPaper indeed only does the setpagedevice to set the paper size. If the "-paper" argument is supplied to pdftops it is called only one time in the setup section as with a forced paper size the paper size does not change throughout the document's pages. Without "-paper" ("-origpagesizes" or paperMatch mode) pdfSetupPaper has only to be called when the page sizes change. The attached patch fixes this.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #43 |
Adrian, I did not see your comment #19 when I added my further patches, the idea to check whether the page size changed against the previous page inside the macro is really great, as one can easily re-order the pages. Can you implement this? Thanks.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #44 |
Adrian, I am absolutely OK with your idea of comment #18. Then we could really remove the last difference of "-origpapersizes" (in your patch plus my new patches) which is suppressing the centering. We only need to make sure that all sample files come out correctly.
Till Kamppeter (till-kamppeter) wrote : | #17 |
cups-filters 1.0.43 (with the fix) released upstream.
Changed in cups-filters (Ubuntu): | |
status: | Incomplete → Fix Committed |
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #45 |
Created attachment 91000
0001 - ensure page size takes into account rotation
These 5 patches fix pdftops to work as described in comment 18.
0001 - Till's patch to ensure make -origpagesizes uses the page match code.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #46 |
Created attachment 91002
0002 - fix media DSC comments
Fix the DSC comments so PS viewers use the correct page size. For common paper sizes it also uses the paper name eg "A4" as some viewers such as gv will display this name as the page size.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #47 |
Created attachment 91003
0003 - use crop box as page size
As noted in comment 18 we should be using the crop box as the page size. This also fixes the centering bug with launch_
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #48 |
Created attachment 91004
0004 - remove origpagesizes mode
The origpagesizes mode is redundant now that it is exactly the same as "-paper match". So remove the code and make -origpagesizes an alias for "-paper match".
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #49 |
Created attachment 91005
0005 - only change paper size when different to previous page
This patch puts the "don't change paper size unless different to previous page" check in the pdfSetupPaper macro. This preserves page independence allowing pages to be printed in any order since every page now contains the set page size PS code but it is only executed if different from the previous page size.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #50 |
Adrian, thank you very much.
I have applied all the five new patches instead of the old ones and tested all attached example files and also duplex printing. Everything works as intended. Please commit all the patches upstream.
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #51 |
Adrian, I'd like to run a few bare bones testing to make sure it doesn't change the behaviour of the regular pdftops command, is it ok for you if i run the tests and report back before you commit? Will take 2 or 3 days at most.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #52 |
(In reply to comment #31)
> Adrian, I'd like to run a few bare bones testing to make sure it doesn't
> change the behaviour of the regular pdftops command, is it ok for you if i
> run the tests and report back before you commit? Will take 2 or 3 days at
> most.
Yeah, better to do some reg tests before committing.
Launchpad Janitor (janitor) wrote : | #18 |
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
"
* 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 |
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #53 |
Hmm, somehow these patches make the convert utility very unhappy. For example, take https:/
pdftops -f 1 -l 1 file.pdf file.ps
convert file.ps file.png
That will work without the patches but with the patches it fails. Any idea why this may be happening?
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #54 |
Albert, I cannot reproduce your problem on Ubuntu Saucy. For me the "convert"step works perfectly.
My "convert" is from Graphicsmagick 1.3.16-1.1ubuntu2. Poppler is 1_0.24.1-0ubuntu1 with the 5 current patches from this bug report applied.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #55 |
On a Ubuntu Trusty box I have ImageMagick 6.7.7.10-6ubuntu1 and here the "convert" fails:
till@till-
Unrecoverable error: rangecheck in .putdeviceprops
Unrecoverable error: rangecheck in .putdeviceprops
convert.im6: Postscript delegate failed `file.ps': No such file or directory @ error/ps.
convert.im6: no images defined `file.png' @ error/convert.
till@till-
A direct Ghostscript call like
gs -sDEVICE=png16m -sOutputFile=
and any attempt to display file.ps on the screen (gs, gv, evince) or to print it unfiltered to a PostScript printer works.
For me it looks like a Ghostscript problem. One would need to find out which Ghostscript command line is used by ImageMagick's "convert".
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #56 |
ImageMagick is using gslib. The command passed to gslib is;
(gdb) p command
$3 = "\"gs\" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=
The output image size seems to be the problem:
-g18446744073
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #57 |
Created attachment 91064
0002 - fix media DSC comments
The problem was this line in the PS output:
%%BoundingBox: 0 0 -1 -1
I've update the DSC comments patch to fix it.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #58 |
Adrian, I have tested your fix and it works now.
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #59 |
When running the same thing (i.e. pdftops on a single page and then convert) I'm getting files of different sizes
tsdgeos@
new.png: PNG image data, 595 x 792, 16-bit/color RGB, non-interlaced
tsdgeos@
old.png: PNG image data, 596 x 792, 16-bit/color RGB, non-interlaced
Any idea why is that happening?
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #60 |
Created attachment 91104
0002 - fix media DSC comments
The bounding box should have been rounded up.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #61 |
I cannot reproduce the problem described in comment #39 but as the fix of comment #40 is more than a trivial change I have done a regression test to check whether all other problems described in this bug report stay solved and they do, so the current state of the patches is OK.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #62 |
(In reply to comment #41)
> I cannot reproduce the problem described in comment #39
You will only see the bug if the PDF contains a non integer page size.
eg 595.2 x 841.3. As the bounding box DSC comment can only use integers this needs to be rounded up to 596 x 842.
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #63 |
When running pdftops trhough (without any extra option) in https:/
Any idea why that is happening?
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #64 |
(In reply to comment #43)
> When running pdftops trhough (without any extra option) in
> https:/
> these patches.
>
> Any idea why that is happening?
Looking at the output of pdfinfo -box:
Page size: 551 x 747 pts
MediaBox: 0.00 0.00 612.00 792.00
CropBox: 38.00 5.00 589.00 752.00
BleedBox: 38.00 5.00 589.00 752.00
TrimBox: 38.00 5.00 589.00 752.00
ArtBox: 38.00 5.00 589.00 752.00
The mediabox is different from the crop box. As noted in comment 18, pdftops was using the media box as the page size but acroread uses the crop box for display size and printing paper size, glib and qt use the crop box for display size and pdfinfo as shown above uses the crop box as the page size.
I changed pdftops to use the crop box as the paper size (unless -nocrop is specified) to be consistent with acroread and fix the printing of the pdfs in this bug report.
Till Kamppeter (till-kamppeter) wrote : | #19 |
The Poppler fix is still under test to make sure that there are no regressions. See
https:/
As soon as it finalizes I will look into backporting it to 13.10.
Changed in poppler: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #65 |
ok, if adobe does the same maybe it makes sense. Are you making the qt-ps-converters do the same too?
In freedesktop.org Bugzilla #49946, Bugzilla-libreoffice-0 (bugzilla-libreoffice-0) wrote : | #100 |
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
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #66 |
(In reply to comment #45)
> Are you making the qt-ps-converters do the same too?
It should work. All the changes are internal to the PSOutputDev class. I tried qt4-demo but it doesn't seem to have a print function.
In freedesktop.org Bugzilla #49946, Rgloor (rgloor) wrote : | #101 |
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!
In freedesktop.org Bugzilla #49946, Rgloor (rgloor) wrote : | #102 |
BTW:
It works with both of my printers:
- Brother MFC-8460N
- Samsung CLP-365
No need of PDF-work-around anymore! :-)
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #103 |
--NOT FIXED-- (and i guess, no one has ever done something)
with LO Version: 4.1.3.2 Build ID: 70feb7d99726f06
and printer MFC-J6510DW it is still NOT working!
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #67 |
While running pdftops -f 30 -l 30 over
https:/
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #68 |
Created attachment 91266
0002 - fix media DSC comments
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #69 |
Created attachment 91314
0006 - pdftocairo fixes
Apply origpagesize and crop box changes to pdftocairo to ensure it works the same way as pdftops.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #70 |
Created attachment 91315
0007 cairo clip to crop box
Another crop box fix for cairo.
In freedesktop.org Bugzilla #49946, Foss-4 (foss-4) wrote : | #104 |
<email address hidden> then why not just update whiteboard with Confirmed:
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #71 |
Generally, the patches work well, but they have a problem. They break the ABI. I have backported them into the current Ubuntu package and now several other packages which use Poppler, like evince, do not work any more. Is it not possible to solve our problem without ABI change?
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #72 |
(In reply to comment #51)
> Is it not possible to solve our problem without ABI change?
Unfortunately not. But you don't need all the patches to fix the bug you reported. You can omit 0002 since DSC comments don't affect printing. 0004 can be omitted since that is a cleanup that doesn't affect functionality.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #73 |
Thank you very much, I have now reverted to my original patch plus a patch to fix duplex so that in the current Ubuntu package this bug is fixed. Your patches will go in as part of a later Poppler update (to a Poppler version which includes the patches).
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #105 |
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.
In freedesktop.org Bugzilla #72312, Till Kamppeter (till-kamppeter) wrote : | #74 |
Are the patches fixing pdftocairo the same way as pdftops so that the PS output of pdftocairo has everything fixed which was fixed in pdftops?
See the following bug report
https:/
The rporter tells that all is OK when using pdftops and he gets a wrong result with pdftocairo.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #75 |
(In reply to comment #54)
> Are the patches fixing pdftocairo the same way as pdftops so that the PS
> output of pdftocairo has everything fixed which was fixed in pdftops?
>
> See the following bug report
>
> https:/
>
> The rporter tells that all is OK when using pdftops and he gets a wrong
> result with pdftocairo.
He also filed bug 73452 a few minutes ago. I assumed CUPS should be setting the page size when IncludeFeature is used as described in:
http://
but this does not seem to work. Looks like I will need to use setpagedevice in the cairo PS output.
In freedesktop.org Bugzilla #72312, Alex Korobkin (korobkin) wrote : | #76 |
Yes, I tried to apply all the patches listed on this bug to poppler 0.24.5, with cairo being 1.12.16, and the issue was not resolved for me. Thanks for looking into this.
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #77 |
Albert,
Any update on the review/testing of these patches?
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #78 |
Not a biggie since it's a "broken" file, but when running pdftops on page 30 of https:/
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #79 |
Created attachment 92877
0008 ensure there is always a valid page size in the output
In freedesktop.org Bugzilla #72312, Albert Astals Cid (aacid) wrote : | #80 |
Ok, regtest finished, all looks good, please commit!
In freedesktop.org Bugzilla #72312, Adrian Johnson (ajohnson-redneon) wrote : | #81 |
Pushed.
Changed in poppler: | |
status: | Confirmed → Fix Released |
In freedesktop.org Bugzilla #49946, Dparsons-b (dparsons-b) wrote : | #106 |
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.
In freedesktop.org Bugzilla #49946, Foss-4 (foss-4) wrote : | #107 |
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.
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #108 |
NOT FIXED with Version: 4.2.0.4
Build ID: 05dceb5d363845f
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(
2013-09-20 11:54 - Linux x86_64
In freedesktop.org Bugzilla #49946, Foss-4 (foss-4) wrote : | #109 |
Comment 21 reported this fixed. and printer bugs are hard to verify, no one has all printer models. thanks for re-opening.
In freedesktop.org Bugzilla #49946, Jmadero-dev (jmadero-dev) wrote : | #110 |
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
Joshua O'Leary (jmoleary) wrote : | #82 |
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 : | #83 |
This bug was fixed in the package poppler - 0.24.3-0ubuntu2
Can you backport it to saucy? (currently on 0.24.1-0ubuntu1)
Przemek K. (azrael) wrote : | #84 |
Changed in cups: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Sebastien Bacher (seb128) wrote : | #111 |
> 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.
In freedesktop.org Bugzilla #49946, Barta-c (barta-c) wrote : | #112 |
--> <email address hidden>
please give an update of the bug status using latest LibO 4.3.2.2 release.
thanks for your feedback
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #113 |
**** not resolved !!! ***
hi
with
opensuse13.1
LO Version: 4.3.2.2 Build ID: edfb5295ba211bd
print via cups
2 pages per sheet
to brother MFC-J6510DW
Name : mfcj6510dwcupsw
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 : mfcj6510dwcupsw
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
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #114 |
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
In freedesktop.org Bugzilla #49946, Barta-c (barta-c) wrote : | #115 |
sorry to hear that...
Brother printers are affected by multiple issues on LibO.
see this bugzilla query: http://
In freedesktop.org Bugzilla #49946, christoph mueller (stof999) wrote : | #116 |
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
In freedesktop.org Bugzilla #49946, Barta-c (barta-c) wrote : | #117 |
I have no experience with Linux so I can't help.
@Joel Madero
any ideas about this?
In freedesktop.org Bugzilla #49946, Jmadero-dev (jmadero-dev) wrote : | #118 |
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 : | #119 |
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.
Problem description:
with LibreOffice 3.5.3.2 3802056- 4a8fed3- 2d66ea8- e241b80
Build-ID: 235ab8a-
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