| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When a high level image is written into the clist, values that are in the
image settings that are different that the clist device settings
are copied and a flag is set to indicate that those values need to be
written to the clist with the writing of the unknown command (cmd_write_unknown).
A problem is that the test for the change in the color space in the image
code did not test if the ICC profile
was different than the one stored in the clist device. And if the color
spaces were different, the ICC information was not getting updated.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the PS and PDF world, images can either be imagemasks (in which
case they are filled in the current gstate color), or they can
supply different colors per pixel.
Accordingly, if an image uses the current gstate color, the clist
must write the halftone phase if the color might need it. If an image
does not use the current gstate color, then the halftone phase should
be written (because we can't tell whether all the colors are pure or
not in advance). The current code copes with this just fine.
Unfortunately, in the PCL world, we can be in the unholy situation
where an image can use the current gstate color AND it can use
colors information from the image. Thus we need to send the phase
both in the case where the current gstate color might need it and
when the image is not a masked one.
|
| |
|
|
|
|
| |
If the target device is a contone device there is no
need to write and read halftone data into and out of
the clist.
|
| |
|
|
|
|
|
|
| |
When sending a monochromatic image to the clist, we end up using
whatever tile phase was set rather than the more correct (0,0).
The fix is to reset back to (0,0) if we are not using color. This
causes 3 diffs in testing, all now match page mode rendering.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than writing 'extend' and then poking the appropriate
extended op into the second byte of the block, use some friendly
functions to both allocate a command block for the extended
op and fill in both 'extend' and the 'op' in question.
Also move away from a few macros to static inline functions.
Should be just as fast on any non-archaic compiler, and has the
advantage of being both more readable and debuggable.
Possibly we could move to making the standard set_cmd_put_op
stuff automatically handle extended stuff by bumping all the
extended values up by 0x100. Ponder this for the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Stupid fuzzing file uses a Type 3 font with a sampled image in the glyph
proc. The image uses a procedure as a data source. The glyph proc does
gsave, and the image data source procedure does a grestore. So by the time we
clean up the image "samples", the gstate and the clip path it contains have
gone. So the image enumerator's reference to the clip path is left dangling.
Copying, rather than referencing, that clip path solves the crash.
Fixes oss-fuzz issue: 26987
|
| |
|
|
|
|
|
|
|
| |
The pdf14 compositor changes the color depth to 8 for a SMask, but the
compositor actions were not being put in all the bands needed. In this
case the copy_color_alpha was output from the interpolation logic because
the image gridfitting expanded the image. Fix it by expanding the top and
bottom limits for the "temp_cropping" which controls the RECT loop writing
the compositor info to the bands.
|
| |
|
|
|
|
| |
In this case "remap_color" is gx_concretize_ICC() and the link profile
creation fails. Previously we were ignoring the error, and trying to use the
resulting (invalid) color space.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The SMask 'swap' of profiles for the 'default' colorspaces in the icc_manager
was not being detected by the clist logic since the colorspace id was still
set to the cs_Device*_id value (1, 3, or 4).
The fix is to have the clist writing check for unknown color_space check BOTH
the color_space.id and the color_space.space, and flag 'unknown' if either
differed. The color_space.space includes the icc_profile info.
This results in a few progressions as well as fixing the file of this bug.
|
| |
|
|
|
|
| |
The gxclimag.c code, when it does 'cmd_put_drawing_color' was not updating
the tile_phase. The Kanji text set the tile_phase to 100, but the begin_image
was supposed to be 0,0 but the writer was not performing the set_tile_phase.
|
| |
|
|
|
|
|
|
| |
The code in gxipixel.c skips gridfitting if fill_adjust is 0, but the clist
writer logic wasn't updating the fill_adjust, so the reader could have the
wrong value. Seen with fts_25_2505 and fts_25_2506 which have an image with
SMask and also have large text (non-cached, so painted with fill) preceding
(drawn under) the image. Text is drawn with fill_adjust 0.
|
| |
|
|
|
|
|
|
|
|
| |
The clist_image_plane_data function was called with the dev_color for a band
being type <pattern> when the image had type <pure>, but the code was not
calling cmd_put_drawing_color to update the bands for the image because uses_color
was false. Add rop3_uses_S(pgs0>log_op) as well as (||) rop3_uses_T(pgs->log_op)
when CombineWitColor is true.
Note that extra calls to cmd_put_drawing_color before an image are low cost
and do nothing if the current device color is already the same.
|
| |
|
|
|
|
|
| |
As described in the bug, the patch to disable high-level images in
pattern-clists when Interpolate is true is no longer needed (hasn't
been since 2015), and it causes the memory and performance problems
with this type of file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Otherwise it's hard for someone unfamiliar with the macros to see
what is going on.
|
| |
|
|
|
|
| |
11-14.PS trips some valgrind warnings where we
write structures into the clist without having
cleared the padding in the structures.
|
| |
|
|
|
|
|
|
|
|
|
| |
Even though the commit fixed bug 695280, we noticed that it caused PS
and PDF clist image logic to sometimes take the slow "default" handling
instead of the high-level image path.
To restore the fix for PCL, we could remove the rop3_uses_T altogether,
but we don't know if this will impact PCL performance.
Re-opening bug 695280.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The clist mode "uses_color" was ignoring CombineWithColor if the rop
did not use the texture (rop3_uses_T false). This affects the ps3cet
09-40.PS and pcl5ccet/23-11.BIN files.
Note that this reults in these cases not using high-level images
in the clist since currently the clist cannot accomodate the two
different colorspaces (painting an Indexed colorspace image through
a pattern). Since the number of changed file is minimal, I assume
that the performance impact does not affect many files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the zbegintransparencymaskgroup with a '/None' SMask parameter with the clist
in use, we get to clist_create_compositor().
In there, the return value of the get_cropping method can be either an error
(negative) or a specific cropping operation (positive). We assign it to 'code',
and if it's an error, return it, if not, assign it to another variable. But
don't set 'code' to anything else. It is then possible to get to the end of the
function without going through the path where 'code' is used again.
Setting 'code' to 0 after storing the cropping op solves the problem.
|
| |
|
|
|
|
|
|
| |
The entire concept relies on recovery by being able to store an entire
page raster image somewhere when the clist writing gets a VMerror, but
if we have room for a page, we could have used page mode in the first
place and totally avoid clist complexity VMerrors. Rip this code out
to make the clist more readable and maintainable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Tweak the code to avoid the warnings seen in the MSVC debug build of
gs.
Mostly adding a few casts to make type changes explicit (and hence
avoid the "casting from int to double might lose data" etc warnings).
Reorder the headers in a couple of places to avoid offsetof being
redefined in a system header warnings.
|
| |
|
|
|
|
|
|
|
| |
Various bits of the ICC code collects return values only to not
check them. Fix that here.
In some cases this is because functions have a 'void' return type
so there isn't a way to return an error. Change those return types
and ensure that all callers check and propogate the errors.
|
| | |
|
|
|
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.
|
