Bug 693509 - Lines are missing in TIFF-output when -dBufferSpace is too large
Summary: Lines are missing in TIFF-output when -dBufferSpace is too large
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Printer Driver (show other bugs)
Version: 9.06
Hardware: All All
: P2 normal
Assignee: Ray Johnston
URL:
Keywords:
: 690036 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-19 14:37 UTC by artifex
Modified: 2013-06-25 19:48 UTC (History)
1 user (show)

See Also:
Customer: 870
Word Size: ---


Attachments
ISO-A0.pdf (322.49 KB, application/pdf)
2012-12-19 14:37 UTC, artifex
Details
ISO-A0c.pdf (9.36 KB, application/pdf)
2012-12-20 01:59 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description artifex 2012-12-19 14:37:43 UTC
Created attachment 9152 [details]
ISO-A0.pdf

When the attached PDF-file is converted to TIFF/G4 with following command:

gs -dNOPAUSE -dBATCH -r600 -sDEVICE=tiffg4 -o out.tif ISO_A0.pdf

the result is OK! If the option -dBufferSpace is defined with a large value, like

gs -dNOPAUSE -dBATCH -r600 -sDEVICE=tiffg4 -dBufferSpace=100000000 -o out.tif ISO_A0-pdf

the vertical dashed lines are missing!
The generated TIFF has 19862x28086 pixels, which needs about 69703516 bytes.
It seems, that when BufferSpace is greater than the requested size, the problem occurs.
Comment 1 Marcos H. Woehrmann 2012-12-20 01:59:53 UTC
Created attachment 9155 [details]
ISO-A0c.pdf

Simplified version of the original attachment.
Comment 2 Marcos H. Woehrmann 2012-12-20 02:02:45 UTC
You can see the difference in output using these command lines:

  bin/gs -sDEVICE=ppmraw -o test.ppm -r600 -dBufferSpace=50000000 ./ISO-A0c.pdf

and

  bin/gs -sDEVICE=ppmraw -o test.ppm -r600 -dBufferSpace=10000000 ./ISO-A0c.pdf

The former produces a completely blank page, the latter the expected dashed line.
Comment 3 Marcos H. Woehrmann 2012-12-20 02:03:55 UTC
Assigning to Ray since this appears to be a clist issue.
Comment 4 Ray Johnston 2012-12-20 08:03:20 UTC
I'm not sure how this is a clist issue since it WORKS when the clist is used.

For example:  -dMaxBitmap=10000 -dBandHeight=7000 produces output matching
Adobe and -Z: displays:
[:]width=5100, band_width=5100, band_height=7000, nbands=1
% Start time = 0.109, memory allocated = 2274440, used = 2051025
Processing pages 1 through 1.
Page 1
[:]width=2400, band_width=2400, band_height=7000, nbands=1
[:]width=2400, band_width=2400, band_height=7000, nbands=1
% Outputpage start time = 0.183, memory allocated = 2550408, used = 2366053

I'll look at it and see if I can see what's going on, and assign it to
whoever is more appropriate.
Comment 5 Ray Johnston 2013-06-03 16:51:28 UTC
This is an issue with clipping. Tracing with the debugger, the clip rectangle
with the clist has xmin=0x37a and xmax=0x37b. In page mode, the xmin=0x37a,
but the xmax=0x37a meaning that after clipping, we fill a rectangle of
0 width.

I'm looking at how the clipping box gets set now, and why it's different.
Comment 6 Ray Johnston 2013-06-03 20:16:30 UTC
*** Bug 690036 has been marked as a duplicate of this bug. ***
Comment 7 Ray Johnston 2013-06-03 20:17:20 UTC
WIth some paths, the fill_adjust was not being applied,.

Testing a change to always us it when clipping.
Comment 8 Ray Johnston 2013-06-05 15:51:19 UTC
Fixed by commit e0ba422 Fix clipping bugs 693509 and 690036.