To fulfill a customer requirement, we created a custom ppd file to enable them to print the 1st page from a different tray than the following trays. The file contains the relevant tray information for each page: %%BeginFeature: *InputSlot Default ... %%Page: 1 1 ... %%Page: 2 2 ... %%BeginFeature: *InputSlot Upper The resulting ps document has the input tray information embedded in it and works as expected with PostScript printers viz. the 1st page prints from the default tray3 and the rest from tray2. However when we use ghostscript to convert this PS doc to PCL for sending to PCL printers, the input tray info is lost. The following command line option is used. C:\temp>C:/hp-dazel/os/bin/gs -sDEVICE=pcl5 -IC:/hp- dazel/os/lib/FONTS/Soft_Horizons -IC:/hp-dazel/os/lib/PS -q -dBATCH -dNOPAUSE - dSAFER -dSHORTERRORS -dWRITESYSTEMDICT -dGHOSTSCRIPT - sOutputFile=c:/temp/cust.pcl cust.ps
Please attach a PostScript file using that custom ppd so that we can investigate this further.
I'm confused by your tray naming conventions. Looking at the "Paper Source Command" spec in the PCL manual, I don't see anything that corresponds to "tray2" and "tray3". Also, "pcl5" is not one of our standard devices. Is this a custom driver that you have written? If so, what standard driver is it based on (so that the patch has a good chance of merging cleanly)? We'd need to implement this by writing a put_params method. Most likely, this would be a string pass-through, so you can access any PCL commands.
Created attachment 1164 [details] The PS doc generated by the custom PPD The first page is taken from the upper tray and the rest from the default tray. %%BeginFeature: *InputSlot Default <</ManualFeed false /MediaPosition 1>> setpagedevice %%EndFeature %%BeginFeature: *InputSlot Upper <</ManualFeed false /MediaPosition 0>> setpagedevice %%EndFeature This info is not retained when converted to PCL
Created attachment 1165 [details] cust.pcl converted by gs from cust.ps This file is generated from cust.ps by giving command C:\temp>C:/hp-dazel/os/bin/gs -sDEVICE=pcl5 -IC:/hp- dazel/os/lib/FONTS/Soft_Horizons -IC:/hp-dazel/os/lib/PS -q -dBATCH -dNOPAUSE - dSAFER -dSHORTERRORS -dWRITESYSTEMDICT -dGHOSTSCRIPT - sOutputFile=c:/temp/cust.pcl cust.ps There is no tray selection info in this file.
Proposed fix posted here: http://ghostscript.com/pipermail/gs-code-review/2005-March/004764.html
Fix committed: http://ghostscript.com/pipermail/gs-cvs/2005-April/005390.html http://ghostscript.com/pipermail/gs-cvs/2005-April/005391.html
Tested the fix with our current setup. Still have the same problem, i.e. tray selection doesn't work for the customer ps document (attached: attachment.ps). What we have noticed is that the ps document doesn't have a InputAttributes dictionary. The tray selection works fine when sent to ps printer. If we add the following details to the ps document manually it works fine: << /PageSize [595 842] /InputAttributes << 1 <</PageSize [595 842] >> >> >> setpagedevice << /PageSize [595 842] /InputAttributes << 0 <</PageSize [595 842] >> >> >> setpagedevice But the problem is that customer ps file is generated by a custom ppd.
Yes, and InputAttributes dictionary must be sent with the print job. This dictionary contains the information from the PPD and perhaps site specific information such as 50lb bond A4 is in tray 4.
From: Nagaraj Rao, Guruprasad Kadhur (HP-OM) Sent: Tuesday, August 01, 2006 4:42 PM To: stefan.kemper@artifex.com Cc: Jose T, Viju; Rajesh, Therakkal; Nagaraj Rao, Guruprasad Kadhur (HP-OM) Subject: Reg. Bug #687899 -- Follow-up Hi Stefan, This is regarding the fix for reported bug #687899. Please find below the recent communications that we had on this issue. Kindly could you let me know whether are they any further update on the reported issue. It would be great if you could reply at the earliest. Regards, Guruprasad ------------------------------------------------------------------------ Hi Stefan, We don't want to define InputAttributes dictionary for each printer as one can always change the printer settings to map a media to different tray. InputAttributes overrides printer settings hence is not an acceptable solution. The doubt we have is if the postscript document prints correctly and selects appropriate tray why can't a PCL document do the same when converted using ghostscript to PCL. Can you change ghostscript code such that if the InputAttribute dictionary is not present then whatever media position is specified within the document is emitted as the physical tray to be printed? Regards Rakesh -----Original Message----- From: Stefan Kemper [mailto:stefan.kemper@artifex.com] Sent: Tuesday, June 28, 2005 3:58 AM To: Kookkal, Gopikrishnan Cc: support@artifex.com; raph.levien@artifex.com; 'Ray Johnston'; Sawan, Rakesh K; Gopinathan, Ashok Subject: Re: Reg. fix for bug #687899 Hi Gopikrishnan, I really don't know how to solve this. Given a random postscript job and a random pcl printer to print to: I don't know how to match a MediaPosition to a meaningful tray number without knowing something about the pcl printer, in particular how many trays it has, how they are numbered and what is loaded in each tray. This is exactly what and InputAttributes dictionary in postscript is for. Different pcl printers use tray numbers to mean different things. For that matter which MediaPosition maps to which physical tray isn't specified in postscript either. So while we could pass the mediaposition to the output, how do we make this a meaning full result for the customer. Best regards, Stefan Kemper
closing, we don't have a solution.