I have a PDF which is 17x11 landscape. I need to convert it to PCL, 11x17 portrait. If I convert with gs -sDEVICE=ljet4 -sPAPERSIZE=ledger, the resulting file is for A1 paper. If I convert with -sPAPERSIZE=11x17, the resulting file is printed cropped; the plans are not rotated to fit into 11x17. I notice that the PXL driver does the right thing. See gdevpxut.c around line 157. It would be useful to port this to the PCL drivers. The work around is to use pdf2ps, then -c '<< /Orientation 1 >> setpagedevice' to get the correct orientation.
Unfortunately, I can not share the example PDF I have.
(In reply to comment #1) > Unfortunately, I can not share the example PDF I have. Okay should be easy enough to create a test example. The problem should be reproducible with -sDEVICE=ljet4. This is an easy bounty problem and the output can be tested with ghostpcl.
After an initial look at this problem, the ljet4 device (and surely some other ones) does not support the landscape orientation. When searching for the paper size in gdev_pcl_paper_size(), it returns PAPER_SIZE_A1 because it is the more appropriate portait size for 17x11. I have started to work on a patch which detect the orientation, select the correct paper size and output the PCL orientation control (<ESC>&l#O). However, I'm not sure if the pcl6 command can support page orientation. When converting the resulting PCL (ledger+landscape) into a PDF file, I end up with a portrait orientation.
Created attachment 9368 [details] Initial patch for testing Philip, can you test with this patch and tell me if the result is ok?
So far the patch looks good. Waiting for confirmation of printer output. I do not have physical access to the 11x17 printer.
Results form the printer: orientation and size is correct. But the output is offset by 1/4 inch up and to the right.
I guess experimenting with align.ps (google fixing your margins in ghostscript) at different sizes and orientations would tell us something about what is going on here. But I am not sure if this device shouldn't be simply deprecated as the this class of printer should be supported with some combination of HPIJS and/or CUPS. What is the exact printer model you are targeting Philip?
FYI regarding deprecating ljet4 in Ghostscript and support via HPIJS and/or CUPS. HPLIP provides two drivers: HPIJS and HPCUPS. HPIJS is unmaintained/unsupported by HPLIP, see https://answers.launchpad.net/hplip/+question/170304 ------------------------------------------------------ goutam kodu (goutam-hplip) said on 2011-09-07: ... HPIJS driver is not maintained for new HP devices. As now all the distros are using CUPS there is only hpcups support. ------------------------------------------------------ https://answers.launchpad.net/hplip/+question/170025 ------------------------------------------------------ Srikanth (srikanth-lokare) said on 2011-09-06: ... Currently HPLIP stopped supporting HPIJS. We support only printing from HPCUPS. ------------------------------------------------------ I think compared to using ljet4 directly in Ghostscript it is more complicated to use HPCUPS to make generic PCL5e because a more complicated stack of software is involved. I think for plain printing by usual end-users of usual Linux distributions it does not matter but for experienced users and/or minimal systems it makes a difference. I think Ghostscript should provide generic PCL output devices. I added Till to Cc because I assume he is also interested regarding deprecating ljet4 in Ghostscript.
Please keep maintaining ljet4, ljet4d, cljet5c, ... in Ghostscript and fix this bug in all of them. They are still useful: 1. Linux is more and more used for mobile devices. Here it is important to save space and so eliminating the need of shipping hpcups is an important step. Please consider also to port the PCL 5c/e and PCL 6/XL output devices to MuPDF. 2. HPIJS is deprecated in HPLIP and therefore can easily disappear, so the few users of non-CUPS spoolers (option in Debian, *BSD operating systems, ...) need a way to use PCL printers without needing libcups and/or libcupsimage.
(In reply to comment #9) > Please keep maintaining ljet4, ljet4d, cljet5c, ... in Ghostscript and fix > this bug in all of them. They are still useful: > > 1. Linux is more and more used for mobile devices. Here it is important to > save space and so eliminating the need of shipping hpcups is an important > step. Please consider also to port the PCL 5c/e and PCL 6/XL output devices > to MuPDF. > > 2. HPIJS is deprecated in HPLIP and therefore can easily disappear, so the > few users of non-CUPS spoolers (option in Debian, *BSD operating systems, > ...) need a way to use PCL printers without needing libcups and/or > libcupsimage. Okay the problem remains bountiable (Artifex will pay for a fix), "Math" and Philip can iterate back and forth until the margins are correct. I see in the ljet4 driver code the margins are being set with registration commands which offset the PCL logical page from the physical (see the PCL technical reference manual). This is a bit different than the usual arrangement of setting ghostscript HWMargins with -c on the command line or with cups in the PPD, that should work fine but hardwiring the numbers in the code is much less flexible. As for cljet5c, I can't imagine it should ever be used, a contone raster is too large for the default configuration and PXL is available on the printer so the vector device pxlcolor should be used. I can confirm cljet5c does not work on my Color Laserjet 4600 at the default printer resolution, 600dpi.
(In reply to comment #10) > I see in the ljet4 driver code the margins are being set with registration > commands which offset the PCL logical page from the physical (see the PCL > technical reference manual). Henry, I assume you are talking about Left and Top Offset defined in the init command (<ESC>&l-180u36Z). The PCL documentation states that this has the same effect regardless of orientation but this does not seems to be the case... Do you know how these values have been defined in the first place?
(In reply to comment #7) > What is the exact printer model you are targeting Philip? Tests are being done on a Ricoh Aficio 2075sp. But this printer will be changed.
(In reply to comment #11) > (In reply to comment #10) > > I see in the ljet4 driver code the margins are being set with registration > > commands which offset the PCL logical page from the physical (see the PCL > > technical reference manual). > > Henry, I assume you are talking about Left and Top Offset defined in the > init command (<ESC>&l-180u36Z). The PCL documentation states that this has > the > same effect regardless of orientation but this does not seems to be the > case... > Do you know how these values have been defined in the first place? The author derived the values empirically from a laserjet 6mp using portrait paper. If we want to make this device as generic as possible I recommend removing that and using HWMargins instead. Here is one discussion about doing this: http://www.bobdbob.com/~deneb/doc/ghostscript_margins.html We (ghostscript.com) should have some better documentation about align.ps, anyway each papersize can be tested with the align.ps postscript program as above which will give us HWMargin parameters, then we need to figure out how to feed that information to the printer given the specific printer specified (many will differ). In cups this is done with ppd's, it can be done with a postscript file as in the link about, using the -c option on the command line, or a new device structure can be specified in the code with the HWMargins. In the interest of getting you paid for the code you've done if we had a command line working with the patched code: -c '<< /.HWMargins [ml mb mr mt] /Margins [x y] >> setpagedevice' with correct values for ml, mb etc. filled in we'd call it a fix and integrate the code.
(In reply to comment #13) > [...] If we want to make this device as generic as possible I recommend > removing that and using HWMargins instead. [...] Removing these hard-coded offset values will change current behavior and impact users relying on that behavior. In addition, I don't think it will be possible to use a negative HWMargin value like the negative Left Offset currently is use (-180). Isn't it possible to keep these initialization offsets (one for portrait, one for landscape) and let the user adjust the alignment using HWMargins if required?
Created attachment 9577 [details] Updated patch Philip, can you test your document using this updated patch and tell us how the result is? Can you also print the align.pcl file generated using the patched gs binary and the following command: gs -sDEVICE=ljet4 -sPAPERSIZE=ledger -sOutputFile=align.pcl -dNOPAUSE -dBATCH -f gs/lib/align.ps With the printed align.pcl document, measure the dimensions detailed in the document and send me the results. Thanks for your help.
(In reply to comment #14) > (In reply to comment #13) > > [...] If we want to make this device as generic as possible I recommend > > removing that and using HWMargins instead. [...] > > Removing these hard-coded offset values will change current behavior and > impact users relying on that behavior. In addition, I don't think it will > be possible to use a negative HWMargin value like the negative Left Offset > currently is use (-180). > > Isn't it possible to keep these initialization offsets (one for portrait, > one for landscape) and let the user adjust the alignment using HWMargins > if required? Yes that does sound more reasonable. Thank you.
Philip, Do you still have access to the printer to launch the two tests described in comment 15? Thanks for your valuable time to help us define the margins for landscape mode.
Hi, I had a similar situation and I wanted to confirm that this patch (http://bugs.ghostscript.com/attachment.cgi?id=9577&action=diff) works well for me. Here is my setup: Ghostscript-GPL 9.06 (Yes, I back-ported the patch to 9.06) I have a script that generates an HTML form using a template and database data. The HTML form is formatted to fit with a US Letter in Landscape mode. I convert the generarted HTML data to a PDF using wxhtmltopdf (and the wxhtmltopdf patched QT sources). The wxhtmltopdf command is: wxhtmltopdf -q -O landscape -s Letter file.html file.pdf I then convert the PDF to PCL, using Ghostscript 9.06 (with the before mentioned patch), in order to concatenate with other PCL files and send to the printer in one lump sum. The ghostscript command is: gs -sDEVICE=ljet4 -DNOPAUSE -DBATCH -q -sOutputFile=file.pcl file.pdf Thanks, Dyweni
Henry, Is there anything I can do to make this bug fix progress? The original poster (Philip) is unresponsive but an other user (comment 18) has confirmed that the patch is working as expected. Thanks for any indication.
Fix committed to the GIT repository, rev. 5d6b18a. Thank you very much for the patch.