• Thomas Freitag's avatar
    Splash: Implement DeviceN support · 2e77799a
    Thomas Freitag authored
    Bug #53140
    Some copying from the bug tracker
     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
    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.
SplashTypes.h 5.95 KB