Customizing PSNormalizer Framework in MacOS X 10.3?

[Thomas Kaiser]

Hi all,

anyone out there who managed to use individual setdistillerparams in
PostScript jobs within Apple's PSNormalizer framework in MacOS X 10.3?

If I alter the contents of startupNORM.ps [1] I'm able to affect the
creation of all PDFs from the on via /usr/bin/pstopdf, the CUPS'
pstopdffilter or Preview.app.

But even if I add "/LockDistillerParams false", I'm not able to let the
integrated distiller core honour setdistillerparams calls inside ps files.

Same with "pdfmark". Seems like the operator has been redefined?

Anyone any clues?

TIA,

Thomas

[1] in /System/Library/PrivateFrameworks/PSNormalizer.framework/Resources/

[mattrix]

For the printing system itself, PSNormalizer only comes into play when a
PostScript file is presented to the printing system and the destination
device is not a PS printer. This can happen with drag and drop printing of
a PS file to a desktop printer, lpr printing from a remote host (including
Mac OS 9 and Windows) to a raster print queue hosted on Mac OS X, and from
applications that use the job submission API on Mac OS X to submit
PostScript files to the printing system.

In that case the printing path for non-PS printers looks like:

PS -> PDF -> raster -> printer -> backend

where the PS->PDF conversion is done using the PSNormalizer code.

PSNormalizer also is the basis for the /usr/bin/pstopdf tool and is used
when applications (such as Preview) use the public API in Quartz to
convert PostScript files into PDF documents. (Preview does this when you
open a PS file.) This API is described in the Quartz header file
CGPSConverter.h in the CoreGraphics.framework inside of
ApplicationServices.framework. This is another way that PostScript can be
inserted into the printing system, i.e. implicitly by an application that
converts PostScript or EPS files into PDF as part of its normal
operation.