Created attachment 11079 [details] PDF file When converting the attached PDF into PDF / TIFF / PNG with GS head the output file looks wrong. I get the same problem with older GS versions. Also tried building GS with luratech jpeg2000 engine - same problem.
Other PDF readers (mupdf, Apple Preview, Adobe Acrobat) open the file correctly.
Did you check Ghostscript "commercial build" with Luratech decoder?
oops. Please disregard last comment. I hadn't read carefully :-(
Copying Ken as the file appears to have font problems as well.
(In reply to Henry Stiles from comment #4) > Copying Ken as the file appears to have font problems as well. How can you tell ? All I see is a mess..... If I remove the image from the content stream then I get a blank page in both Acrobat and Ghostscript. What are you seeing Henry ? And surely if its fonts then it should be Chris that gets copied ?
On inspecting the page content stream, it appears that the majority (possibly *all*) the text is drawn with Text rendering mode 3 (neither stroke nor fill). This is usually done so that an image can be 'searched'. Ghostscript doesn't do anything with Tr mode 3 so I'm at a loss to see what the problem could be.
Some progress here: the reading part of the filter is correct, it is set up to read the correct amount of data, the graphics library image is set up wrong. The image uses bits per component from the image dictionary which isn't right according to specification. So the input tries to read 8 bpc data and it is written to an image that expect 4 bpc, and the image signals all done 1/2 way through the data as expected. I'm surprised this is broken, at least I'd expect both input and output to be wrong.
commit db7668753ca114aabc4d34063876732dc043e9b8 fixes this for me. Strangely it causes some of the cluster machines to throw seg faults or errors when processing a particular EPS file (Bug688845.eps) which cannot possibly be affected by this change. I'm also unable to reproduce a problem locally either on Windows or Linux.....
I'm reassigning this one to Marcos for now, in the hope that he can identify some means to reproduce the seg fault caused by this commit.
(In reply to Ken Sharp from comment #8) > commit db7668753ca114aabc4d34063876732dc043e9b8 fixes this for me. > > Strangely it causes some of the cluster machines to throw seg faults or > errors when processing a particular EPS file (Bug688845.eps) which cannot > possibly be affected by this change. I'm also unable to reproduce a problem > locally either on Windows or Linux..... I don't believe the seg faults in the regression tests with Bug688845.eps are related to this commit either; I see seg faults in the regression logs starting in May. If I can reproduce the seg faults reliably or find a valgrind error I'll open a separate bug.
(In reply to Marcos H. Woehrmann from comment #10) > (In reply to Ken Sharp from comment #8) > > commit db7668753ca114aabc4d34063876732dc043e9b8 fixes this for me. > > > > Strangely it causes some of the cluster machines to throw seg faults or > > errors when processing a particular EPS file (Bug688845.eps) which cannot > > possibly be affected by this change. I'm also unable to reproduce a problem > > locally either on Windows or Linux..... > > I don't believe the seg faults in the regression tests with Bug688845.eps > are related to this commit either; I see seg faults in the regression logs > starting in May. > > If I can reproduce the seg faults reliably or find a valgrind error I'll > open a separate bug. Turns out there already is an open bug: Bug 694549