[plug] OpenOffice.org in a pre-press environment.

Craig Ringer craig at postnewspapers.com.au
Sun Jan 16 16:28:16 WST 2005


On Sun, 2005-01-16 at 11:50, James Devenish wrote:
> In message <1105840941.3537.1.camel at latte.internal.itmaze.com.au>
> on Sun, Jan 16, 2005 at 01:02:21PM +1100, Onno Benschop wrote:
> > my logo was originally a GIF
> 
> Aiee! :) Please don't tell me you were using it at 72dpi, too :)

Seconded - decent effective resolution of images on a PDF is really
important. The POST requires 200dpi minimum, and prefers 300dpi - and
since we're printing on newspaper, chances are anybody else's specs will
be higher than that.

> > The printer also complains that the text boxes are RGB, even though
> > they're black, and even selecting CMYK/Black made no difference.

Ideally you shouldn't be generating PDFs with such issues, but then OO.o
isn't exactly the best tool for generating press-ready PDF. If your
printer is a "print shop" that regularly deals with the public, though,
they should be more than able to deal with minor issues like this. Your
printer should be able to trivially fix this with a tool such as
PitStop. If they don't have any preflight tools like that, then ...
well, I'd be looking for another print shop personally. Of course, it
may be that they simply don't want to have to fix the PDF (even though
PitStop lets you automate most fixes as well as checks) or want you to
take responsibility for any required changes.

Feel free to mail me the document - I'll check it out in PitStop and if
it looks sane, send you back a copy with true greyscale and CMYK
colours.

> In PDF terminology, I think these are "DeviceRGB" colours. The
> problems are twofold. Firstly, those DeviceRGB values can't be used by
> a full- colour CMYK print process because such a process does not
> actually have any red, green or blue inks. Thus, the colour must be
> transformed from RGB to CMYK.

Typically this is done by the printer during preflight, where necessary,
with much wailing and gnashing of teeth. The RGB colour space doesn't
map perfectly onto the CMYK colour space, and printers really prefer not
to risk changing your colour results. That said, any half-decent RIP (or
preflight tool) should be able to handle conversion from RGB "black" to
true greyscale black without any issues.

> Secondly, this produces a mirky and wasteful result because the
> naive mathematical operation will give CMYK values of 1 1 1 0 (i.e. the
> printer will consume cyan, magenta and yellow inks at full strength to
> produce a dark mirky brown instead of using the pure black ink).

The colour conversion process used in the RIP / preflight tool usually
applies "black pullout" to address this. Trouble is, there's no exact
right answer as to how much to leave as mixed colour inks and how much
should be applied in the black channel instead.

> The general solution is to design a page in CMYK. Alternatively, it is
> probably possible to go down the path of colour calibration in which
> perceptual values are stored in the PDF and converted to best- guess
> device values when the PDF in rendered on screen or in print (this is
> what Mac OS X does).

If you embed ICC colour profiles in your PDF and make sure all images
are tagged with ICC profiles, it should be quite safe to use an RGB PDF
these days (so long as your printer supports colour management and
ideally PDF/X-3). Getting the colour management right is usually harder
than just generating a proper CMYK PDF though.

> Better file a bug with the OOo team so that OOo
> will output in CMYK instead of RGB. This won't give you "WYSIWYG"
> results, nor will it give your the result you'd get by paying a graphic
> designer, but it will make 'small office home office' production more
> accessible.

OO.o should /certainly/ output greyscales as real black channel colours,
whether targeting on-screen display or print. CMYK conversion is harder
because doing it "automagically" is a little risky and can change the
user's colours. IMO it's best done at the printers, where they have all
the colour profiles for their press etc - but it seems many printers
don't have basic preflight tools for this sort of thing (or just don't
want to deal with it).

In the end, I'm not sure OO.o is really the best app to be using when
generating PDF for print. The only free-software app I'm familiar with
that generates fairly good press-ready PDF is Scribus. It may be worth
looking into - 1.2.1 just came out, and it's considerably improved.
 
--
Craig Ringer




More information about the plug mailing list