xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46141] Graphics2D ImageConverters make coordinate system assumption which is incorrect for AFP
Date Tue, 04 Nov 2008 10:43:07 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141


Adrian Cumiskey <dev@cumiskey.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #2 from Adrian Cumiskey <dev@cumiskey.com>  2008-11-04 02:43:06 PST ---
I understand all that you are saying, but I repeat myself again, the
ImageConverter is making an assumption about the coordinate system being used
by the Graphics2D implementation.  I can provide an unsatisfactory workaround
to invert the Y axis (g2d.translate(0, area.getHeight()); g2d.scale(1, -1))
prior to painting.  It would be better if there was a hook provided into each
painter like setPreparator(PainterPreparator preparator) which could override
any default implementation for the painting coordinate preparation phase.

(In reply to comment #1)
> Created an attachment (id=22824)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22824) [details]
> Examples showing off the image loader framework
> 
> These image converters don't make any assumptions. They follow the requirements
> of the Graphics2DImagePainter interface. Or I hope they do if I've done my job
> right (but the example in the attachment proves that [1]). At least it worked
> for PDF, PS (both have LR-BT coordinate systems) and for Java2D and PCL
> (LR-TB). The interface has two methods:
> 
> "Dimension getImageSize()" returns the image's intrisic size in millipoints.
> That's an absolute size which is useful for certain situations. FOP usually
> doesn't need that because it already knows the intrinsic size from the layout
> stage (from the ImageInfo object).
> 
> "void paint(Graphics2D g2d, Rectangle2D area)" actually paints the image on the
> given Graphics2D object. The implementation has to paint the image (in its
> entirety) so it fits in the coordinates (user/any coordinates) given by the
> area. See also the Javadocs. Let me know if they are unclear.
> 
> IMO, the contract is clear. The caller has to set up the coordinate system so
> the image is properly painted. If it is upside-down in your case, you've got a
> bug in your code. If you want help, I can take a look at the AFP code tomorrow
> (Tuesday is my FOP day this week).
> 
> [1] When you run that example yourself, you need to change the base directory
> to a FOP working copy so it finds the images. Note that there seems to be a bug
> in PSGraphics2D that somehow messes up some of the text coming from the WMF
> example. The rest looks ok.
> 


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message