Age | Commit message (Collapse) | Author | Files | Lines |
|
Create a Goffset type and use this type for all file offsets and file
sizes.
Bug 44085
|
|
Bug #50992
|
|
Sorry, when I implemented the support encrypted pdf files in pdfseparate I
missed that writePageObjects of course is also used in pdfunite for combining
pages, and even more that encrypted files are still not supported by pdfunite,
I removed the numoffset from writing the objects itself. Therefore there are
still all objects in the combined pdf file, but the references missing the
numoffset and therefore were no more reachable.
The patch repairs it.
Bug #58569
|
|
|
|
Move all the private data (including the libpng types) to a private class.
This requires HtmlOutputDev.cc to include <png.h> on its own (which is correct, since it uses the libpng API directly).
|
|
On cygwin pdftocairo -v shows the wrong version due to
jpeglib.h defining PACKAGE_VERSION.
Avoid polluting our header files by moving libjpeg.h and
libjpeg types into JpegWriter.cc
Bug 57687
|
|
Bug 57006
|
|
|
|
|
|
|
|
Fixes bug #56817
|
|
This patch also wraps the code that checks the form type and moves it
from pdfinfo to the Catalog class.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Because in next patch I'll need to pass the object's num and gen always,
not only if the object's header and footer need to be written.
|
|
|
|
This also ensures UTF-16 ActualText strings are converted to UCS-4
before calling addChar.
|
|
to ensure only UCS-4 values are used with the "Unicode" type.
|
|
fontconfig is used only in .cpp sources inside the 'poppler' subdirectory, so there is no need to add the include paths for it in other directories;
likewise, do not to link to it if not needed
|
|
|
|
Outputs the font name without any substitutions. Bug #49872
|
|
|
|
|
|
Bug #49758
|
|
|
|
|
|
|
|
write support)
- Trailer dictionary creation now lives in its own function "createTrailerDict"
(that will be used by XRef stream creation too)
- writeXRefTableTrailer (WAS writeTrailer) now takes care of writing the XRef
table too (previously it was demanded to the caller)
|
|
|
|
Issue found by Joel Voss of Leviathan Security Group
|
|
|
|
|
|
|
|
|
|
for related sources.
|
|
Bug 32340
|
|
Bug #47186
|
|
Bug #47022
|
|
Bug 46888
|
|
This patch fixes pdftops -passfonts by using the new psFontPassthrough variable
consistently and removing the old psSubstFonts and its setter and getter in
GlobalParams.
Bug 46744
|
|
|
|
based on pdftpppm patch 7ec31b8dc40ec8a3534fbb89964aa011aeb81f5e
|
|
be preserved
based on pdftoppm patch 38ace7db5de0b2b247fd520e48a8f26e5d28c9d7
|
|
This way people won't expect it to be six fixed digits
Bug #46708
|
|
|
|
preserved
bug 43393
|