In bug 687192, a user reports that there are problems with an old version of GS, pdfwrite and shadings. Jack closed that bug since all files were being processed. However one file produces and incorrect result. The test file involves shading patterns being applied to text. command line: ps2pdf.bat pattyp1.ps pattyp1.pdf
Created attachment 400 [details] Adobe test file pattyp1.ps
Created attachment 421 [details] A simplified test pattyp1-.ps
The patch http://www.ghostscript.com/pipermail/gs-cvs/2003-December/003925.html fixes the PDF format problem. However the generated PDF still has a wrong pattern matrix. The reason appears somewhere before passing data to pdfwrite, because GS wrongly renders pattyp1-.ps to display device. A correct view may be obtained with Acrobat(Distiller(pattyp1-.ps)). Assigning the bug to Dan for fixing that. Maybe I'll need to do something in pdfwrite after that. Dan, if you disagree with this assignment, please bring it to a support meeting.
Created attachment 738 [details] A raster from Adobe CPSI
Confirm discrepancy between GS rendering of PS file and CPSI's. Fixing that problem _may_ fix pdfwrite behavior, but it should be tested once the PS interpreter is fixed. I see a discrepancy between gs's rendering of original ps and gs's rendering of pdfwrite output, but Dan didn't when he tested, so there may be some indeterminacy.
This didn't originate as a customer bug, so priority should be P3 or less
Created attachment 3246 [details] PNG showing results of pattyp1-.ps->Distiller->AR This attachment shows the results of running the file pattyp1-.ps through Distiller 8 and reading the resulting PDF with AR7.0.8
Created attachment 3247 [details] png shows the current results of running pattyp1-.ps to the x11 device Results looks similar to Distiller->AR, but are noticeably different.
Created attachment 3248 [details] png shows the results of running pattyp1-.ps to the pdfwrite device gs -sDEVICE=pdfwrite -sOutputFile=687196.pdf pattyp1-.ps Significant difference is seen here. While the x11 output looks reasonable, the gradients in the pdfwrite case are no where close to what is expected. The gradients almost completely drop out.
As it wasn't 100% clear to me what to expect based upon the earlier descriptions, I updated the record with the 3 png attachments above to make it clear what the current state of this bug is at this point in time (as of r8158).
Reassigning to current "owner" NB, The problem is still present with rev 8468 and also note that the X11 output shown have the pattern at the wrong angle.
I see that the 'P' and 'S' results are incorrect when rendering under Windows using the current HEAD. I will look into the pdfwrite problem, but this is unlikely to affect the incorrect rendering, these look to be different problems to me.
The issue with pdfwrite is because the shading dictionary (type 2 pattern) is contained within a type 1 pattern. Normally we need to 'normalise' the matrix for both type 1 and type 2 patterns to the *default* user space and not to the user space currently in force. However, in the case of a pattern within a pattern (which is only possible when the second pattern is a shading dictionary), we need to normalise the matrix to the pattern space. In fact this means we need do nothing; at present we do the renormalisation resulting in the shadings being 1/10th the correct size. There doesn't seem to be any way to know at present that a shading dictionary is running in the context of a pattern. I have a simple enough solution involving adding a flag to the device structure to track type 1 pattern accumulation. This works (still testing, and want Leonardo's opinion), but as expected has no effect on the rendering problems I see with GS. Intriguingly the PDF files produced by Distiller and now by pdfwrite both render correctly! Rendering issues aren't my field, (though I'm intrigued that the PDF files work ;-), I should probably open a new issue for these, assign to Alex or someone else ?
The simplified test pattyp1-.ps clearly demonstrates a pattern rendering problem with raster devices, so we need to fix the graphics library first. pdfwrite improvements must be delayed after than. I will change the bug title and assign it to the owher of patterns. The old title is "Incorrect PDF produced from Adobe test file pattyp1.ps". After fixing the graphiocs library the bug should be passed back to pdfwrite owher. Ken please attach your test files to here.
Created attachment 3723 [details] Series of test files for type 1 patterns, including nested and rotated. As requested, a Zip archive with a series of test files. As far as I know these do work correctly when rendered, though I haven't been testing them that way. However, as requested by Leonardo, all the files. I have some others, patterns inside forms, patterns using images, and so on. These are not as well named or comprehensive as the ones in this archive. If anyone wants these as well, let me know.
Running -Ts -r144 pattyp1-.ps I see the shading matrix is good but the clipping is incorrect (rectangular). gs_vdtrace.ini content for this test is : [VDTRACE] OrigX=-10000 OrigY=-10000 ScaleX=1000 ScaleY=1000 ShiftX=0 ShiftY=0
According to PLRM the pattern BBox is used to clip the pattern cell. With a skewed or rotated matrix it maps to a device area, which is not a canonic rectangle. Soi it needs to set up an untrivial clipping in pattern_paint_prepare. Ghostscript does not implement it yet. I'll try to make a patch.
Created attachment 3727 [details] patch.txt A patch for raster devices.
Created attachment 3728 [details] patch.txt Patch for vectore devices. To be applied after the patch for vector devices.
Patches to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-January/008083.html http://ghostscript.com/pipermail/gs-cvs/2008-January/008084.html