Re:
On Mar 6, 2006, at 6:58 AM, Yvo Van Wezemael wrote:
Current 10.4 headers show that all PMSessionPostScriptXXX calls are
deprecated and that one should use PMPrinterPrintWithFile or
PMPrinterPrintWithProvider instead.
That is correct. Also note that 'pictwps' printing path is not
available on Intel-based Macintosh computers except under Rosetta. If
you want to generate the PostScript data your print job you will have
to do so yourself rather than what you've done previously. Note that
if you only need to support EPS data you can use Quartz drawing
together with PMCGImageCreateWithEPSDataProvider to allow the
inclusion of EPS data as part of your Quartz drawing. This may not
apply to you but I mention it because some developers are only using
'pictwps' for EPS support and that isn't necessary.
To be honest, I don't really understand how the latter serves as a
replacement for the 'old' calls. They require passing of printer/
settings and format, which does not really match our usage of the
session related calls which we use to emit postscript data on a per
page basis (i.e. we let the driver due all of its settings/page
setup stuff and just emit the postscript code for page rendering).
By using the Job Submission API function PMPrinterPrintWithFile (or
PMPrinterPrintWithProvider when available) to submit PostScript jobs,
you have two choices as to how you submit your job:
1) submit fully formed PostScript jobs where your code supplied PPD
features and all user features such as n-up, collation, etc. To submit
this type of job you would submit your PostScript file as mime type
application/vnd.cups-postscript.
2) submit a complete DSC compliant page independent PostScript jobs
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 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
their PostScript data 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.
Of course you have 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 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.
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Printing mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/printing/email@hidden
