DO NOT REPLY [Bug 37236] - [PATCH] Fix gradients and patterns

[bu...@apache.org]

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


jeremias@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Keywords|                            |PatchAvailable
            Summary|Fix gradients and patterns  |[PATCH] Fix gradients and
                   |                            |patterns




------- Additional Comments From jeremias@apache.org  2005-10-26 23:17 -------
(In reply to comment #7)
> Created an attachment (id=16810)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16810&action=view) [edit]
> Update to gradient transform fix, passes all junit tests.

Patch applied. Thanks.

> This replaces the first patch (it has the imporant bits of the
> second patch commented out as well).
> 
> This eliminates the concatenations list, but resets the Data
> transform after each push.  When the PDFRenderer want's to
> rebuild state it just uses the transforms from the individual
> data elements (rather than all of the concatenations).

Looks good to me.

> This appears to pass all of the JUnit tests but since this
> is the first time I've tried to run them it's a bit hard to
> know what this really means (is the PDF output checked for 
> example? Is there PDF output?).

The JUnit test can currently only check the FO tree and the layout engine, not
the renderers. We have a special renderer, the area tree renderer, which writes
out the area tree to an XML file and we use XPath statements to check against
this XML file. The area tree is the thing that the renderers convert to the
final output format, so we're only checking the input for the renderers, not
their output.

I've written a small tool (BatchDiffer) which can create diff images from
PDF/PS/Java2D output, but it's not integrated into JUnit, yet, and rather
designed for manual visual checking. I've actually stolen a few lines of code
from Batik for that. :-) The problem with checking PDF and PS is that you need
an external tool like GhostScript to convert PDF/PS to PNG so we could do
automated diff testing. We used to do checksum testing on the PDF files but
that's not really useful. Some way to go, one step at a time....

I'm leaving the issue open so we can look at the overflow thing ASAP.

-- 
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.