Our process flow invovles the following step:
Step 1 - Customer uploads PDF document (At max they will be uploading only 3 varieties of PDF documents) and these will be stored in our server
Step 2 - Each of these 3 types of PDFs needs to be mapped to a specific printer tray (because each printer tray will be loaded with different paper types)
We need a solution that would automate the paper tray assignment - no manual intervention should be there to select the paper tray
Please provide that solution !!
I think it may be optimistic to hope for a solution to this, but let us try.
The printing. Does it take place from
* the original user, who owns Acrobat and could install a plug-in?
* the original user, who just has the free Reader?
* some arbitrary web client?
* the server where the files are stored?
HI MVP -
- The original user generates PDF file using virtual printer and uploads the PDF in my .Net web application
- Once the file is uploaded in the web-application it gets stored in our server (here is were the solution is needed)
-The printing is handled by a third party vendor
The above is the currently planned scenario - but the main agenda is to make sure the PDFs are printed in their specific printer trays (if there are any feasible solution will change the plans accordingly)
Ok, this third party vendor. Are they printing from Acrobat? Are they using PostScript printing to a known printer? Can you install plugins for them?
Let us be clear that there is no paper tray instruction in a PDF, and no generic solution to this.
- I am not 100% sure on what application they use for printing
- Yes they do use postscript printing to a known printer (it is cannon 110pro)
- Yes we can install plugins for them
If they are using the Canon Imagerunner 110, they are using PostScript DSC commands (you can see them at the beginning of the file, the lines usually start with a '%'). These commands can trigger certain features of the printer (e.g. pull the paper for page 5 from the supply that contains blue letter sized 20# paper). Because, as was already explained, this is highly printer specific, you need to use software from the printer manufacturer (or their API specification - if available - to design your own solution).
Thanks Karl - I checked the PPD file. There are 5 - 6 media color options for selecting
*MediaColor Blue/Blue: "
dup /MediaColor (blue) put
setpagedevice settransfer setscreen "
so you are telling that we can use the above option to call blue paper tray(after setting manually in the printer) in the postscript file ?
Also are there any options to convert PDF to PS file in the server?
I poked around a bit and found the Interface Development Guide for this printer (it's actually a Kodak printer sold by Canon): Digimaster HD - Main | Graphic Communications - look at the end of the page for the download links for the IDG.
You can then create your custom headers that allow you to send the PDF file to the printer. You may have to experiment a bit to figure out exactly what needs to be in the header, but with access to the printer, that should not be a problem.
This is no longer a discussion that is suitable for the Acrobat SDK forum (this has nothing to do with Acrobat, or it's SDK), so if you want to discuss professional help with implementing this, please feel free to contact me privately - my contact information is on my profile page (I used to work on the development team for this printer).
Thanks a ton for the help Karl - I will keep you updated on the success story
Just to clarify – PDF does not have a “select paper tray” feature as that would not be Portable (remember the P in PDF).
Depending on the printing device in question, the use of Job Tickets (such as JDF) would be a common option.
I totally understand that PDF doesn't have the feature to select paper tray. We researched about JDF but the MIS - implementation seemed costly and not all printers supported JDF (especially the ones used by our vendor).
We are looking for solution that can be scaleable so that the process design / architecture won't get affected in future (if we have to use any other printers)
No, there is no standard solution. No architecture proofing. It is printer specific.
One solution is to use PostScript printers, and use a plug-in to inject extra PostScript tray selection code, chosen from the printer's PPD file. They MUST print from Acrobat though and this may not suit their workflow which may be MIS dependent. Direct PDF printing is now common at the high end and you cannot influence this with plug-ins. Note too that Acrobat is not for server use, not even as a print controller.
Actually, I'd expect the printer to ignore the DSC comments and use the code that follows them, but maybe not: some device managers (not RIPs) do use the DSC comments for preference. It's generally best to include both the DSC comment and the PPD-supplied PostScript code. This is an arcane art which is almost lost!
This device can actually print PDF directly, so the DSCs are used to set up the job and select the PDF interpreter. With PostScript, settings can be provided via DSCs or embedded in the PS code. If both are present, then there are some rules about which ones take precedence.
Oh, so it accepts DSC comments in PDF? I'd heard of that possibility, but I didn't realise any real world products did it. And this is part of the general problem: direct PDF printing is completely non standardised, and very difficult to get the spec of.