Bug 412466 - Possibly wrong page prolog for PostScript printers generated by libpoppler.
Summary: Possibly wrong page prolog for PostScript printers generated by libpoppler.
Status: RESOLVED UPSTREAM
Alias: None
Product: openSUSE 11.0
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Final
Hardware: x86-64 openSUSE 11.0
: P2 - High : Major (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL: https://bugs.freedesktop.org/show_bug...
Whiteboard: gnome-wrong-out-of-the-box
Keywords: should_go_upstream
Depends on:
Blocks:
 
Reported: 2008-07-26 14:26 UTC by Andreas Pfaller
Modified: 2010-11-27 11:46 UTC (History)
4 users (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Trival patch for problem (508 bytes, patch)
2008-07-26 14:26 UTC, Andreas Pfaller
Details | Diff
Enhanced patch for PS prolog (748 bytes, patch)
2008-11-09 03:18 UTC, Stefan Brüns
Details | Diff
get info from printer (879 bytes, application/postscript)
2008-11-17 02:08 UTC, Stefan Brüns
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Pfaller 2008-07-26 14:26:43 UTC
Created attachment 230173 [details]
Trival patch for problem

Duplex printing on my Brother Laser printer using PostScript output
has has always been problematic with every SUSE version I have used
with this printer. The printer is PostScript capable (BR-Script3).
This printer series has an unusual "feature". In
order to print in duplex a lever at the back has to be in a
specific position to match the used paper size (I only use A4).
However the printjobs generated by many programs (e.g. all KDE jobs)
cause the printer to request (via its status display) the movement 
of this lever to the "Letter" paper size position although I have
specified "A4" in the page setup dialogs. While the document prints
after moving the lever the output is unusable because it is
not correctly positioned on the paper (in fact some area is even
missing).

With wireshark I found that the problematic jobs all contain the
following PostScript code:

/pdfSetup {
  3 1 roll 2 array astore
  /setpagedevice where {
    pop 3 dict begin
      /PageSize exch def
      /ImagingBBox null def
      /Policies 1 dict dup begin /PageSize 3 def end def
      { /Duplex true def } if
    currentdict end setpagedevice
  } {
    pop pop
  } ifelse
} def

I initially had problems locating the software which is responsible
for inserting this code but a binary grep of the /usr partition
finally found it in libpoppler. Changing the code above to
use "/PageSize 1" (instead of "/PageSize 3") fixes my problem.

Adobes "PostScript Language Reference (3rd ed.)" describes the
"/PageSize n" command as follows:

n=3 Select the nearest available medium and adjust the page to ?t, as de-
    scribed below under “Recovery Policies and Media Selection.”

n=1 Do not consider the PageSize parameter in media selection. Subse-
    quent calls to currentpagedevice will return a dictionary whose
    PageSize entry describes the medium that was actually selected.

For me the description does not really help to see if the code as 
used by libpoppler is actually correct. With n=3 the printer may select a
different paper size then I selected in the print setup 
which is contrary to what I would expect since I explicitly requested a
page size in the print setup. On the other hand Brothers selection is
also quite clearly wrong (since it selects a paper size which it
in principle could handle but which is not available and then prints
incorrectly on the "A4" paper).

I don't have a wide selection of PostScript Printers available to
test if the change to "/PageSize 1" causes any problems on other
printers so I don't know if this is an appropriate fix.
Comment 1 Klaus Singvogel 2008-07-28 07:55:45 UTC
I didn't check this bug.
But it's poppler related, which is maintained by gnome-maintainers. -> reassign

Changed Component accordingly.
Comment 2 Andreas Pfaller 2008-07-28 12:43:59 UTC
As additional info:

If i save my document to a PostScript file (e.g. via kate's "Print" dialog)
and then print the PostScript file from the command line with

  lpr -P br-ps -o Duplex=DuplexNoTumble test.ps

duplexing works as expected even with an unpatched libpoppler (as it is
obviously not used in this case).
Comment 3 JP Rosevear 2008-10-07 18:53:07 UTC
Filed upstream to get a patch review.

https://bugs.freedesktop.org/show_bug.cgi?id=17952
Comment 4 Stefan Brüns 2008-11-09 03:18:32 UTC
Created attachment 250888 [details]
Enhanced patch for PS prolog

This Patch sets the PageSize policy dependend on DeferredMediaSelection
Comment 5 Stefan Brüns 2008-11-09 03:23:36 UTC
As kpdf has copied the poppler/xpdf code, kpdf is affected as well
Comment 6 Andreas Pfaller 2008-11-09 07:04:27 UTC
I have just tried the patch from comment #4 but unfortunately my
printer (Brother MFC-8820DN) still behaves like I described in
comment #1.
Comment 7 Stefan Brüns 2008-11-17 02:08:35 UTC
Created attachment 252521 [details]
get info from printer

This PS sequence requests the current state of media selection, a list of available media, then tries to set A4 paper and duplex, and requests the current media again
Comment 8 Stefan Brüns 2008-11-17 02:12:51 UTC
@Andreas: can you send this file to your printer (assuming it is a network printer, listening on port 9100 (known as AppSocket/Jetdirect) and known under the DNS name "yourprinter")
netcat yourprinter 9100 < printerstate.ps
Comment 9 Andreas Pfaller 2008-11-17 08:28:45 UTC
Sending the PS code from comment #7 with netcat causes blinking
of the printers "Status LED" for about 4 seconds but nothing else
happens.
Comment 10 Vincent Untz 2010-11-27 11:46:39 UTC
Closing as UPSTREAM since the bug has been filed upstream, and I doubt we can do anything better downstream.