Bug 688247 - problem writing CMYK pdf with -sDEVICE=bmpsep8 on amd64
Summary: problem writing CMYK pdf with -sDEVICE=bmpsep8 on amd64
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Other Driver (show other bugs)
Version: 8.51
Hardware: PC Linux
: P3 normal
Assignee: Stefan Kemper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-28 08:45 UTC by Michael Glauche
Modified: 2008-12-19 08:31 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
dna.tar.bz2 -- local copy of the sample files (1.97 MB, application/octet-stream)
2005-07-28 10:15 UTC, Alex Cherepanov
Details
patch (822 bytes, patch)
2005-07-29 11:58 UTC, Alex Cherepanov
Details | Diff
improved path (1.74 KB, patch)
2005-08-02 06:24 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Glauche 2005-07-28 08:45:45 UTC
Hi,
  i found a strange bug in gs 8.51, which seems to be related to the 64bit
version of gs. 

reproduce: 
gs  -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0
"-sDEVICE=bmpsep8" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-g513x703" "-r72x72"
"-sOutputFile=dna.bmp" "-fdna.pdf"

source file: http://www.connection-net.de/tmp/magick/dna.pdf
result: http://www.connection-net.de/tmp/magick/dna.bmp

I checked with a 32bit version of gs and it worked perfectly fine. However gs
8.15 and 8.51 on 64bit produce the result posted as the .png (the .bmp is the same)
Comment 1 Dan Coby 2005-07-28 10:10:21 UTC
Not surprsing since the problem appears on a 64 bit machine and not on 32 bit 
machines, the problem is related to the size of an integer.

The problem appears to be in bmp_cmyk_print_page in gdevbmp.c and 
write_bmp_separated_header in gdevbmpc.c.  According to the comments in 
gdevbmp.c, BMP files have each pixel rounded up to 32 bits.  For the bmpsep8 
device, pixels are 8 bits and the line width is 513 pixels.  So each line in 
the bmp file should be 516 bytes.  However in the bmp file from the problem 
report, raster lines appear to be 520 bytes.  This is consistent with rounding 
up to 64 bits instead of 32 bits.  The problem area seems to be the assumption 
that the bitmap_raster macro is only rounding the size of a raster line up to 
a byte boundary.  Instead this macro is rounding up to either 32 or 64 bits 
(based upon the machine).  The routines bmp_cmyk_print_page and 
write_bmp_separated_header then do their own rounding of the raster line size 
up to a 32 bit boundary.

I do not have a 64 bit machine so I cannot verify a fix.  It is probably 
simple. 
Comment 2 Alex Cherepanov 2005-07-28 10:15:12 UTC
Created attachment 1584 [details]
dna.tar.bz2  --  local copy of the sample files
Comment 3 Alex Cherepanov 2005-07-29 11:58:56 UTC
Created attachment 1587 [details]
patch

Fix calculation of the row width on 64-bit platforms. Remove bitmap_raster()
macro, because Windows bitmap is not affected by the source platform alignment
constrains.
Comment 4 Michael Glauche 2005-07-30 05:03:12 UTC
that patch worked flawlessly, my test-pictures come out correctly now, thank you
very much !
Comment 5 Dan Coby 2005-07-31 17:19:59 UTC
Alex,

Looking at your patch, you only changed bmp_cmyk_print.  I would assume that a 
similar change also needs to be made to write_bmp_separated_header.  Otherwise 
I think that the header data will be inconsistent.
Comment 6 Alex Cherepanov 2005-08-02 06:24:37 UTC
Created attachment 1592 [details]
improved path

Fix calculation of the row width on 64-bit platforms. Remove bitmap_raster()
macro, because Windows bitmap is not affected by the source platform alignment
constrains. Initialize padding bytes to 0.

The files generated on Alpha and x86 are now identical.
Comment 7 Alex Cherepanov 2005-08-04 10:40:38 UTC
The patch is committed to Head branch.