Bug 47144 - Poppler's pdftops filter does not respect the margin values of some of the Envelope PageSize's on landscape,reverse landscape printing
Summary: Poppler's pdftops filter does not respect the margin values of some of the En...
Status: RESOLVED INVALID
Alias: None
Product: poppler
Classification: Unclassified
Component: utils (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium critical
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-09 03:33 UTC by Goutam Korra Kodu
Modified: 2012-03-12 01:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Attaching the Officejet_XXXX.ppd PPD file, geditoutput.pdf, pdftopsoutput.ps , Expectedoutputformpdftops.ps, neww.txt files.ps. (41.90 KB, application/x-gzip)
2012-03-09 03:33 UTC, Goutam Korra Kodu 		Details
View All

Description Goutam Korra Kodu 2012-03-09 03:33:12 UTC 
Created attachment 58229 [details]
Attaching the Officejet_XXXX.ppd PPD file, geditoutput.pdf, pdftopsoutput.ps , Expectedoutputformpdftops.ps, neww.txt files.ps.

Printing the text document on Envelope paper size as landscape/reverse-landscape from gedit application in OpenSUSE 12.1 & Fedora 16 gives the clipped output on the Printer.

Gedit app generates the pdf and then it is passed through cupsfilter chain pdftops and pstoraster filters to generate the raster data.

The output generated by the pdftops does not contain the Hardware(HW)margin values contained in the PPD file for landscape orientation and hence its giving the clipped output.

This bug is not seen in Ubuntu 11.10 as they have a separate cpdftocps filter script at /usr/lib/cups/filter location  which takes care of adding the HWmargin values from PPD file into the pdftops output.

OpenSUSE 12.1 and Fedora 16 does not contain the cpdftocps filter script and there is no way for adding the HWmargin units from PPD file for envelope paper size to the pdftops output.

Pdftops filter need to take care of the HWmargin values provided in the PPD file and embed it into the ps output generated by the pdftops filter.

How to reproduce the bug ?

1. Create a print queue by some name XYZ and selecting the ppd (which is attached) Officejet-XXXX.ppd.

2.Pause the print queue.

3.Generate the pdf document from the gedit application. This you can do by opening the text file in gedit and select the printer in the print dialog box showing as paused and in the Page Setup tab set the page size as "DL Envelope" and orientation as "landscape" and then check the print button. Go to the location /var/spool/cups and you will find the file name starting with d00XXX. Copy that file to the desktop with some name as abcd.pdf.

4. Run the cupsfilter command:
   cupsfilter -m application/vnd.cups-postscript -p /etc/cups/ppd/Officejet-XXXX.ppd -o "PageSize=EnvDL landscape fitplot MediaType=Plain OutputMode=Normal ColorModel=RGB" ~/Desktop/abcd.pdf > ~/Desktop/abcd.ps

Open the file abcd.ps with vim editor and you see there are no HWmargin values povided in the PPD file is embeded in the landscape oriented ps output of the pdftops filter.

Where as this doesn't affect the Portrait orientation.

Printing the raster file generated form the pstoraster filter produces the clipped out at the printer  as the Hardware margin values are not respected in the raster data.

Please embed the HW margin values provided for the Envelope paper sizes in the PPD file  into  pdftops filter output as per the orientation specified (Landscape/Reverse landscape).
Comment 1 Albert Astals Cid 2012-03-09 03:39:36 UTC 
****
The output generated by the pdftops does not contain the Hardware(HW)margin
values contained in the PPD file for landscape orientation and hence its giving
the clipped output.
****

That is not a bug, pdftops knows nothing about PPD files. This is either a cups bug or a bug of whoever generated the PDF.
Comment 2 Adrian Johnson 2012-03-09 04:52:59 UTC 
This is a gedit bug. Gtk has a function for getting the hard margins. Evince is using the hard margins when "shrink to printable area" or "fit to printable area" is selected. Gedit should be adjusting the page layout to fit within the printable area. I did a grep on the gedit sources but found no calls to gtk_print_context_get_hard_margins(). Scaling the PDF after it has been generated is a less desirable solution as the user may not want everything on the page to be rescaled.
Comment 3 Goutam Korra Kodu 2012-03-12 01:37:51 UTC 
(In reply to comment #2)
> This is a gedit bug. Gtk has a function for getting the hard margins. Evince is
> using the hard margins when "shrink to printable area" or "fit to printable
> area" is selected. Gedit should be adjusting the page layout to fit within the
> printable area. I did a grep on the gedit sources but found no calls to
> gtk_print_context_get_hard_margins(). Scaling the PDF after it has been
> generated is a less desirable solution as the user may not want everything on
> the page to be rescaled.

Thanks Adrian,

Will Post this bug to the gedit team.

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.