Is Pages Good Enough For Professional Printing?

Printing to PDF in Pages in OSX 10.6.4 produces a PDF 1.4 file.

*Results (Summary)*
Error
Number of pages is unequal 1
OutputIntent for PDF/X missing
PDF version is newer than 1.3
PDF/X version key (GTS_PDFXVersion) missing
Page does not have TrimBox or ArtBox (3 matches on 3 pages)
Resolution of color and grayscale images is less than 150 ppi (21 matches on 1 page)
Transparency used (soft mask in image) (20 matches on 1 page)
Transparency used (transparency group) (47 matches on 1 page)
Trapped key not true or false
Uses device independent color (188 matches on 3 pages)
Warning
Resolution of color and grayscale images is between 150 and 225 ppi (6 matches on 1 page)

Printing to PDF/X-3 in Pages produces the error "Couldn't create PDF/X-3 document".

Printing to Postscript in Pages then distilled in Acrobat Distiller 9.2 using PDF/X-3:2002 settings:

Compressed object streams used
Number of pages is unequal 1
OutputIntent for PDF/X missing
PDF version is newer than 1.3
PDF/X version key (GTS_PDFXVersion) missing
Page does not have TrimBox or ArtBox (3 matches on 3 pages)
Trapped key not true or false
Uses device independent color (26 matches on 3 pages)
Warning
Resolution of color and grayscale images is between 150 and 225 ppi (11 matches on 1 page)

Peter

You perfectly know that PDF 4 was a typo.

The correct 'spelling' appears just above in the 'citation' as well as in my original post.

Thank you for the explanations.

Let me say that there is something really puzzling.

You are right, when I use the scheme which you describe, I get :



but when I read the header of the file itself, I get :



I wish to add that when I apply Print to PDF, I get exactly the same behaviour.

As I don't use Preview but Adobe Reader (which is free so Adobe may apply every multiplication factor on the price, it doesn’t matter) I never saw this info.
And as I am using daily Hexedit, I was only aware of the PDF-1.3 header which sounds really curious on a file described as PDF-1.4

In the files built thru the different schemes the block named stream (which seems to be a bitmap block) has exactly the same length but not the same contents.

Yvan KOENIG (VALLAURIS, France) dimanche 22 août 2010 17:21:26

Thank you for the explanations.

You're welcome. Note in passing that the PDF version in itself does not imply that transparency is present, or indeed that transparency is not present, see below.

/hh

Reference:
http://www.enfocus.com/kb.php?id=982

You are testing nothing. Unless the transparent type is overlapping bitmaps it remains vector.

Since introducing issues on the iCalamus support, I have tried to suggest what iCalamus support has suggested, which if memory serves is to save out as PDF in such a manner as not to use the ISO 15930 PDF/X-3 implementation in the Apple ColorSync Utility.

One tends to have posts scotched by Apple employees and scathed by non-Apple employees, so it turns out a tad troublesome all in all. Meanwhile, to stay on the subject of transparency support, here a simple test of several objects simultaneously.

1. Place tagged RGB colour photograph in correct 300dpi+ resolution.

2. Place a composition frame on the area separation frame, insert the character information 'Type', choose the imageable composition in e.g. ITC Bodoni, set US point size to 72, set colour to rubrication red, set opacity to 50%.

3. Pick File > Export > PDF > Best

4. Apply a PDF audit, also apply a visual analysis e.g. scale to 6000% for signs of low resolution rasterisation of the type. Working with Mac OS X 10.4.11 and Pages 3.0.3, the type is not rasterised at low resolution, but stays scalable.

Granted, I may have to have new glasses, but if the Apple ColorSync Utility is set aside, where is the problem?