Bug 687196

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