Bug 53177 - [PATCH] Fix for XGC when rendering PostScript using SVG being drawn upside down when using a custom affine transform.
Summary: [PATCH] Fix for XGC when rendering PostScript using SVG being drawn upside do...
Alias: None
Product: XMLGraphicsCommons - Now in Jira
Classification: Unclassified
Component: java2D (show other bugs)
Version: Trunk
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: --
Assignee: XML Graphics Project Mailing List
Depends on: 48723
  Show dependency tree
Reported: 2012-05-02 13:33 UTC by Robert Meyer
Modified: 2012-05-03 08:21 UTC (History)
0 users

Code changes applied including a test case (3.51 KB, patch)
2012-05-02 13:38 UTC, Robert Meyer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Meyer 2012-05-02 13:33:56 UTC

Comment 1 Robert Meyer 2012-05-02 13:38:20 UTC
Created attachment 28708 [details]
Code changes applied including a test case

A new dependency to Mockito has been added for the test case
Comment 2 Robert Meyer 2012-05-02 14:06:51 UTC
PostScript documents are by default drawn from the bottom up, because of this FOP changes the Y axis for each generated PS file so everything on the page is inverted and can be displayed in the same way as other document types such as PDF. 

If however, an SVG drawing co-ordinates were specified from the top down, a custom transform would need to be applied to counter FOP's automatic switch. The problem was that a checkTransform method prevented any new transform matching the current page transform from being applied. This original intention of this checkTransform method was to reduce the number of times the same transform is applied to the postscript file thus reducing its size. This is because if a transform is applied to an SVG drawing, for each shape being drawn the transform is applied at the shape level instead of at a drawing or subsequent svg parent level.

Where the checkTransform method fails is that it only checks for one outcome which is the initial page transform which in this case causes the problem. If you change the transform to invert the drawing by one pixel less e.g. [ ... 791 ] instead of [ ... 792 ] the transform would be applied on each shape and it would appear correctly (albeit a little off centre). This is because the transform is applied for the shape and then the graphics state is reverted meaning the current page state is never changed and the only transform it would ever ignore would be one matching the original FOP inversion transform.

As such I have removed this method and added a test unit case to prove it is now concatenating the affine transform correctly. The checkTransform method was a good idea, but due to the way Batik, Fop and XGC passing transforms onto child objects this is not currently possible to implement a fix and subsqeuent reduction in PS file sizes.
Comment 3 Glenn Adams 2012-05-02 15:38:21 UTC
patch landed at:


thanks rmeyer! please verify and close if satisfied
Comment 4 Mehdi Houshmand 2012-05-02 15:52:42 UTC
Thanks for applying this patch Glenn, I added the Hamcrest JAR to which Mockito has a transitive dependency r1333083.
Comment 5 Glenn Adams 2012-05-02 15:57:15 UTC
(In reply to comment #4)
> Thanks for applying this patch Glenn, I added the Hamcrest JAR to which
> Mockito has a transitive dependency r1333083.

thanks; i guess the current xgc junit doesn't tickle that dependency since it ran without error after i added mockito and objenesis jars
Comment 6 Mehdi Houshmand 2012-05-02 15:59:51 UTC
Yeah, no biggy. Hamcrest is needed for some of the matchers that Mockito uses which Rob hasn't used here.
Comment 7 Robert Meyer 2012-05-03 08:21:32 UTC
Thanks for applying the patch. I have verified the changes and will now set the status to closed / fixed.