| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we set out to render an image, we calculate the target
rectangle. We attempt to reduce this according to the
clip path as much as we can so as to limit the amount of
excess work we do - particularly for interpolated images.
Unfortunately, in some cases (including some clist cases) this
code is called without a clip path in place, and so we were
failing to clip the target at all. This meant that for images
that spanned the whole page, we could end up interpolating the
whole image for every single band.
Here, we adapt the code so that in the absence of a clip path
we use the bbox of the target device as bounds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The pdfwrite device can 'rewrite' the image matrixes in a
particularly nasty way that is not easy to avoid. It does this
to be able to capture images with masks of a different size.
Unfortunately, this breaks any possibility of us using the
imagematrix to figure out which source region of the image
we actually need for clipping.
Introduce a new flag to capture when this happens so we can
avoid relying on an untrustworthy imagematrix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The example file (or at least the cut down one), contains a smallish
(256x256) image that is scaled up a lot (to 35379449,35379449). This
does not fit on the 360x240 output (at 10dpi), so only a small
proportion is required.
Because interpolation is required, we don't want to calculate all
1.25 quadrillion output pixels. Accordingly, we calculate the
'patch' region of the source that is actually required, and then
only process that region.
Make the calculations more accurate to try to minimise the
source region. In particular, on an upscale, it doesn't need to be
increased as much as on a downscale.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the capability to simulate overprint including that of
spot colors for all devices including gray and RGB devices. This
is achieved by having the PDF interpreter look if overprint
is present, the seting of -dOverprint (/simulate /enable /disable),
if the page has transparency, and if the page has spot colors. Depending upon
the color model of the device, and if transparency is present,
a special push of the pdf14 device may occur. The pdf14 device
buffer collects the data in a CMYK or CMYK+spots buffer and the
put_image method in the pdf14 device will map the buffer to
the target device color space. The code was tested with
devices that support and do not support spot colors, those that
support and do not support alpha channels, tag based devices,
gray, RGB, and CMYK devices. A special test file to check
multiple cases was added to the regression suite. By default
-dOverprint is set to /enable, which should result in the existing
behavior where by RGB and Gray devices do no show overprint or spot
colors and CMYK devices will handle CMYK overprinting and separation
devices will show spots and overprint of all colorants. With
-dOverprint set to /disable no device will show overprinting. With
-dOverprint set to /simulate all devices will show overprint and
spot colors. Ray Johnston did the work in the interpreter as
well as the device parameter default setup. I did the pdf14 device
changes and testing. Changes in a variety of locations were required
due to the fact that new combinations were encountered, for example
we had cases where devn colors were being used with a device that
supports tags (bitrgbtags device and pdf14 compositor setup for CMYK+spots).
One file:
tests_private/xps/xpsfts-a4/fts_34xx.xps.pdf ppmraw 72 now produces
an error. This file should have been throwing an error all
along but was being quietly swallowed. Acrobat will not open
the created pdf file and throws and error. I will open a bug
for the issue as it is a problem with the XPS interpreter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interface code to the CMM was corrected to indicate when a
endian swap was needed on the data. This should only occur
in the case when we are dealing with transparency buffers
during the put image blending operation that may include
a color conversion. The final blend bakes the data as BE
so if we are on a LE machine, the CMM will need to know to
swap the bytes (assuming the pdf14 device is using 16bit buffers).
The code was rewritten to make it clear that this setting is no
BE vs LE but simply an endian swap. That was a source of confusion.
Revealed in this testing was the lack of some proper error
reporting during buffer conversions, which were fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This relates to the structure gx_image_enum_s which is used by image1
and image4.
The fix is unfortunately scattered around the code, but I think I found
appropriate places. It is ugly because type1 and type4 images
apparently share a lot of the same code, so the module layers are not
as they should be.
Need to increment and decrement the rc since the enum struct wants to
keep it around (especially in gs where it literally goes back out into
the gs interpreter between when the enum is built and when it is
used!).
This is part of cleaning up memory leaks for non-GC interpreters
(pdfi).
Changed the pcs entry in the enum struct to not be const, since it
needs to be reference counted.
Cleaned up an unrelated compiler warning in gxidata.c
There are also some unrelated whitespace changes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Release testing has shown up another case that needs help.
gs/bin -sDEVICE=ppmraw -o out.ppm -r300 -dMaxBitmap=1G
tests_private/pdf/sumatra/1901_-_tiling_inconsistencies.pdf
This shows horizontal white lines in the "Next" "Up" "Previous"
images at the top of the page.
Investigation shows this is due to the images having Masks as well
as SMasks.
The Mask image is run to a 1 bit memory device, which means that
the gxdso to check if we are in an SMask doesn't work. We work
around this by introducing a new flag to gs_pixel_image_common
that we can set to indicate that we are within an smask. We set
this when we set the masked image up (using the gxdso), and check
it when we come to do the gridfitting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an earlier commit, (Jan 27th, f6f8b8de) I updated the gridfitting
logic so that Images within SMask definitions were gridfitted. This
solved the original complaint.
Sadly, this caused problems with other things (thanks to Ken for
spotting them). Files sometimes use an image in an smask, and then
another "matching" image masked by that smask. The upshot of my
new code was that we'd treat them differently. 'Stretching' the
SMasked image, and not stretching the underlying image could cause
moire effects.
The solution, implemented here, is to apply gridfitting to images
both in SMask definitions and usage.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of rendering SMasks, we take the bbox for the region, and round
it up to make the buffer in pdf14. If (as is frequently the case) the
SMask contents are an image, the PS rendering of that image can result
in it rounding DOWN (due to "any part of a pixel" vs "pixel centre
covered"). This can result in 'cracks' around the edge of smasked
groups.
The fix, implemented here, is to extend the logic that "gridfits"
images within pattern accumulator to also cover smasks.
To make this work we add a new gx_dev_spec_op to detect whether we are
in an smask definition.
|
| |
|
|
|
|
|
| |
Prevent leak in gx_image_enum_begin by freeing clip_dev.
Error created using :-
MEMENTO_FAILAT=15565 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0954
|
| |
|
|
|
|
|
| |
Prevent memory leaks on error and then later releasing graphic state.
Error created using :-
MEMENTO_FAILAT=15242 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0720
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rework ROP behaviour with transparency based upon the results
from roptest.pxl seen on an HP printer.
The old style ROP transparency code used to treat white pixels
as special. The new style code does everything in boolean logic
by modifying the ROP that is used when S or T pixels are set to
be transparent.
This enables us to rip out several cases from the ROP
processing loops, as we never need to check for transparent
pixel values anymore.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Fix memory leak due to buffer not being freed on error.
Error created using :-
MEMENTO_FAILAT=10035 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0010
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we start an image, the image code runs through the handlers
for different types of image until it finds one that can handle
the required type.
These handlers are queried with the current device in as penum->dev.
The image code then sets up any clip or rop device on top of this
device.
If the handlers were to call device functions, they would be in
the somewhat odd position of calling a different device in the setup
phase than they would be calling in the processing phase. This
upsets a forthcoming commit.
The fix is to ensure that any clip and rop devices are setup BEFORE
the image handlers are called.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rendering images, if the dda is not shared between the
halftoner and gs, gs cannot just skip lines that it knows should
be clipped, lest the halftoner get confused about it.
The previous attempt to solve this used a separate 'skip_render'
routine, but the decision as to whether to call this or not was
itself dependent on the values of the dda. When scaling down
scanlines can be completely skipped. In the cases where the dda
in gs doesn't match the one in the halftoner exactly we could
get dropouts.
So, a new attempt. Here we introduce a new function call that
checks with the halftoner whether the next scanline will be
required or not. If it is, gs unpacks the data and passes it in.
If not, the data can just be skipped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As gs runs through image data, it unpacks each line into
a buffer, then checks whether that buffer is trivially
outside the clipping region. If it is, then it doesn't
bother to call the line renderer.
This has 2 implications. Firstly, we unpack the line data
even if it is to be skipped. Secondly, for line renderers
that rely on counting the number of lines they have been
passed (rather than on consulting the position of the dda)
to know where they are, this can cause problems.
Accordingly, this commit rejigs the code a bit. As well
as a function pointer within penum that points to the
rendering routine, we have a new function pointer that
points to an optional "skip_render" routine.
We also rejig the code so that we only unpack the data if
we know it is going to be used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change to ref_count of profiles needs to be protected by a lock if
the profile ref_count could be changed by another thread. Also when
decrementing the ref_count to 0, we cannot free the lock until after
the profile has been unlocked.
New routine gsicc_adjust_profile_rc replaces old (not threadsafe) function
gsicc_profile_reference.
Also add tracing "cname" to the RC_ADJUST_ macro to aid in debugging
with -Z^ debug flag.
Testing had revealed race conditions which are now fixed (eliminate use
of semaphores).
This also changes the gsicc_lcms2art.c interface functions to keep a
list of transforms configured to have differing buffer formats that
include alpha, planar IN/OUT, big_endian IN/OUT, bytes_per_component
IN/OUT which are cloned as needed by threads.
Change gscms_is_threadsafe to return "true" in gsicc_lcms2art.c
TBD: If a link fails to build a thread may hang waiting for the link
profile to become valid if it was not the thread that was building it.
Not a new condition, but exposed when gscms_is_threadsafe returns true.
TBD: Fix error handling / clean-up when links fail to build. Also not
new, but is needed to prevent leaks, and possibly hang conditions.
|
| |
|
|
|
| |
Prevent numerous SEGV points by ensuring error codes are returned and
handled appropriately
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We store the image size as a rectangle in the image enumerator.
For the purposes of scaling, we also store the rectangle that
needs to be rendered. We expand this slightly to allow for
the support requirements of the scaler, thus giving a rectangle
that is really what we need to decode.
In order to correctly setup the scaler we then need to try to
guess how much expansion was done. My previous attempts at
this guesswork failed.
A simpler solution would appear to be to just save both the
render and decode rectangles stored separately. This simplifies
the logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #698995 "Fixing error returns in gxicolor.c can cause PXL to enter an infinite loop or seg fault"
This started off as a fix to a scanbuild warning and spiralled somewhat.
Fixing gs_image_class_4_color() so that it didn't ignore an error return
led to the possibility of the PXL interpreter seg faulting or ending up
in an infinte loop.
Initially this turned out to be because gs_initgraphics() was no longer
setting the colour space to the proper default, leading to us trying
to use the very pattern space which failed. That was fixed in the
previous commit.
After that it turned out that in an error condition we were freeing
an image enumerator twice. This didn't seem to cause the PostScript
interpreter a problem, though it seems likely it did really, it simply
didn't exhibit before the interpreter exited. The PXL interpreter
however threw an error in the memory manager rather rapidly.
Fixed that by not calling gx_default_end_image in gx_enum_begin()
when we hit this particular error condition (no handler for an image).
This removes one of the free instances, and seems more reasonable anyway
it seems wrong to end an image we haven't yet begun.
This allows us to now propagate the error up from px_remap_pattern
without causing a seg fault or infinite loop. (finally)
|
| |
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
| |
|
|
|
|
|
| |
There was an overflow check for ht_buffer size, but none for the larger
threshold_buffer. Note that this file didn't fail on Windows because the
combination of the ht_buffer and the size of the (miscalculated due to
overflow) threshold_buffer would have exceeded the 2Gb limit.
|
| |
|
|
|
|
| |
The fix for coverity ID# 127201 introduced a compiler warning due to an
accessor macro (ctm_only) implicitly adding const. Make the local variable
const, too.
|
| |
|
|
|
| |
Fix potential NULL pgs (graphics state) pointer dereference. I suspect this can
never occur, but it's cheap and should silence coverity
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #697596 "Use-After-Free in i_free_object()"
There is confusion over ownership of 'penum' between gx_begin_image1(),
gx_begin_image4() and gx_image_enum_begin() which is called from these
two functions (and only from these two functions).
The enumerator is allocated in gx_begin_image?() and freed there if
gx_image_enum_begin() returns an error. However, gx_image_enum_begin()
also frees the enumerator on an error; except that it doesn't always do
so. Its a large function and there are at least 9 ways to exit it, only
4 of which free the enumerator.
This commit removes the 'free' instances from gx_image_enum_begin()
leaving the cleanup as the responsibility of the calling code, which
performed the allocation.
|
| |
|
|
|
|
|
| |
The penum->rect values were cleared, and this didn't cover all uses of
gx_image_enum_alloc. Also, return *ppenum NULL if alloc fails in case the
caller doesn't check the return code. Also, if we fail the enum_begin,
free the enum and set *pinfo to NULL.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the clip list accumulator is optimized for x-major entry of rects,
if we know the information is y-major, as for landscape imagemasks, then
transpose X and Y in the list, and similarly transpose back when doing
the clip_enumeration bounds checking and calling the target operation
(process function).
This improves the processing of the customer's file from 1900 seconds to
96 seconds!
So far only landscape imagemask clip path accumulation uses this. TBD
is to evaluate if any other uses of the clip path accum device can take
advantage of this transposition.
|
| |
|
|
|
|
| |
If the scaling was less than the threshold, interpolation would be skipped
even if it had been forced by logic in gxipixel.c. Also skip interpolation
if it doesn't do anything (Width and Height In == Out).
|
| |
|
|
|
|
| |
PCL uses patterns (a lot) but due to rounding patterns intended to be 1:1
scale end up as slightly less (grasshop.pcl) so interpolation would be
forced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how gstate initialisation is done:
Previously we relied on the imager state being a subset of the gstate (thus
assigning an imager state to a graphics state over wrote to the entries
common to both, and didn't overwrite any already set graphics state specific
entries).
Making the imager and graphics states the same means that approach doesn't work,
so this changes it to initialise the entries individually.
Renames gsistate.c->gsgstate.c and gxistate.h->gxgstate.h
Cleanup and fix the gs_state gc stuff.
Uses different check for pre/post clist pdf14 device
Previously, the code used "is_gstate" in the imager/graphics state object
to determine if the code was being called pre or post clist (post clist would
only ever have had an imager_state so is_gstate = false).
With no imager state any more, that test would no longer work (and I am dubious
about whether it was really safe, anyway). Other places check for the presence
of a clist reader device in the pdf14 device structure - so use that here
too.
Adds initial (NULL) value for show_gstate pointer in gs_state.
Removes the now pointless macro for the contents of the graphics state
Changes function names that had "imager" to use "gstate"
Removes the redundant 'is_state' flag
Cleans up gs_(g)state_putdeviceparams():
Previously we had to similar routines: one took a graphics state, and used the
device from the graphics state, the other took an imager state and the device
as an explicit parameter.
With the removal of the imager state, "merge" those two functions
Replaces gs_state with gs_gstate
It makes for less confusion as it really is a g(raphics)state
|
| |
|
|
|
|
|
|
|
|
| |
gx_make_rop_texture_device checked 'target' to see if it is NULL, but
then later dereferenced target without checking. It 'looks like' this
is a condition which can't happen, because we would get a seg fault.
In fact it is only called from one place, and that location
(gx_image_enum_begin) can return an error, so I've chosen to ensure
that the argument cannot be NULL before calling gx_make_rop_texture_device
|
| |
|
|
|
|
|
|
|
|
|
| |
The gxino12b.c and gxino16b.c modules were no longer used and the
graphics library always supported 12 and 16 bit images, so remove
the leftover code allowing for these to be build time options.
This was causing false positives with helgrind since the procs
were being set into the two-dimensional array at run time. The
unpackicc_16 had this same code even though there was no method
or check for non-support.
|
| |
|
|
|
|
|
|
| |
To interpolate imagemasks, we need to do a copy_alpha operation.
These are impossible to do well on a pattern accumulator due to
the 1bpp alpha plane.
As such the best thing we can do is to sidestep the problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous commits in this area went in piecemeal and caused lots of
diffs which were then fixed etc. By committing here in one go, we
hope to get saner results from the tests which we can have more
confidence in.
A summary of the changes:
1) Introduce a mechanism so that we can know whether we are in
a pattern accumulator or not.
2) When plotting an othogonal image use that mechanism to detect
whether we are in a pattern accumulator. If we are, then grid
fit the image.
3) If we are in a pattern accumulator and we are downscaling an
image, then interpolate it. This avoids nasty dropouts with
halftoned images that can (due to nearest neighbour plotting)
suddenly change massively in appearance.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert:
1) "Bug 696132/696572: Continued "pattern gap" work - interpolate"
commit 80693d83612e03b26a5006b74296c6e9f11779da.
2) "Bug 696132/696572: Continued "pattern gap" work - tidying."
commit 1b843b1a6adca2f0245af8049b7c5d6d8f00ae5d.
3) "Fix gridfitting images being too greedy."
commit c902d4d4ba62306aa59cd30c3f450af5ad7bf797.
4) "Bug 696132: Grid fit images within pattern fills."
commit 6b04051b251d7dbde9a2e6f170cac9dc7950e20e.
After this I can reintroduce the commits and get (hopefully)
cleaner testing data.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Marcos reports (in bug 696572) that many files have problems
after the commit done for bug 696132. That commit was intended to
cause all orthogonal images within a pattern to be gridfitted.
Due to a mistake, this actually caused all orthogonal images
ANYWHERE to be gridfitted. That bug was fixed a few commits
ago (c902d4d).
Having fixed that, so we now operate as originally intended
we still have some problems showing. These (in the cases tested
at least) appear to be due to the radically different renderings
given of images when they are very slightly permuted. This is
because when images are being rendered at a smaller size
than their source, dropouts occur.
A classic example of this might be an image of the form:
* * * * * *
* * * * *
* * * * * *
* * * * *
which is used as a pattern to give a halftone efferct.
When downscaled, this is very sensitive to dropouts; we can easily
get solid black or white out of such images. Using interpolation
gives a truer rendition of the intended output.
This commit spots such downscales of gridfitted images within
pattern accumulators and forces interpolation on for them.
|
| |
|
|
|
|
| |
Rejig the existing code slightly to make it more readable.
No functional changes, just clearer code.
|
| |
|
|
|
| |
Devices that don't understand a gxdso will return -1, which we
were incorrectly reading as meaning "gridfit this image".
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To avoid white lines appearing between pattern fills, grid fit
images whenever they appear within such fills.
Gridfitting involves stretching any axis aligned image to
completely cover the pixels it touches.
The vast majority of this patch is to do with detecting that
we are in a pattern accumulation device in a nice way (allowing
for the possibilities of pdf14 accumulators etc).
|
| |
|
|
|
|
|
|
| |
Valgrind reports an indeterminism in gs_image_class_1_simple,
caused by penum->map[0].inverted not being set.
Analysis reveals that image_init_colors is not setting .inverted
in some cases. The fix is simply to ensure that it's always set.
|
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|
