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.
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.
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.
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.
Assigning to Ralph as a memory issue.
Assign back to Alex who was the reporter and seems to have some clues as well.
*** This bug has been marked as a duplicate of bug 690832 ***