Incorrect handling of orientation when printing PDF files

Bug #1243484 reported by Stephane Peter
46
This bug affects 7 people
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/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.

Tags: raring saucy
Revision history for this message
In , christoph mueller (stof999) wrote :

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

Revision history for this message
In , christoph mueller (stof999) wrote :

Created attachment 61672
current and expected behavior

Revision history for this message
In , Dparsons-b (dparsons-b) wrote :

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.

Revision history for this message
In , Dparsons-b (dparsons-b) wrote :

Incidentally Bug #46341 sounds like the same bug.

Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :

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?

Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :

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

Revision history for this message
In , christoph mueller (stof999) wrote :

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

Revision history for this message
In , Rgloor (rgloor) wrote :

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.

Revision history for this message
In , Rgloor (rgloor) wrote :

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.)

Revision history for this message
In , Jmadero-dev (jmadero-dev) wrote :

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.

Revision history for this message
In , 100megabit (100megabit) wrote :

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.

Revision history for this message
In , Jmadero-dev (jmadero-dev) wrote :

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

Revision history for this message
In , 100megabit (100megabit) wrote :

4.1.1.2 The problem still exists. Solve, please.

Revision history for this message
In , Jmadero-dev (jmadero-dev) wrote :

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

Revision history for this message
In , 100megabit (100megabit) wrote :

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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Revision history for this message
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).

Revision history for this message
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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Tobias, can you have a look into this?

Revision history for this message
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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Revision history for this message
Stephane Peter (megastep) wrote :

Any progress for a resolution of this orientation bug?

Revision history for this message
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
Revision history for this message
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
Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :
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...

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Also reported to Debian as

http://bugs.debian.org/610014

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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?

Revision history for this message
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...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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?

Revision history for this message
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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :
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...

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

> 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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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).

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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).

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 90792
ensure page size takes into account rotation

The page rotation part of Till's patch.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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).

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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".

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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

Missing Qt4 change.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Created attachment 90836
pdftops-paper-segfault-fix.patch

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Created attachment 90837
pdftops-origpagesizes-papersize-setpagedevice-fix.patch

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Changed in cups-filters (Ubuntu):
status: Incomplete → Fix Committed
Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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_leaflet-pdftopdf.pdf.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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".

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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.

Revision history for this message
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
Revision history for this message
In , Albert Astals Cid (aacid) wrote :

Hmm, somehow these patches make the convert utility very unhappy. For example, take https://bugs.kde.org/attachment.cgi?id=9998 and run

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?

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

On a Ubuntu Trusty box I have ImageMagick 6.7.7.10-6ubuntu1 and here the "convert" fails:

till@till-twist:~/Documents$ convert file.ps file.png
Unrecoverable error: rangecheck in .putdeviceprops
Unrecoverable error: rangecheck in .putdeviceprops
convert.im6: Postscript delegate failed `file.ps': No such file or directory @ error/ps.c/ReadPSImage/832.
convert.im6: no images defined `file.png' @ error/convert.c/ConvertImageCommand/3044.
till@till-twist:~/Documents$

A direct Ghostscript call like

gs -sDEVICE=png16m -sOutputFile=file.png file.ps

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".

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

ImageMagick is using gslib. The command passed to gslib is;

(gdb) p command
$3 = "\"gs\" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 \"-sDEVICE=pngalpha\" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 \"-r72x72\" -g18446744073709551616x18446744073709551616 \"-sOutputFile=/tmp/magick-2413941yb1GUbrpBA%d\" \"-f/tmp/magick-24139E3UZ0BJSk5zw\" \"-f/tmp/magick-24139AG3GGDNM9Vys\"", '\000' <repeats 3759 times>

The output image size seems to be the problem:

  -g18446744073709551616x18446744073709551616

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Adrian, I have tested your fix and it works now.

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

When running the same thing (i.e. pdftops on a single page and then convert) I'm getting files of different sizes

tsdgeos@xps:~/okularfiles/pdf/scripts$ file new.png
new.png: PNG image data, 595 x 792, 16-bit/color RGB, non-interlaced
tsdgeos@xps:~/okularfiles/pdf/scripts$ file old.png
old.png: PNG image data, 596 x 792, 16-bit/color RGB, non-interlaced

