When trying to convert the attached PostScript document into PDF with GS Head (i also tried it with gs 8.34 / 8.14 - same error) i get a PDF document that displays "Wrong operand type" error when i'm trying to open it in Acrobat Reader. Adobe Distiller converts this document into a fine PDF.
Created attachment 1167 [details] PostScript file (zipped with winzip)
Created attachment 1168 [details] PDF file created with gs 8.34
Confirmed in CVS HEAD and GS 8.50
The PDF file contains the following: q 0 2 0 0 0 0 cm -92559631349317831000000000000000000000000000000000000000000000.0 -92559631349317831000000000000000000000000000000000000000000000.0 m -92559631349317831000000000000000000000000000000000000000000000.0 -92559631349317831000000000000000000000000000000000000000000000.0 l S Q
*** Bug 688242 has been marked as a duplicate of this bug. ***
1. I do not see "00000000000000000000000000000000000000000" in the attached PDF - neither in the original file, nor in an unpacked copy made with pdfinflt. Not clear what document Alex used. 2. Acrobat Reader 4 opens the attached document with no error. 3. Acrobat Reader 5 and and Adobe reader 6 opens the attached document with the "Wrong operand tipe" message. 4. The problem (3) is reproducible with the current HEAD.
After I replaced all occurances of "0 2 0 0 0 0 cm" with "0 2 2 0 0 0 cm", the file opens with no error with Adobe Reader 6 and Acrobat Reader 5.
Well, I know where Alex took huge numbers. The function gdev_vector_dopath_segment calls gs_point_transform_inverse without checking the return code, but with sample document it returns the undefinedresult error code, and leaves the result point argument uninitialized. With my build it happens to be zero, but Alex uses a different compiler.
The reason of the problem is that the sample document first constricts a path, and then sets a generate CTM and strokes with the degenerate CTM. The function gdev_vector_dopath_segment doesn't priopagate the error code and leaves an uninitialised variable, therefore Alex's hguge number may appear indeterministically. gdev_vector_dopath applies the inverse matrix to provide a right stroking if the CTM is set BEFORE constructing the path. However a mathematically corect result isn't possible when CTM doean't change after the path is constructed. Need to know whether PDF allows to change it between constructing a path and stroking. If so, the logic of gdev_pdf_stroke_path to be changed dramatically.
Some quotes from PDF 1.4 page 152 : "The effect produced in device space depends on the current transformation matrix (CTM)in effect at the time the path is stroked.If the CTM speci fies scaling by different factors in the horizontal and vertical dimensions,the thickness of stroked lines in device space will vary according to their orientation." Page 163 : "Table 4.9 shows the path construction operators.All operands are numbers de-noting coordinates in user space." Page 162 : "In PDF (unlike PostScript),the current path is not part of the graphics state and is not saved and restored along with the other graphics state parameters." However we're unclear what coordinate system does the PDF viewer must use for storing the clipping path : the device space or the user space ? What is the defined result if CTM changes between path construction and stroking ?
Created attachment 1645 [details] cur-.pdf A mannualy made PDF with changing the CTM between path construction and stroking.
Created attachment 1646 [details] cur.pdf A PDF file with setting the CTM before path construction, generated with current HEAD.
Acrobat Reader 4, Acrobat Reader 5, Adobe Reader 6 all render same page with cur-.pdf and cur.pdf ! Thus I conclude that Adobe stores the path in the user space coordinates, and applies the CTM in the time of stroking. Contrary Ghostscript applies one CTM in the time of path construction, and another CTM in the time of stroking.
Thus, the paragraph2 of Comment#9 and Comment #13 imply that the sample document is mathematically impossible to convert precisely into PDF.
Created attachment 1647 [details] t1.ps A Postscript file for testing what Adobe does with anisotropic line width. Both CPSI and Distiller+Reader paint an constant width line with this test. Ghostscript with a raster device renders a zero width line, which looks incompatible to Adobe.
Well, after some experimenting with Distiller+Reader, we think that : 1. Distiller stores the path is device space coordinates, as a regular Postscript interpreter. 2. If the stroking happens with an anisotropic CTM, the anisotropic width appear with Distiller+Reader, except the CTM is degenerate. The distiller writes an anisotropic matrix and then inverse-transforms the path with it. It appears same as Ghostscript does. 3. If the stroking happens with an anisotropic degenerate CTM, Distiller+Reader paints a constant line, and uses the non-zero matrix coefficient to compute the line width. Ghostscript must do same, but currently gives an undeterministic behavior and the "Wrong operand type" error.
Patches to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-August/005655.html http://ghostscript.com/pipermail/gs-cvs/2005-August/005656.html