| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Looks like a cut/paste error.
|
| |
|
|
|
|
|
|
|
| |
When rewriting FitPage for the new interpreter I seem to have left part
of the debugging code in place, which led to two incorrect values on
the stack when we calculated the scale factor. I general these values
were zero, leading to a scale factor of 0 and nothing being drawn.
Fixed here by removing the extraneous values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cases where -dOverprint=/simulate and -dUsePDFX3Profile
are used, if the page has overprint and no transparency push the
pdf14 device and render the page to a transparency buffer
to the Output intent color space. If the target device has a
different ICC profile than the output intent (specified
with something like -sOutputICCProfile="Fogra39.icc") then
convert the output intent rendered buffer to the target
device color space. Also make sure that the tiff device do
not use the wrong profile in the header.
Additionally, a problem was found where the pdf14 device
was setting up color conversions using the perceptual rendering
intent. Those transforms should be using the colorimetric
rendering intent.
|
| |
|
|
|
|
|
|
|
|
| |
Thanks to Ken Sharp for providing the solution for this.
If we are doing pattern simulation with the pdf14 device
then the patterns should also do this. Otherwise we can
get seg faults. For example:
-sDEVICE=bitrgbtags -dNEWPDF=false -dOverprint=/simulate
-r72 -o output.ppm -f tests_private/comparefiles/Bug693541.pdf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file supplied for this came from a customer who asked that we
delete the file after working on it, so there is no bug report and no
reproducer for this.
The problem is that the PDF file has a font using a CMap, and that CMap
uses /UseCMap (and the usecmap operator) to read a different (Horizontal)
CMap and then modify it with Vertical glyph positions.
The CMap does not have a begincodespacerange, it simply inherits the
ranges from the child CMap. This causes the code added to work around
Bug 690737 to read off the end of the CMap in read_CMap_stream.
Since there is nothing left to process, this causes errors in the CMap
processing.
Following a suggestion from Chris this commit first attempts the same
'discard up to the begincodespacerange) hackery, then checks to see if
the stream has any bytes left. If it does we proceed as before.
If there are no bytes left, then we have discarded all of the content.
So we rewind the stream to the point we were at before we tried to
discard the header, impose a different SubFileDecode, looking this time
for a 'begincmap' and then attempt to process the CMap as normal.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Ken for finding this. If we are pushing the
pdf14 device we may be doing this if we are doing
overprint simulation or if there is transparency.
Only push the page group if we have Transparency
on the page (there are files which may have a
page group but never use transparency op_all.pdf is
an example of one). Match the conditions for pushing
and popping the page group. Here we only will push
the group if one exists, we have transparency on the
page and we need the pdf14 device (and the device push
and group push were successful).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The spot colors were not being handled properly for
devices that did not support spot colors. Example
issues could be seen with
-sDEVICE=tiff24nc -dNEWPDF=false -dOverprint=/simulate -r72 -o ./myoutputs/testout_rgb.tif -f ./myinputs/op_all.pdf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When simulate overprint is set for a sep device, there is no
need to do a simulation as the device already supports spot
color overprinting. This will change in the future for cases
dealing with rendering to the output intent but the target
device uses a different ICC profile. This issue occurred only
with pdfi.
There was also a problem with the use of patterns in the
case where we are doing overprint simulation. If the pattern
accumulator target is the pdf14 device and we are doing
overprint simulation, then it is necessary
that the pattern accumulator uses transparency. This problem
occurs for the old PDF interpreter and pdfi. This commit
fixes the issue for pdfi. The old PDF interpreter needs an
additional fix.
Example command line with issues
-sDEVICE=bitrgbtags -dMaxBitmap=10000000000 -dNEWPDF=true/false -dOverprint=/simulate -r72 -o testout.ppm -f Bug693541.pdf
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
After we retrieve a 'Box' from the PDF file we use it to setup the
device PageSize. However we were assuming the Box array was always in
the 'normal' format of bottom left corner and top right corner.
The spec is quite clear that any opposite pair is acceptable, so in this
commit we 'normalise' the two corners before we process the array for
the PageSize.
Also remove a commented out left over piece of debug printing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ghostscript has multiple memory management models, of particular interest here
are the mark, sweep and relocate garbage collection, and reference counting.
Postscript objects rely on garbage collection, most internal objects utilize
reference counting. In this case, Ghostscript devices are reference counted
but also allocated in garbage collected memory - so are subject to both models.
A problem arises when Ghostscript device objects are referenced by Postscript,
previously such references were not reference counted where internal references
are. So Postscript like "gsave nulldevice currentdevice grestore setdevice"
would crash because the "nulldevice" created after the gsave was freed (by
reference count) by the grestore, despite a remaining reference from the
Postscript operand stack.
This modifies the approach so Postscript references a "device container" object,
and the container object references the device. The container object is
garbage collected, and the device is reference counted. The device container
object has a finalize method, so just before it is freed, the finalize can
decrement the reference count of the device.
That allows us to maintain the consistency of the device reference count, even
through the Postscript interpreter.
Also remove the solution for a previous, related problem, which this fix makes
redundant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code to retrieve a page dictionary was assuming that, if we reached
a node in the pages tree which contained a dictionary that it was a
page dictionary. This file, however, has a node in the Pages tree which
has a Kids array, containing a reference back to a dictionary which
is the Root pf the Pages tree.
This commit checks the dictionary to see if it is already in the loop
detection array, if it is then we've already visited it, so this must
be a circular reference.
Also removed a couple of unused variables that were causing compiler
warnings.
|
| | |
|
| |
|
|
|
|
|
|
| |
Recent changes in the txtwrite and docxwrite devices tipped the Coverity
heuristic because we now check the return code more often than we don't.
We obviously should have been checking the return code before, so let's
do that here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we made a decision to preserve all the keys in an annotation,
even non-standard ones. However this has led to continual problems with
circular references; for example one file from Bugzilla has an
annotation with a /BookmarkPtr entry, and the object pointed to has a
/AnnotPtr key which points back to the original annotation. In addition
corrupted /Parent keys (various OSS-fuzz issues) have resulted in the
key/value pair not being stripped (because this is an obvious circular
reference).
So instead this commit adds code which only preserves keys from an
annotation if they match a standard key name. This resolves both the
problems noted above.
I still believe that more work will be needed here, as it is potentially
possible that a valid key can contain a reference to an object which
has a circular reference back to the original annotation. We don't
check the values associated with keys.
However, we do have some mitigation in place already, and this
additional may prove sufficient.
|
| |
|
|
|
|
| |
Also cups device: Ignore deprecated function warnings
Using gcc pragmas
|
| |
|
|
|
|
| |
When switching graphics states between Postscript and pdfi.
Found when fixing oss-fuzz 44994.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
An out of memory error can leave the FT TTF hinting context in a partially
initialized state. Meaning bad things can happen if we try to render another
glyph using the same context. Ideally this would be handled by FT internally,
but that means some implications for supporting out of spec fonts, and
performance.
By destroying, recreating and resetting the FT size, it invalidates the
(possibly corrupt) hinting context, and ensures a fresh start in any
subsequent call.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We were using the /Length value supplied in the Encrypt dictionary
even for encryption types where that is not valid. This commit
fixes the KeyLen value for those encryption types for which it is not
a variable (most of them), checks the minimum/maximum and multiple of 8
for the on really variable type, and flags warnings if the /Length is
supplied for an inappropriate filter.
It's possible we will see a load of files encrypted with V 3-6 which
supply a /Length where they technically shouldn't, and will raise a
warning. We might want to not do that in future if it proves irksome.
|
| |
|
|
|
|
|
| |
txtwrite_process_plain_text(): apply part of commit
9f637a543b06 (devices/vector/gdevdocxw.c) to similar code in
devices/vector/gdevtxtw.c:txtwrite_process_plain_text() to handle
TEXT_REPLACE_WIDTHS; this fixes the calculation of glyph widths.
|
| | |
|
| | |
|
| |
|
|
| |
And initial changelog/news entries
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The existing code would drop out after sucessfully reading the
first object from a stream. Fix that by hoisting the code == 0
check before code > 0 check.
Also, eliminate the need to assign code = 0 by modifying a
code == 0 check to be a code >= 0 check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a fir of mis-naming by Adobe, the /Count parameter of an Outline
does not tell you how many descendants a given outline node has, it
tells you how many open items there are at all levels for the initial
node (or missing if there are no open outline items). For descendant
nodes this is either the number of open outlines at all levels below
this one (if the item is open) or the number of descendants which would
appear if the item were opened if it is closed, the latter expressed as
a negative value.
The code was counting the total number of descendant items and using
that as the /Count value, which is simply wrong. We cannot realistically
determine what the correct value should be, we just have to accept
whatever was sent to us.
So this is just a case of deleting lots of code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test file /tests_private/pdf/pdf_1.7_ATS/WWTW61EC_file.pdf exhibits
a marked performance problem on page 2.
This is because it has many shadings, each of which use one of a small
number of functions. We cache the functions, as with all objects, so
would expect these to be processed efficiently. However, the functions
are type 3 stitching functions and each one has 255 sub-functions.
This means that as we process the function array we eject every cached
item (and then some of the sub-functions), which means that we lose the
benefit of the cache.
This commit adds 'nocache' options to the derefrencing code, and new
options in array and dictionary handling to retrieve objects without
adding them to the cache. We only actually use the nocaching array
routine, but it seems worth having a matching dictionary version
available.
This improves the performance of the file in question by a factor > 10.
|
| |
|
|
|
| |
Even if we cannot cache the instantiated font object, we can still use it, so
don't treat a failure to cache as a "hard" error.
|
| |
|
|
|
|
| |
In one of the "in extremis" fallback cases, the return code from Freetype
wasn't being acted upon, leaving a partially initialised glyph bitmap, that we
subsequently attempt to use, resulting in a crash.
|
| |
|
|
| |
To avoid potential double free.
|
| |
|
|
|
|
|
| |
When I rejigged the buffered mode for the X11 devices when using a color
depth that we have to "hide" from the rest of Ghostcript, I got the "color_info"
and the "orig_color_info" logic reversed when setting up the memory buffer
device.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apple Raster (aka URF) output: With -sDEVICE=appleraster or
-sDEVICE=urf (instead of -sDEVICE=cups) the output is in the Apple
Raster format and not in CUPS Raster format.
The format is used by Apple's AirPrint which allows printing from iOS
devices. Due to this practically all modern printers understand this
format and so providing it allows easy, driverless printing.
Before, in order to output Apple Raster, the gstoraster filter of
cups-filters had used the "cups" output device of Ghostscript to
produce CUPS Raster and after that the rastertopwg filter of CUPS had
to turn this into Apple Raster. With this commit a future version of
cups-filters can let gstoraster (the ghostscript() filter function)
directly output Apple Raster and this way save one filter step.
Outputting Apple Raster instead of PWG Raster (which we could already
do via -sDEVICE=pwgraster) is trivial. One has only to tell the
cupsRasterOpen() function of libcups to write Apple Raster headers
instead of PWG Raster headers by a simple flag, so this commit
consists mainly of the definition of the output device names
"appleraster" and "urf" and make the output device set said flag when
one of these device names is used.
I have defined two device names for exactly the same thing, as I am
not really sure which one is the better or if one could cause any
problems. We could remove one later if needed. The output is
absolutely identical for both.
Apple Raster support was introduced to libcups in CUPS 2.2.2, so the
CUPS 2.2 API does not contain it necessarily, therefore the 2.3 CUPS
API is the minimum requirement by the ./configure script to build
Ghostscript with Apple Raster/URF output support.
The libcups which is included with the Ghostscript source is too old,
and when you build with it (--with-local-cups) you will not get Apple
Raster support. But remember that this build option is only for
development and debugging and not for production.
The commit also contains a bug fix: devs.mak hard-coded -I./cups/libs/
in the compilation command line of gdevcups.c, making always the
included cups/raster.h being used instead of the system's one and so
always having a too old cups/raster.h which suggests that Apple Raster
is not supported. This I have fixed by removing the -I./cups/libs/,
--with-local-cups works also without.
|
| |
|
|
|
|
|
|
| |
The object type check for the properties was checking the wrong object
(almost certainly a copy/paste from the top of function). Not a problem
for well-formed files, but the test file had an integer instead of a
name, trying to access the 'data' property of the name led to a read
from random memory.
|
| |
|
|
|
| |
Technically, probably not actually required, as no one ever uses
total_in, but this doesn't hurt.
|
| |
|
|
| |
Probably unnecessary, but this is cleaner.
|
| |
|
|
|
| |
Don't make it take a pdf_obj, let it take a raw string. This avoids
callers needing to allocate/free an object each time.
|
| |
|
|
|
|
| |
Same as 1f2e9b2a9f54af7645bb2641ff7e716f93eb5d30 but for delta_space entries.
Benign problem as the glyphs aren't rendered, but safer.
|
| |
|
|
|
| |
There were obviously duplicate cases of these which I missed because
I find the Coverity web interface hard to use. Fixed them here.
|
| |
|
|
|
|
|
|
|
| |
Says it all really. We store the colour space name for named spaces, so
we can spot attempts to change colour space using the existing current
space.
But if we fail to create/set the space, then it doesn't exist, so we
can't apply the name to it.
|
| |
|
|
|
|
|
|
|
|
| |
In practice I think this is not actually possible to hit, but it's
easy to solve, so let's make certain.
Simply pass a NULL instead of &gnstr, the function already deals with
a NULL parameter.
Also fixed a number of comments that had somehow had whitespace changes.
|
| |
|
|
|
|
|
|
| |
When we call zscreen_enum_init with a screen that doesn't set
spot_function it can get copied into the graphics state. I
couldn't satisfy myself that this never actually matters, so
I settled for initing everything to zero for clarity. This
is not speed critical code.
|
| |
|
|
|
|
|
|
| |
Set the client_color 'pattern' member to 0 before calling gs_setcolor.
Make sure we can't try to call gs_setcolor without initialising at
least one paint value, by checking the number of components in the
space is at least 1.
|
| | |
|
| |
|
|
|
|
|
|
| |
Because args.pv[1] is non-zero, and all the rest are zero,
pxSetHalftoneMethod won't access args.source, but Coverity can't
see this.
For clarity, we update the init of args to clear the whole lot.
|
| |
|
|
| |
Certainly shouldn't hurt, and may genuinely be a bug.
|
