summaryrefslogtreecommitdiff
path: root/base/gdevmpla.c
diff options
context:
space:
mode:
authorRay Johnston <ray.johnston@artifex.com>2021-05-09 06:56:22 -0700
committerRay Johnston <ray.johnston@artifex.com>2021-08-22 16:34:33 -0700
commit2e66582c527646015731cd0f4a0fb2e2d1559887 (patch)
tree2bc0c98d80a4586584776ec719511e9ea862dcd7 /base/gdevmpla.c
parentb36656f76191565786180dc9bd4a11a49e046a32 (diff)
downloadghostpdl-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.c3
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);