1. 21 Sep, 2012 3 commits
  2. 20 Sep, 2012 2 commits
  3. 17 Sep, 2012 3 commits
  4. 16 Sep, 2012 7 commits
  5. 15 Sep, 2012 2 commits
  6. 13 Sep, 2012 1 commit
  7. 11 Sep, 2012 8 commits
    • Albert Astals Cid's avatar
      Make gcc happy · cb93d51c
      Albert Astals Cid authored
      It is stupid and can't see that we only use them when we init them and complains
      they might be used un-initialized
      cb93d51c
    • Thomas Freitag's avatar
      Splash: Avoid bogus memory error for tilingPattern · 3349a8dd
      Thomas Freitag authored and Albert Astals Cid's avatar Albert Astals Cid committed
      just return gFalse if the resulting
      tiling pattern bitmap reaches a memory limit and so the Gfx implemention of
      tiling patterns will be used. I think that this is an acceptable approach also
      concerning performance, because it would take also a while to paint such a huge
      bitmap and then draw it to splash.
      3349a8dd
    • Thomas Freitag's avatar
      Splash: Implement DeviceN support · 2e77799a
      Thomas Freitag authored and Albert Astals Cid's avatar Albert Astals Cid committed
      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
    • Albert Astals Cid's avatar
      cb2ed646
    • Jason Crain's avatar
      Allow multiple fonts in a TextWord · f3a1b765
      Jason Crain authored and Albert Astals Cid's avatar Albert Astals Cid committed
      Bug #6923
      f3a1b765
    • Albert Astals Cid's avatar
      Do not use isnan as it is C99 · 3ce4d213
      Albert Astals Cid authored
      3ce4d213
    • Jason Crain's avatar
      Check for NaN in TextPage::addChar · 4d7a64a2
      Jason Crain authored and Albert Astals Cid's avatar Albert Astals Cid committed
      4d7a64a2
    • Tobias Koenig's avatar
      Make 'additional actions' available in Annotation API of Qt4 frontend · e79b70ec
      Tobias Koenig authored and Albert Astals Cid's avatar Albert Astals Cid committed
      Bug #53589
      e79b70ec
  8. 10 Sep, 2012 3 commits
  9. 09 Sep, 2012 11 commits