| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
We missed updating the clist code to initialise the new
imagematrices_are_untrustworthy member. Consequently in
some cases we were failing to clip the amount of images
we were interpolating.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz #50779 with this command line:
-K1048576 -r200x200 -sBandListStorage=memory -dMaxBitmap=0 -dBufferSpace=450k -dMediaPosition=1 -dcupsColorSpace=1 -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -sDEVICE=pkmraw -r72 -sOutputFile=/temp/out%d.pkm -dBATCH -dNOPAUSE
has a memory leak. This is because the execute_compositor_queue()
function has this comment:
code = apply_composite(cdev, pgs, mem, pcomp, x0, y0, target); /* Releases the compositor. */
But apply_composite only releases the compositor object on success,
if any of the paths fail it does not free pcomp leading to a memory
leak. Address that here by changing apply_composite so that it does
in fact free pcomp unconditionally.
|
| |
|
|
|
| |
by the reading code, so when the actual copy_mono device call happened, it
segfaulted.
|
| |
|
|
|
| |
On Windows long is never 64bits, so 64bit builds were truncating
the offsets.
|
| |
|
|
|
| |
Introduce new lock_pattern device proc and clist implementation.
Call that for fill_stroke operations.
|
| |
|
|
|
|
|
|
| |
The use of set_bits for planar data goes wrong, as on reading we
set num_planes to 1.
Introduce a new set_bits_planar operation that includes num_planes
and use that as appropriate.
|
| |
|
|
|
| |
Also rejig clist_change_bits to avoid nasty (and unnecessary)
use of goto.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly, at various points when writing the clist, we allocate a
block (inside cmd_put_bits) under the name of 'end_run'. This is
dutifully printed by the debugging code. We then rewrite that
block so it's not an end_run at all, but rather something like
a set_bits operation (or even 2 operations).
The debugging printing is therefore confusing. It would be fairly
tricky to neatly (and efficiently) get the printing correct, so
we add some new prints to the debugging code, so that rewrites
of these 'fake' end_runs are documented.
Secondly, we update clist_change_tile to print out the params it
reads back (enabling us to easily compare them to the ones printed
during the writing phase).
Finally, we update a deficiency with the debugging with cmd_read_data.
The reading phase calls cmd_read_data to copy data out from the
buffered stream into blocks of data (for example, for set_bits).
This data is copied first from the buffer that the clist reader holds,
but if more data is required than the buffer actually has it,
bytes can be pulled direct from the stream itself.
Unfortunately, in this latter case, this sidesteps the debug code's
attempts to keep a correct record of the offset it has within the
file, meaning that it's hard to match reading and writing debug
prints up. We fix this here, by calling a function, with the pithy
name 'new adjust_offset_map_for_skipped_data'.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Not actually found by memory squeezing per-se, but found when running:
gpcl6 -dNOPAUSE -dBATCH -sDEVICE=ppmraw -dMaxBitmap=1000 -r300
-o gpcl6.out ../tests_private/pcl/pcl5cats/E*
in a 32bit windows memento build. We run out of memory at just the
right time to trigger a bad cleanup path.
|
| | |
|
| |
|
|
|
| |
Send the fill adjust value that should be used for a clip path
as part of the begin_clip operation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were unpacking the screen phase from the clist and inverting it.
This works in many cases because the most common use of this is with
the code that writes it setting it to the device color phase, which
is in the opposite sense.
Unfortunately, not ALL places that wrote it were writing it in this way,
causing differences with PCL, particularly where rop texture devices
are in use.
Accordingly, we remove the inversion on read, and invert it at the
appropriate place when writing.
This produces ~85 cluster diffs (all bar one in the pbmraw device),
where the clist rendering now matches the page mode rendering.
The sole exceptions to this is tests_private/xl/pcl6cet3.0/c421.bin
to pbmraw at 600dpi where clist and pagemode differ on page 17 in
a slightly odd way.
This is so much of a progression that I have committed these fixes and
will look into that file afterwards.
|
| |
|
|
|
|
|
| |
When rendering from the clist, we were maintaining a copy of the
screen_phase in a local variable in addition to the graphics
state. The local variable version was never actually used, so
remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we serialise colors into the clist, we want to include the
"phase" of colors with them where appropriate. During reading
the phase for such colors will need to be offset by the offset
of the screen.
If, for example, we are rendering for a band that starts at
(0, 1000) then the phase will need to be offset by 1000. Therefore
pass this offset to the color reading code, so we can adjust by
it.
|
| |
|
|
|
|
|
|
|
|
|
| |
The clist attempts to send both screen phase (derived from color)
and tile phase (for strip_copy_rop) etc using the same command.
Unfortunately, there are instances (for example, when using PCL
transparency) where we need to send both screen and tile phase
through, but with different values.
For correctness (and just as importantly, simplicity and sanity),
move to sending tile and screen phases through separately.
|
| |
|
|
| |
Tidy the code slightly, add some comments, and some sanity check code.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I find the clist debugging output unreadable (which may just be
my ignorance). Tweak it so that it appears in (what seems to me)
to be a more logical form.
|
| |
|
|
|
|
|
|
| |
Currently, they appear to be split over 2 headers for no good
reason that I can see (probably something historical).
A load of whitespace changes to align stuff nicely to make it
look less scary.
|
| |
|
|
|
|
| |
Fix (hopefully) the last few LGTM warnings. Suppress warnings for
those things that we can't avoid (use of goto in speed critical
state machines for example), and fix those we can.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PostScript 'sethalftone' has an optional parameter "ObjectType" that allows
one of the three object specific types to be set: Vector, Image or Text.
Also add a new PostScript operator to set the current halftone (dev_ht,
set by sethalftone) as the device halftone to be used for an object type:
path, image and text.
For non-PostScript clients, the gs_halftone structure adds a 'objtype'
element (enum) that can be set prior to calling gs_sethalftone.
The gs_gstate_s dev_ht is now an array of HT_OBJTYPE_COUNT elements,
indexed by the gs_HT_objtype_t enum, with HT_OBJTYPE_DEFAULT (value 0)
used for prior sethalftone/setscreen/setcolorscreen operations.
NOTE: adding object types beyond the default+3 entries will require modification
of gx_select_dev_ht since it only uses 3 bits of the 'tag' to get the index
for the dev_ht[] array.
For code style, change to use != NULL instead of != 0 in most places that
this commit touched (but we may want a general cleanup of this everywhere).
TBD: Command line options for all PDL's will need a method to take a
halftone specification -- most likely a file that may be "PS-lite" syntax
and may be limited to a threshold array. Discussions are in progress.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update create_compositor device method, so that it always returns
the compositor device (or the leaf device if there is no specific
compositor device). The device now returns 1 if we created a
compositor device to wrap the given device.
This should enable us to identify exactly the cases where forwarding
devices need to update which device they forward to.
In particular, this allows us to remove the horribly fragile code
in apply_create_compositor in gxclrast.c, and to ensure that we
correctly identify the 'new compositor' case.
This avoids us sending stuff to the wrong device, and having to
cope with a slew of warnings.
|
| |
|
|
|
| |
In these functions, for implementing state machines, gotos are
inevitable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where the colorspace was modified (read_set_color_space)
there was a memory leak.
This was because the old code just freed pcs, but if the color had
changed, then gs_state.color[0].color_space and [1].color_space are no
longer the same. This way we track the references to them separately
and free them separately.
pcs doesn't get its own ref, because it is always the same as
gs_gstate.color[0].color_space.
This fixes memory leaks that only show up in the case that the memory
is not garbage-collected, such as in pdfi.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the plane_begin_typed_image function used the gs_gstate_copy_temp,
but since this was allocated as a st_gs_gstate, and the reference counts
were not handled (as the comment describes), freeing that object would
decrement the ref_counts, causing premature free of objects.
Remove this dangerous function.
Change to use gs_gstate_copy so we have a proper gs_gstate structure.
Using gs_gstate_copy from a clist playback gstate requires that we have
client colors and device colors in the color[0] and color[1] elements.
Allocate, and initialize these, then free upon exit from clist_playback.
Also, the mem device underlying the plane_extract device needs to be
retained so that it is not prematurely freed.
|
| |
|
|
|
|
|
|
|
| |
Prevent memory leaks by propagating error codes and freeing loose objects.
Also resolve some compiler warnings.
Error created using :-
MEMENTO_FAILAT=19484 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5efts/fts.0051
|
| |
|
|
|
|
|
|
| |
The file for this bug does show that the stroke_color stack based struct
in not initialized. Init fill_color and stroke_color. This is probably a
bug tail from the fill_stroke commit.
Also explicitly set 'zeros' to 0 to clarify the expected contents.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes shape.alpha and opacity.alpha from the
graphic state. This involved removal of methods in the
postscript based PDF interpreter, changes in the pdf14 device,
changes in pdfwrite, the XPS interpreter, and the PS
transparency test file that is present in examples and on
the cluster. The goal of this commit was to avoid
confusion and conflicts between shape.alpha opacity.alpha and
the stroke and fill alpha values (CA ca). This change
resulted in progressions in the XPS file. There were changes
in a couple PDF files that required some investigation. In
particular, the change in the dashed lines of Bug694981.pdf. Robin
and I looked at this. Robin determined it was due to
differences in stroke_add and stroke_fill not giving identical results.
In the end, the new output looks closer the what AR provides.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Change to test for pgs->colours.pattern.p_tile to be NULL before
attempting to dereference it.
pdfi has a 'null' pattern frequently, which didn't seem to matter before the
fill/stroke changes, but does matter now.
I think the gs/pdf implementation sets up a specific "null" pattern
that gets around this issue, but currently pdfi does not do this.
Maybe it should?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When characters are filled as paths, the fill_adjust may be set to 0.
Clip paths are supposed to match fill paths, i.e. the 'any part of pixel'
rule, so we need fill_adjust of 0.5 (not 0). The most foolproof way to fix
this is to set it in the reader when processing 'begin_clip' and restore
it when handling the end_clip.
There are many progressions with this change, but it also exposes some
cases where the change in clipping allows other elements to be seen that
were previously hidden. Those few instances are minor and mostly seem to
occur when page mode differs from clist mode. Examination of some of those
cases shows that the clip path with clist mode now matches page mode and
other elements (e.g. images) differ in extent between page and clist mode.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Remove ppcs. When the code was changed to write the pgs->color[0],
the ppcs param was never removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This branch had several contributors including Robin Watts,
Ken Sharp and Ray Johnston.
The intent was to add a "fill and stroke" path device method
to ensure we get proper rendering when doing fill/stroke
methods with overprint and transparency. In addition,
adding the method made it possible for pdfwrite to match
the original pdf source file if it also had fill/stroke methods.
The interaction with overprint and transparency led to significant
changes in parts of the code related to those sections. In particular,
overprint was reworked to ensure that the overprint compositor and
the transparency compositor were aware if it was to be using
the overprint drawn_comps for stroke or for fill. The code was
rewritten so that the overprint compositor actions only occurred when
an actual operation occurred (e.g. fill, stroke, image, text) as opposed
to every time that the overprint graphic state values changed.
When there is a fill-stroke operation with transparency, depending upon the
graphic state values, a non-isolated knockout group may be pushed. From this,
an issue with knockout groups within knockout groups was revealed, which was
related to the backdrop selection. The backdrop selection code was simplified.
|
| |
|
|
|
|
|
|
|
| |
There are some elements of the (stack based) gs_gstate that were not being
set by either GS_STATE_INIT_VALUES_CLIST, or gs_gstate_initialize, so set
the entire structure to 0 before setting the values we care about. This
was prompted by a customer that has made modifications to the clist playback
that relied on gs_gstate.color[0/1].color_space being NULL or valid, but
since it is so quick and only happens once per band, go ahead and do it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
In preparation for upcoming clist changes for tiles, do some clean up of
the definitions and document unused command codes. Note that there are
still commands with flag bits where there are unused bits when certain
flags are set, e.g. copy_mono_planes, low 3 bits unused if copy_use_tile
is set, but using these code combinations would need changes in the
clist_playback_band reader.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The simplified case had a character (copy_mono) followed by a rect
fill.
The copy_mono for the character sets the rect.height clamped to the
"cropping_max" (dev->height) for the band in the writer, but it doesn't
actually write the height to the clist for that band. Then the reader
was using the entire bitmap height, but that went past the end of the
device, so the next time the state.rect.height was used in the reader,
it was wrong.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Add initializers for variables that confuse gcc. Also get rid of the
clist_reinit_output_file which was only needed for the RETRYING code
and the partial page rendering (this function had unused variable
warnings). THis should have been part of commit 7eda41b.
|
| |
|
|
|
|
|
|
|
| |
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.
|
