DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37236>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37236 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-25 13:17 ------- (In reply to comment #3) > (In reply to comment #1) > <snip/> > > 2) Patterns that contain gradients generate 'bad' PDF. I suspect > > the problem is resource referencing. Since I am fairly sure the > > problem existed before my fidling I'm going to leave it as is. > > Do you have a test case to reproduce this? Yes, sorry this was generated by: http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/samples/tests/spec/paints/patternRegions.svg Most of the document converts correctly but the last test seems to generate a PDF error. I took a quick look at it but it basically looked believable to me... > > A few notes on the patch. > > 1) I simplified the PDFState.Data class, by removing the > > the 'concatenations' List. It doesn't seem to be used > > by anything. > > You're wrong. It is used by the PDF Renderer to handle "fixed" positioned > block-containers. This can't just be removed. The concatenate() method > even has a proper javadoc comment that explains the purpose. Sorry about that. It's a bit odd I thought was careful to delete all class files after this change to ensure that I hadn't missed anything, and everything still compiled (of course it doesn't now). Anyway if this is needed it can stay, the real problem code was the way that 'PDFState.getTransform' was coded which was definately producing wrong results (transforms applied twice, see below). > > 2) I changed PDFState.getTransform it now just returns the > > current transform as this already includes all the previous > > transforms. Perhaps I misunderstood the code but things work > > now and the transforms make sense where as they didn't before. > > As you can see in my comment for 1) this can't be the solution. This part of the change is essentially independent from the first point. > If you can give be the test cases that are involved here I can try > to help. You would hit this problem with any SVG file (try linearGradientOrientation.svg in the same directory as above). The way I detected it was by tracking what is handed to 'PDFState.setTransform' and what is returned by 'PDFState.getTransform'. The value returned by getTransform has the transform applied twice. The reason is pretty clear when you clone the Data object for a push you don't clear the transform of the new Data object (you did clear the concatenations list), thus you end up with two Data objects both of which have what ever the transform was. Then the old getTransform code would then concatenate both of these resulting in a double transform. I think only the gradient code uses the transform returned by this method, so for most content the bug wouldn't show up. There are two potential solutions, first clear the transform when you clone the Data object, but leave the concatenation code in getTransform. Second have getTransform just return the current Data.transform (as I did, but leave the concatenations List stuff alone). If you do the first I suspect the code in PDFRenderer could just use the transform from the Data object to restore state, and the concatenations list could go away, but I don't really know or understand the code in question - I'll just say that the current system appears way more complex then it needs to be, you should be able to accomplish everything with the existing push/pop on PDFState. Finally, doesn't it bother you to have one class getting an iterator from a raw member of an inner class belonging to another class? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
