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:59 ------- (In reply to comment #5) <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... Thanks, I'll look into it ASAP. > > > 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). I see. That sounds bad. > > > 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? Well, it bothers me to have public member variables in the first place. I simply haven't enough of an itch to fix it, yet. That stuff evolved over time. When I recently updated the PS renderer I took a cleaner approach to handle state information. Maybe that could be ported to the PDF case. Still, the transformation list is still necessary to recreate the same state after a "break out" as needed when painting fixed block-containers. I haven't found a better way to handle this case, yet. Essentially, you're welcome to rework this stuff if you find a better way, as long as especially the testcase "block-container_absolute-position_fixed.xml" doesn't get broken. I'm going to look deeper into this ASAP. Right now I want to finish the documentation for FOP Trunk first to prepare for the initial release. Looks like we will still not be able to release this month and next week I'm away. :-( Thanks for explaining the problem. I understand much better now what's going on. -- 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.
