https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
Adrian Cumiskey <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #2 from Adrian Cumiskey <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
