1. 21 Oct, 2017 1 commit
  2. 28 Oct, 2015 1 commit
  3. 11 Sep, 2012 1 commit
    • 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
      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.
      2e77799a
  4. 14 Feb, 2012 1 commit
    • Thomas Freitag's avatar
      Overprint implementation in postscript and splash device · 59946e0c
      Thomas Freitag authored
      It is an enhancement patch, a
      merge fix and a bug fix in one: an enhancement, because it now completes
      the implementation overprint mode and devicen in postscript, a merge
      fix, because it fixes some bugs in the overprint implementation in
      splash of xpdf 3.0.3 and has now the complete functionality (and more!)
      of my implementation back again and a bug fix, because it fixes the use
      of splash cmyk in postscript which never had worked.
      
      1. Overprint implementation in postscript
      To have a complete overprint implementation in the (pure) postscript
      device there were just two things missing: overprint mode and the
      implementation of the DeviceN colorspace in PostScript. I double checked
      my implementation with the Ghent Test Suite with GhostScript (device
      pdfwrite) and Acrobat X distiller, and all the tests now succeeds,
      either in Acrobat X distiller or in GhostScript. As overprint is a
      device dependent feature, it is up to the output device if it supports
      overprint and what features of overprint are supported, and often You
      have various configuration possibilities there. Nearly all PostScript
      output of the Ghent tests show now the desired results if converting it
      back to PDF with ghostscript pdfwrite, the implementation in ghostscript
      is complete. On the other hand a few tests failed when using Acrobat X
      distiller, all of them with the overprint mode switch. Funny, because
      overprint mode 1 is often also called the illustrator overprint mode
      because it was introduced by illustrator, but probably the destiller
      only handles EPS correctly which comes from illustrator
      
      2. Overprint implementation in postscript if using splash rasterization
      Of course the postscript overprint implementation will only work if
      pdftops doesn't decide to use splash to rasterize it because of the use
      of transparencies in the PDF. But because overprint is device dependent
      I decided to spend an additional parameter "overprint" to pdftops
      (simular to pdftoppm). Switching it on (only available if compiled with
      SPLASH_CMYK, because overprint is only in CMYK colorspace showable) will
      use the overprint implementation in splash also if rasterizing the PDF.
      
      3. Overprint implementation in splash
      The overprint implementation in splash now uses the better designed
      interface of xpdf and therefore now also works in transparency groups.
      Thanks to the developper team of xpdf. I just fixed a small bug in it,
      where it defies the technical specification. Of course it is still in
      the nature of the splash implementation that it fails if CMYK values
      should overprint spot colors, because spot colors are converted
      immediately in their CMYK alternates. And in the implementation of
      overprinting spot colors over CMYK colors I made a small assumption to
      get it running which causes undesired results if this assumption fails,
      but I didn't want to implement more and more configuration switches. I
      still plan to implement a DeviceN output in splash and make a complete
      implementation there, but this is of course a bigger task (but doable).
      The overprint switch in pdftoppm is still only available if compiled
      with the SPLASH_CMYK directive.
      59946e0c
  5. 07 Jan, 2012 1 commit
    • Albert Astals Cid's avatar
      xpdf303: Merge some stuff in Splash [Thomas Freitag] · 34ae3829
      Albert Astals Cid authored
      1. merge the complete pipe changes
      a) including the overprint implementation from Derek used by pipe
      b) including the transfer function implementation
      2. Two changes (not really a merge) to get it compiled under windows (in
      GlobalParams.cc & PDFDoc.cc)
      3. merge fill and stroke changes
      a) including merge of SplashClip.cc
      b) including merge of SplashXPathScanner.cc
      34ae3829
  6. 28 Jul, 2011 1 commit
  7. 02 Jun, 2009 1 commit
  8. 25 Apr, 2007 1 commit
  9. 30 Oct, 2005 1 commit
  10. 27 Aug, 2005 1 commit
  11. 03 Mar, 2005 1 commit