Any idea why is that happening?

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 91104
0002 - fix media DSC comments

The bounding box should have been rounded up.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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.

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

When running pdftops trhough (without any extra option) in https://bugs.kde.org/attachment.cgi?id=10851 the page size is changed by these patches.

Any idea why that is happening?

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(In reply to comment #43)
> When running pdftops trhough (without any extra option) in
> https://bugs.kde.org/attachment.cgi?id=10851 the page size is changed by
> 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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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
Revision history for this message
In , Albert Astals Cid (aacid) wrote :

ok, if adobe does the same maybe it makes sense. Are you making the qt-ps-converters do the same too?

Revision history for this message
In , Bugzilla-libreoffice-0 (bugzilla-libreoffice-0) wrote :

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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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.

Revision history for this message
In , Rgloor (rgloor) wrote :

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!

Revision history for this message
In , Rgloor (rgloor) wrote :

BTW:
It works with both of my printers:

- Brother MFC-8460N
- Samsung CLP-365

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

Revision history for this message
In , christoph mueller (stof999) wrote :

--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!

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

While running pdftops -f 30 -l 30 over
https://bugs.freedesktop.org/attachment.cgi?id=9910 the patched version segfaults while the old one does not. Can you have a look?

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 91266
0002 - fix media DSC comments

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 91314
0006 - pdftocairo fixes

Apply origpagesize and crop box changes to pdftocairo to ensure it works the same way as pdftops.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 91315
0007 cairo clip to crop box

Another crop box fix for cairo.

Revision history for this message
In , Foss-4 (foss-4) wrote :

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

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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?

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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).

Revision history for this message
In , christoph mueller (stof999) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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://bugs.linuxfoundation.org/show_bug.cgi?id=1176

The rporter tells that all is OK when using pdftops and he gets a wrong result with pdftocairo.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

(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://bugs.linuxfoundation.org/show_bug.cgi?id=1176
>
> 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://lists.cairographics.org/archives/cairo/2006-February/006278.html

but this does not seem to work. Looks like I will need to use setpagedevice in the cairo PS output.

Revision history for this message
In , Alex Korobkin (korobkin) wrote :

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.

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Albert,
Any update on the review/testing of these patches?

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

Not a biggie since it's a "broken" file, but when running pdftops on page 30 of https://bugs.freedesktop.org/attachment.cgi?id=9910 the unpatched version creates something that gs can read (even if ends up beign empty) while the patched version creates something that makes gs unhappy. Can you have a quick look to see how hard would it be to get doesn't make gs hate the output ps file?

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Created attachment 92877
0008 ensure there is always a valid page size in the output

Revision history for this message
In , Albert Astals Cid (aacid) wrote :

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

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

Pushed.

Changed in poppler:
status: Confirmed → Fix Released
Revision history for this message
In , Dparsons-b (dparsons-b) wrote :

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.

Revision history for this message
In , Foss-4 (foss-4) wrote :

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.

Revision history for this message
In , christoph mueller (stof999) wrote :

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

Revision history for this message
In , Foss-4 (foss-4) wrote :

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

Revision history for this message
In , Jmadero-dev (jmadero-dev) wrote :

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

Revision history for this message
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

Revision history for this message
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)

Revision history for this message
Przemek K. (azrael) wrote :
Changed in cups:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
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.

Revision history for this message
In , Barta-c (barta-c) wrote :

--> <email address hidden>

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

Revision history for this message
In , christoph mueller (stof999) wrote :

**** 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

Revision history for this message
In , christoph mueller (stof999) wrote :

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

Revision history for this message
In , Barta-c (barta-c) wrote :

sorry to hear that...

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

Revision history for this message
In , christoph mueller (stof999) wrote :

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

Revision history for this message
In , Barta-c (barta-c) wrote :

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

@Joel Madero
any ideas about this?

Revision history for this message
In , Jmadero-dev (jmadero-dev) wrote :

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)

Revision history for this message
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.

To post a comment you must log in.
This report contains Public information  
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.