summaryrefslogtreecommitdiff
path: root/splash
AgeCommit message (Collapse)AuthorFilesLines
2012-10-04Merge remote-tracking branch 'origin/poppler-0.20'Albert Astals Cid1-0/+4
2012-10-04Do not render invalid outlinesThomas Freitag1-0/+4
Bug #55573
2012-09-11Splash: Implement DeviceN supportThomas Freitag7-22/+426
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.
2012-09-09Merge remote-tracking branch 'origin/poppler-0.20'Albert Astals Cid2-0/+26
2012-09-09Fix invalid memory access in solves 1066.pdf.asan.38.75Thomas Freitag2-0/+26
2012-09-06Add missing licensesAlbert Astals Cid1-0/+1
2012-09-06Replaced srand/rand calls in SplashScreen with grandom callsFabio D'Urso1-5/+2
2012-08-03Fix segfault when scaleImage returns NULLMarkus Trippelsdorf1-0/+7
Bug 52488
2012-08-03Fix segfault when scaleImage returns NULLMarkus Trippelsdorf1-0/+7
Bug 52488
2012-08-01Splash: Blend mode enhancements for CMYKThomas Freitag1-22/+0
2012-08-01Splash: Blend mode enhancements for CMYKThomas Freitag1-22/+0
2012-07-19Unify poppler-config.h includes in core "installed" headersTorsten Kasch2-2/+2
Bug 52193
2012-07-19Unify poppler-config.h includes in core "installed" headersTorsten Kasch2-2/+2
Bug 52193
2012-07-13Fix Splash::arbitraryTransformImage causes bogus memory allocation sizeThomas Freitag2-36/+47
Bug #49523
2012-07-13Fix Splash::arbitraryTransformImage causes bogus memory allocation sizeThomas Freitag2-36/+47
Bug #49523
2012-06-24Change SplashBitmap gmallocn to gmallocn_checkoverflowAlbert Astals Cid2-21/+34
Fixes abort in KDE bug #302372
2012-06-24Change SplashBitmap gmallocn to gmallocn_checkoverflowAlbert Astals Cid2-21/+34
Fixes abort in KDE bug #302372
2012-05-17Fix logic on SplashBitmap::writeImgFileAnthony Wesley1-1/+2
2012-05-17Fix logic on SplashBitmap::writeImgFileAnthony Wesley1-1/+2
2012-05-10splash uses cmykTransferC for M, Y and K in two placesWilliam Bader1-7/+7
2012-04-29include for memcpyAlbert Astals Cid1-1/+2
2012-04-29SplashOutputDev: Fix rendering of knockout groupsAlbert Astals Cid4-6/+45
Bug #12185
2012-04-11Fix Splash CMYK merge errorThomas Freitag1-1/+1
Mail says ****** Hi, playing around with the attached PDF to get a better CMYK support for the blend mode soft light, I encountered that I made a big mistake during merge in the CMYK part of splash. I fixed that. The attached patch also includes the small enhancement I made in soft light routine. ******
2012-03-28update Makefile.am to reflect LIBJPEG_CFLAGS, LIBTIFF_CFLAGS, LIBPNG_CFLAGS ↵suzuki toshiya1-0/+16
for related sources.
2012-02-14Overprint implementation in postscript and splash deviceThomas Freitag4-144/+182
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.
2012-02-06[xpdf303] Adapt better to what we did and what xpdf303 doesAlbert Astals Cid6-32/+25
2012-02-06Merge branch 'master' into xpdf303mergeAlbert Astals Cid1-20/+49
Conflicts: poppler/CairoOutputDev.cc poppler/CairoOutputDev.h poppler/FontInfo.cc poppler/GfxFont.cc poppler/GfxState.cc poppler/GlobalParams.cc poppler/GlobalParams.h poppler/Lexer.cc
2012-01-23Do not use 50Kb of stack in SplashXPath::addCurveAlexander Saprykin1-20/+49
Bug 44905
2012-01-15[xpdf] More Splash and Gfx changes from ThomasAlbert Astals Cid4-92/+62
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.
2012-01-10[xpdf303] tiling "merges" from Thomas, using mostly our "old" code instead ↵Albert Astals Cid1-8/+24
of xpdf's
2012-01-10[xpdf303] Splash::blitTransparent merges from ThomasAlbert Astals Cid1-3/+7
2012-01-10[xpdf303] Merge xpath Splash stuff from ThomasAlbert Astals Cid1-9/+13
2012-01-10[xpdf303] Merge splash font stuff from ThomasAlbert Astals Cid6-12/+39
2012-01-10[xpdf303] More merges from ThomasAlbert Astals Cid2-915/+1941
2012-01-07xpdf303: Merge some stuff in Splash [Thomas Freitag]Albert Astals Cid7-700/+1616
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
2011-10-27xpdf303: Use splashDist instead of splashSqrt and USE_FIXEDPOINT enhacementsAlbert Astals Cid2-7/+65
2011-10-13xpdf303: Merge SplashT1Font::getGlyphPath changesAlbert Astals Cid1-18/+21
2011-10-13xpdf303: Add GBool type1 to SplashFTFontFileAlbert Astals Cid2-5/+7
2011-09-11xpdf303: Remove flags that were never usedAlbert Astals Cid3-44/+9
2011-09-08xpdf303: Add codeToGID and codeToGIDLen params to loadOpenTypeCFFFont()Carlos Garcia Campos4-16/+25
2011-09-01xpdf303: codeToGID items can be < 0 nowCarlos Garcia Campos1-1/+1
2011-09-01xpdf303: Use splashDist instead of splashSqrtAlbert Astals Cid1-1/+1
2011-09-01xpdf303: Do the multiplication the other way aroundAlbert Astals Cid1-4/+4
No idea why :-D
2011-09-01xpdf303: Use splashCheckDet isntead of splashAbsAlbert Astals Cid1-1/+1
2011-09-01xpdf303: Assembler for some functionsAlbert Astals Cid1-0/+110
2011-09-01xpdf303: Add splashAvgAlbert Astals Cid1-0/+8
2011-09-01xpdf303: Add getters to SplashClipAlbert Astals Cid1-0/+6
2011-09-01xpdf303: Use int instead of Gushort for gid/cid mapsCarlos Garcia Campos6-16/+16
2011-09-01xpdf303: Remove unused constructorAlbert Astals Cid2-6/+0
2011-09-01xpdf303: Speedup SplashScreenAlbert Astals Cid2-61/+42
By using << instead of * and by putting some functions on the header so they can be inlined