Bug 690356

Summary: Different results with -Z@ flag
Product: Ghostscript Reporter: Alex Cherepanov <alex>
Component: GeneralAssignee: Alex Cherepanov <alex>
Status: RESOLVED DUPLICATE    
Severity: normal CC: chris.liddell
Priority: P4    
Version: master   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: easy2-unc.pdf

Description Alex Cherepanov 2009-03-24 21:45:15 UTC 
Many files render differently or generate PDF that renders differently
with -Z@ flag.

pdfwrite only: 
   473-01.ps, Altona.Page_3.2002-09-27.pdf, Altona_Technical_1v1_x3.pdf,
   Bug689083.pdf, Bug689362.pdf, Bug689815.pdf, Bug689918.pdf, Bug690237.pdf,
   Bug690243.pdf, S2_Digitalproof-Forum_x3k.pdf, adesso2.pdf, 
   altona_technical_1v2_x3.pdf, brochurep1.pdf, korea.ps, messenger.pdf,
   messenger16.pdf, mspro.pdf, ngnews1.pdf

Any raster device or pdfwrite:
   Bug689492.pdf, BCL_easy.pdf  

The bug seems to be easier to reproduce on 32-bit Linux.
Comment 1 Ken Sharp 2009-03-25 07:09:57 UTC 
For whatever it may be worth, I can reproduce this on Windows in a debug build
using BCL_Easy.pdf. In fact I've cut it down to just a pair of images.

Both images are in a /Indexed /DeviceRGB colour space (but actually only two
gray values), but when we emit the colour space for the second image (using
-Z@), the lookup table contains incorrect data.

I don't know if this is the case for the other named problem files, but I do
note that they are all PDF files, which may simply be coincidence.
Comment 2 Ken Sharp 2009-03-25 08:26:36 UTC 
Created attachment 4865 [details]
easy2-unc.pdf

Attached is a radically reduced version of BCL_Easy.pdf. All but the first page
removed, and all the content from the first page, bar two small images,
removed.

Note that these two images are the *same* image rendered twice (ie there is
only one instance of the image and its colour space in the PDF file).

On the second call to setcolorspace the lookup string is incorrect (I set a
breakpoint in setindexedspace in zcolor.c).

I then altered pdf_ops.ps, /setgcolorspace:

/setgcolorspace {	% <colorspace> setgcolorspace -
  dup pdfcolorspace currentcolorspace pdfcolorspace eq {
    pop
  } {
dup ==
    setcolorspace
  } ifelse
} bdef

Which simply dumps the color space array. Again the (string) lookup table was
incorrect on the second execution.

At this point, I'm passing this one up, maybe Alex could take a look ? I'm sure
he can work his way through the PDF interpreter faster than me.
Comment 3 Alex Cherepanov 2009-03-26 06:19:10 UTC 
This is not a PDF interpreter problem. The graphic state is freed
by the reference counting and frees the string that contains the
index table. Probably, the string should be garbage-collected but I'm
still looking into this issue.
Comment 4 Ray Johnston 2009-03-26 10:00:24 UTC 
Assigning to Ralph as a memory issue.
Comment 5 Hin-Tak Leung 2010-05-04 23:45:17 UTC 
Assign back to Alex who was the reporter and seems to have some clues as well.
Comment 6 Chris Liddell (chrisl) 2010-05-11 17:26:27 UTC 

*** This bug has been marked as a duplicate of bug 690832 ***