This program demonstrates how to submit a "ready for print" file directly to the printing system. Two such types of files are an image file (such as a JPEG image) and a PostScript language file, such as those generated by applications which prefer to generate PostScript data when printing to PostScript printers.
This program allows the user to print a PostScript file or Image file that is included in its bundle (testps.ps or testImage.jpg) to the printer. When printing the image file it uses the mime type image/jpeg. When it prints the PostScript file it uses the mime type application/postscript, so the printing system will add the PPD feature code as well as other print dialog features such as n-up and handle collated or reverse order output.
By adjusting the values in the Page Setup and the values in the Printing dialog, you can affect the printing of these files.
More detail about submitting PostScript print jobs:
If you want to generate the PostScript data for your print job, you need submit a fully formed PostScript job using the PMPrinterPrintWithFile function. If indeed you want to generate the PostScript code for your drawing, you need to use the Job Submission API function PMPrinterPrintWithFile to submit PostScript jobs and you have two choices as to how you submit your job:
1) Submit fully formed PostScript jobs where your code supplies PPD features and all user features such as n-up, collation, etc. To submit this type of job, you submit your PostScript file as mime type application/vnd.cups-postscript.
2) Submit a complete DSC compliant page independent PostScript job but without PPD or other feature code embedded. The printing system will add the PPD feature code as well as other print dialog features such as n-up and handle collated or reverse order output. For this behavior, use the mime type type application/postscript. The printing system uses the page format, print settings you provide, in addition to the printer's assigned PPD file, to insert the appropriate PostScript data into the print stream. This is done automatically by the pstops filter that runs as part of printing.
Most developers don't want to do 1) but they instead want to generate the PostScript code for their drawing but without device specific and print dialog features such as n-up, copies, collation, PPD feature code, etc and let the printing system handle the rest.
To allow the pstops filter to handle your PostScript data properly, you need to generate DSC compliant, page independent PostScript files that contain the prolog data you require and page setup invocations that set up the coordinate system you need for your PostScript drawing. Many developers that have been using the pictwps printing path have over time had to do all kinds of hacks to deal with the PostScript wrapper generated by the printing system. By generating your own fully formed (minus device and user features) PostScript stream you won't have to deal with these kinds of hacks.