Bug 17952 - Possibly wrong page prolog for PostScript printers generated by libpoppler.
Summary: Possibly wrong page prolog for PostScript printers generated by libpoppler.
Status: RESOLVED MOVED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-07 11:51 UTC by JP Rosevear
Modified: 2018-08-21 10:55 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description JP Rosevear 2008-10-07 11:51:30 UTC
From https://bugzilla.novell.com/show_bug.cgi?id=412466, patch from reporter in that report.

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 fit, 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 GitLab Migration User 2018-08-21 10:55:20 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/432.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.