summaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorRobin Watts <Robin.Watts@artifex.com>2021-06-30 11:23:31 +0100
committerRobin Watts <Robin.Watts@artifex.com>2021-07-01 00:27:56 +0100
commit2f7f448a4b73b8f996fa9196527da1db5cc520e2 (patch)
tree5e996d8e57f907800de3cf64b0bf07336a6bd09f /contrib
parenta8671762033fa55823068fbb208983f7435b70d6 (diff)
downloadghostpdl-2f7f448a4b73b8f996fa9196527da1db5cc520e2.tar.gz
Add gx_blank_get_bits_rectangle.
High level devices do not generally keep a rendered bitmap version of the page. As such they cannot honour get_bits_rectangle requests. This causes certain rendering operations to fail; notably those that involve ROPs that involve 'D'. This can cause runs to error out prematurely. For instance, a 72dpi page mode PCL run of j9_acrobat.pcl to the lips4v device dies with an error. Accordingly, we add a gx_blank_get_bits_rectangle routine that returns 'empty' rectangles, and we make lips4v use that. This gives imperfect renderings (in the same way that pdfwriting files that use ROPs gives imperfect renderings), but we do at least get a rendering out at the end. In testing this, I found a suspect spot in lips4v where valgrind spots us operating on uninitialised data. Patch around that to init it to 0 to quell valgrind.
Diffstat (limited to 'contrib')
-rw-r--r--contrib/lips4/gdevl4v.c13
1 files changed, 13 insertions, 0 deletions
diff --git a/contrib/lips4/gdevl4v.c b/contrib/lips4/gdevl4v.c
index 5cba57119..1cdc17c41 100644
--- a/contrib/lips4/gdevl4v.c
+++ b/contrib/lips4/gdevl4v.c
@@ -179,6 +179,7 @@ lips4v_initialize_device_procs(gx_device *dev)
set_dev_proc(dev, fill_parallelogram, gdev_vector_fill_parallelogram);
set_dev_proc(dev, fill_triangle, gdev_vector_fill_triangle);
set_dev_proc(dev, begin_typed_image, lips4v_begin_typed_image);
+ set_dev_proc(dev, get_bits_rectangle, gx_blank_get_bits_rectangle);
}
gx_device_lips4v far_data gs_lips4v_device = {
@@ -2090,6 +2091,18 @@ lips4v_fill_mask(gx_device * dev,
byte *buf = gs_alloc_bytes(vdev->memory, num_bytes,
"lips4v_fill_mask(buf)");
+ /* This code seems suspect to me; we allocate a buffer
+ * rounding each line up to a multiple of 4, and then
+ * fill it without reference to this rounding. I suspect
+ * that each line should be padded, rather than all the
+ * data being crammed at the start, but I can't make that
+ * change in the absence of any way to test this. I will
+ * make do by adding the memset here so that any untouched
+ * bytes are at least consistently set to 0 to avoid
+ * indeterminisms (and valgrind errors). RJW */
+ if (width_bytes * h < num_bytes) {
+ memset(buf + width_bytes * h, 0, num_bytes - width_bytes * h);
+ }
for (i = 0; i < h; ++i) {
memcpy(buf + i * width_bytes, data + (data_x >> 3) + i * raster,
width_bytes);