1. 06 Dec, 2018 2 commits
  2. 23 Oct, 2018 1 commit
  3. 10 Oct, 2018 1 commit
    • Adam Reichold's avatar
      Remove usage of pragmas interface and implementation · 7f20ace4
      Adam Reichold authored
      GCC recommends not using them for a long time and its documentation says:
      > These #pragmas have been superceded as of GCC 2.7.2 by COMDAT support
      > and the “key method” heuristic mentioned in Vague Linkage.
      > Using them can actually cause your program to grow due to
      > unnecessary out-of-line copies of inline functions.
      Also nobody seems to set USE_GCC_PRAGMAS and sometimes they were
      guarded by just __GNUC__ which upsets Clang.
  4. 23 Sep, 2018 1 commit
    • Albert Astals Cid's avatar
      More const · b8b82412
      Albert Astals Cid authored
      Marked some caches as mutable
      Fixed an actual bug in page::text that was swapping the page cropbox in
      each call
  5. 31 Aug, 2018 2 commits
  6. 23 Mar, 2018 1 commit
  7. 14 Feb, 2018 2 commits
  8. 08 Jan, 2018 1 commit
  9. 03 Nov, 2017 1 commit
  10. 21 Oct, 2017 1 commit
  11. 08 Mar, 2017 1 commit
  12. 02 Nov, 2016 1 commit
  13. 16 Mar, 2016 1 commit
  14. 10 Mar, 2016 1 commit
  15. 02 Mar, 2016 1 commit
  16. 28 Oct, 2015 1 commit
  17. 24 May, 2015 1 commit
  18. 14 Jan, 2015 1 commit
  19. 20 Jul, 2014 1 commit
  20. 20 Feb, 2013 1 commit
  21. 12 Feb, 2013 1 commit
  22. 26 Jan, 2013 1 commit
  23. 19 Jan, 2013 1 commit
  24. 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
      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.
  25. 13 May, 2012 2 commits
  26. 25 Apr, 2012 1 commit
  27. 11 Mar, 2012 1 commit
  28. 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.
  29. 06 Feb, 2012 1 commit
  30. 15 Jan, 2012 1 commit
    • Albert Astals Cid's avatar
      [xpdf] More Splash and Gfx changes from Thomas · 9c092e17
      Albert Astals Cid authored
      1. merge of blend changes
      Here I had not only merged the changed in blend modes, I made also a few
      changes in the SPLASH_CMYK area, so that the already sent PDF now also
      be rendered correctly with the -jpegcmyk option
      2. merge of font handling in SplashOutputDev.cc
      There were a few changes left in font handling, I took them over
      3. merge of getcolor-changes
      The getcolor changes win a price for well defined C++ code. I wouldn't
      have merged them, if there were not a lot of other things to merge.
      4. merge of image handling in SplashOutputDev.cc
      I merged the left changes in image handling including colorizing masks
      in pattern colorspace
      5. cleanup of overprint
      I tested the overprint implementation of Derek. They succeed only in 70
      % percent of the PDF where my solution had success, but Derek's solution
      is much cleaner, and I'm sure that I could also fix the rest in it. BUT:
      as I already considered, when I implemented overprint, there are some
      overprint situations, which can not be solved in a CMYK colorspace, we
      have to implement a DeviceN colorpace when also overprint from CMYK
      colors over spot colors should work. Therefore I decided to remove my
      overprint implementation completely from the code and let Derek's
      solution in, even if there could be done some enhancements in it.
      6. colorizing text in pattern colorspace
      When I saw Derek's implementation with a clean interface only at one
      place in Gfx.cc, I first was very surprised. My solution had a lot of
      places in Gfx.cc, where I looked if the current colorspace is a pattern
      colorspace. Therefore I first had a look into the PDF specification
      again, and really, it can be done in the way of Derek. Therefore I
      merged it and removed the fragments of my code.
      On this step I started a regtest against the version after the fourth
      patch. There were a lot of enhancements, especially in texts with
      symbolic chars like mathematical and so on, but there was one (and ONLY
      one) regression, shown in bug-poppler27482.pdf
      I examined that (that is also the reason for the delay) and encountered
      that on merging I removed my solution for this bug, therefore
      7. insert enhancements for colorizing masks in pattern colorspace
      I adapt the bug fix from bug 27482 to the merge.
  31. 10 Jan, 2012 2 commits
  32. 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
  33. 01 Sep, 2011 1 commit
  34. 18 Aug, 2011 2 commits