Help needed with PDF/X -3 settings in ColorSync Utility

Question

Hi, I'm attempting to create a PDF/X-3 document from iWork Pages with full bleed.
Can someone explain the four fields for Trimbox and Bleedbox? For instance, what units are they in? Does the fact that my unit preferences in Pages is centimetres affect them? And what does each field relate to on the document?
So far I've found out I need to add 3mm to our A4 page, but I haven't spoken to the proper IT person at our printer yet.
Oh yeah, and when I open up the PDF/X-3 document in Preview should I be able to see the Bleedbox or bleed lines? Or are these just invisible settings for the printer's computer to use?

Answer 1

I take it that's a no then?
Sorry, a bit busy this end.
To be precise, the implemention does not do what the interface for the implementation implies. What the implementation does is what ColorSync itself does, and does correctly. Tagged objects are honoured, that is, the source ICC profiles are preserved. Untagged objects are tagged, that is, the Generic RGB Profile is assigned to objects in data space RGB, the Generic CMYK Profile is assigned to objects in data space CMYK, and the Generic Gray Profile is assigned to objects in data space Gray. And the reference / simulation / OutputIntent of your choice is embedded, whether it be type PRTR Printer or type MNTR Monitor since as per the technical specification both are permitted.
You cannot change the fallback transform. There is a specific reason for this which was stated by John Zimmerer as Color and Imaging Product Manager following the discussion of the Generic CMYK Profile. John pointed out that the operating system has to have a fallback, but that if the fallback can be customised then it can corrupt the operating system. Technically, this is correct. Suppose I tell you to install an ICC transform with which I intend to invert or zero the colour contrasts and colour cues in your system interface.
You can't change the Generic XXX Profile. These are autoinstalled by the system, and if you try to delete them, the system installs them again ... and again ... and again. This was not the behaviour in the early ColorSync releases. If you go far enough back, you will find that the system did not necessarily have a fallback for CIELa*b D50 2 degree standard observer, now Generic LAB Profile. In other words, the system has to have a source fallback for each data space, including CIALab and CIEXYZ.
Note in passing that the problem of a fallback transform also applies to incoming character data. My porous memory has let slip whether the cut is 10.4 or 10.5, but the principle is that you cannot change the system fallback for character-glyph mapping. The prepress people were in an uproar as they wanted their beloved Adobe Type 1 font program dictionaries as system fallbacks for imaging of incoming character data, but again Adobe Type 1 font program dictionaries are malign more often than not and malign character-glyph transforms could chaotify the system interface strings.
As far as I can make out, the implementation of the PDF/X-3 functionality sets MediaBox = CropBox = BleedBox = TrimBox. This has been the case since PDF/X-3 functionality was introduced into the operating system. Is this right or wrong? Well, it's wrong to have an interface if the interface does not do what it says to do. But beyond that, and from my point of view, if people want to set these parameters, then they need to talk to the person who operates the imposition system, or better still the person who operates the press and the person who operates the imposition system need to have a file format that lets them communicate with the person designing the page. So the way to do this is to support as well the ICC file format for prepress colour-colourant conversion and a postpress processing format for cutting, folding and so forth. I've not followed automation for postpress processing closely, but my sense of it is that there are not as many printers who would know what to do with postpress parameters as there now are who have some sense of what to do with a colour managed printing master.
There are prepress people who are looking for more and more device dependence in printing masters. Peter Breis wants support for spot colour, but he does not consider the consequences. Peter Kleinheider and Bernz Zipper had an article in CreativePro that said the problem with OS X was that there was no support for overprint, OPI links, or transfer curves in PostScript programming. For the record, Peter and Bernd are wrong. Transfer curves don't belong in PDF printing masters, because they change the calibration of the RIP relative to the calibration characterised in the ICC profile for the printing condition, which is harakiri. And OPI brings in EPS DCS that cannot be properly colour managed in proofing, for instance.
One can argue back and forth about type, should the system make the supposition that type is to be imaged on one and only one class of device: a separations device that has a separate colourant unit half a meter apart for each process plane? In this case, type should be set to image on the K plane only. As it is, type is set to image on the four process planes, so 10 point Garamond prints in four inking units on an offset lithographic printing press instead of on one inking unit. Paradoxically, when GX was reviewed by Jonathan Seybold in May 1992, he complained that the imaging model did not support more than one colourant for type. Users of Apple Pages are colouring type like crazy and are completely clueless about the consequences for a separations device, as I suspect from time to time was Jonathan Seybold -:).
It is significantly simpler to understand PDF in OS X by comparing with PDD in GX. In both strategies, the idea is to image in a view port model instead of in a program-interpreter model since the latter has long been proven inherently unreliable. In both strategies, the idea is to use page description model in the view port model as spool file format internally, presently replacing PDF with PS as internal spool file format. And in both strategies, the idea is to limit device dependent parameters in the spool file format as much as possible. The problem with device dependent parameters is that an awful lot of prior agreement, more or less private, has to take place which militates against blind exchange of portable documents.
There is non-sense implementation and there is non-sense opinion on non-sense implementation. Which is the more non-sensical I wouldn't know. There are plenty of people burning my effigy already, so a few more won't make much of a difference.
/hh
Reference:
http://store.creativepro.com/node/58748