diff options
author | Ray Johnston <ray.johnston@artifex.com> | 2021-05-09 06:56:22 -0700 |
---|---|---|
committer | Ray Johnston <ray.johnston@artifex.com> | 2021-08-22 16:34:33 -0700 |
commit | 2e66582c527646015731cd0f4a0fb2e2d1559887 (patch) | |
tree | 2bc0c98d80a4586584776ec719511e9ea862dcd7 /base/gdevmpla.c | |
parent | b36656f76191565786180dc9bd4a11a49e046a32 (diff) | |
download | ghostpdl-2e66582c527646015731cd0f4a0fb2e2d1559887.tar.gz |
Bug697978: Replace tiffsep1 to support object type specific halftoning.
The previous implementation rendered contone (as tiffsep does) then
used threshold array based halftoning on the entire image, which used
more memory (or a greater number of bands).
This version renders to 1-bit planes which allows object type specific
halftones to be supported as well as allowing PDF or PS to change
halftones any number of times on a page, as is allowed for by the
language (although defined as "implementation dependent").
This version is much more useful as a RIP for generating plates and
fixes some problems raised by customer 162.
Also add a #define PPM_COMBINED_OUTPUT to allow comparison to pkmraw output
(disabled by default).
Development discovered several places that assumed that DeviceN devices
would be 8 or more bits per component, and gdev_mem_set_planar_interleaved
planar setup needs to avoid using the mem_planar_put_image proc.
NB: Transparency is necessarily performed in contone buffers, so any
object type specific halftone is lost -- the transparency page will be
halftoned during 'put_image' using the default halftone in effect when
the put_image occurs. Thus, changing the halftone while constructing
the page only works for pages without transparency.
A future enhancement would be to use the tags when the page uses
transparency, then use those tags in a custom "put_image" procedure
(the normal default 'put_image' method that creates a typed image
does not deal with the tags plane.
Possible enhancements for performance optimization are:
1. Implement alternative halftone color routines for planar devices so
we don't need to construct chunky multi-component (e.g. CMYK) tiles,
only to then extract and pack the bits from the tile for writing
the planes.
2. Implement a mem_planar_put_image for halftoned devices that uses
the optimized threshold based method similar to the monochrome
image code (which uses CAL if available).
Diffstat (limited to 'base/gdevmpla.c')
-rw-r--r-- | base/gdevmpla.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/base/gdevmpla.c b/base/gdevmpla.c index 28c609d8e..632610d37 100644 --- a/base/gdevmpla.c +++ b/base/gdevmpla.c @@ -148,7 +148,8 @@ gdev_mem_set_planar_interleaved(gx_device_memory * mdev, int num_planes, four planes then use the high level color filling procedure. Also make use of the put_image operation to go from the pdf14 device directly to the planar buffer. */ - if (num_planes >= 4) { + /* Note this is only valid for contone (8 or more bits per component) */ + if (num_planes >= 4 && mdev->color_info.depth/num_planes >= 8) { set_dev_proc(mdev, put_image, mem_planar_put_image); } set_dev_proc(mdev, fill_rectangle, mem_planar_fill_rectangle); |