[Poppler-bugs] [Bug 53140] DeviceN support in splash

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53140

--- Comment #2 from Thomas Freitag <Thomas.Freitag at alfa.de> 2012-08-28 07:48:51 UTC ---
But "implements DeviceN support" is exactly that what it does :-). To explain
it a little bit more I copy a few lines from "Patch 8.01 — DeviceN Support (6
colors)" of the Ghent PDF workgroup:
"This patch tests the DeviceN capabilities of a workflow. If DeviceN is not
handled correctly the colors are converted to CMYK. Instead of the check marks
an X will appear in the lower left corner of each image and in the gradient.
In addition you could inspect the color separations. The objects should appear
only in the Black, Pantone 265C and GWG Green separations as indicated in the
captions."
Without the patch all DeviceN colors are immediately converted to CMYK (with
SPLASH_CMYK). This leads especially to problems, if overprint is used: in
overprint mode a CMYK color will knockout the underlying CMYK components, BUT
neither any spot colors. But if underlying spot colors are immediately
converted to CMYK colors, they will be kocked out then, too!
The patch now spends up to four (or up to SPOT_NCOMPS) additional spot colors
in the splash bitmap, so the order in the bitmap will be
CMYKSTUVCMYKSTUVCMYKSTUV... where S, T, U, V are spot colors (I would use
S1,S2, S3, S4 if it's possible to use indexes), and all painting operations are
done now in this new device. Only at the end, when we want to store the bitmap
in a CMYK or RGB color, the spot colors are converted and their alternate CMYK
components are added to the normal CMYK components.
According to the PDF spec are PDF writer should use different spot color names
if they have a different appearance in their alternate CMYK colorspace.
"hasDifferntResultSet" (sorry for the typo) proofs that: if the same spot color
name is reused BUT has a different appearance in the alternate colorspace, it
will be converted immediately to its alternate colorspace.
"createMapping" is used so that getDeviceN (color) returns the components in
the correct order according their appearance in the splash bitmap, i.e. the
fourth detected spot color must be placed in index 7 of the color array.
updateFill- and updateStrokeColorspace are needed to create this mapping at the
appropriate place. And they are not called once but everytime the colorspace
changed in the PDF (but of course only once in Gfx).
The GooList *getSeparationList() is used to store the functions for converting
the spot colors to their alternate colorspace in order of their appearance in
the splash bitmap. The functions are needed to compare if a spot color with the
same name has really the same appearance and at the end when the splash bitmap
has to be converted to a CMYK or RGB bitmap (s. ahead).
deviceNTransfer is needed simular to rgbTransferX or cmykTransferX if a
transfer function is specified in the ExtGState and splash uses the DeviceN8.
"Do we really need splashModeDeviceN8?": Do we really need splashModeXBGR8? But
kidding aside: splashModeDeviceN8 needs four more components than
splashModeCMYK8, so the bitmap size in memory doubles the size of a pure CMYK
bitmap, and it is only needed if the PDF uses spot colors. So I think it's a
good idea to spend an additional mode and let it up to the calling application
and the cirumstances if it wants to use this new mode or not. 
Once again: sorry for the typo, and of course this->copy() is the same as
copy().
You shouldn't expect any change in a "regular" run, and as far as I remember I
tested that. I also made some tests with valgrind to see that the allocated
memory in this new mode is freed correctly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.