You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by bu...@apache.org on 2008/11/03 19:15:55 UTC
DO NOT REPLY [Bug 46141] New: Graphics2D ImageConverters make
coordinate system assumption which is incorrect for AFP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
Summary: Graphics2D ImageConverters make coordinate system
assumption which is incorrect for AFP
Product: XMLGraphicsCommons
Version: Trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P1
Component: Image codecs
AssignedTo: general@xmlgraphics.apache.org
ReportedBy: dev@cumiskey.com
The ImageConverter*2G2D implementing classes in XG Commons make the assumption
when creating their Graphics2DImagePainter implementations that the coordinate
system used by the Graphics2D implementation follows the 'Standard' bottom to
top ascending x and left to right y ascending axis. This assumption is fine
for most cases but in the case of AFPGraphics2D implementation the coordinate
system is different and you have a descending y axis.
^ ------------------>
| |
| |
| |
| |
| |
|-----------------> |
Standard AFPGraphics2D (GOCA)
So for AFPGraphics2D you need to a different translation and scale
AffineTransform matrix to paint correctly. At the moment this translation and
scale preparation is hardwired inside the paint(Graphics2D g2d, Rectangle2D
area) method of the Graphics2DImagePainter implementation/instance.
There needs to be a separation of concerns between the painting and the
preparation for painting (which can be Graphics2D implementation specific).
--
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
DO NOT REPLY [Bug 46141] Graphics2D ImageConverters make coordinate
system assumption which is incorrect for AFP
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
Adrian Cumiskey <de...@cumiskey.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #4 from Adrian Cumiskey <de...@cumiskey.com> 2008-11-04 09:24:08 PST ---
Its committed with a workaround so nothing to worry about now.
--
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
DO NOT REPLY [Bug 46141] Graphics2D ImageConverters make coordinate
system assumption which is incorrect for AFP
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
--- Comment #1 from Jeremias Maerki <je...@apache.org> 2008-11-03 13:08:37 PST ---
Created an attachment (id=22824)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22824)
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
DO NOT REPLY [Bug 46141] Graphics2D ImageConverters make coordinate
system assumption which is incorrect for AFP
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
--- Comment #3 from Jeremias Maerki <je...@apache.org> 2008-11-04 03:24:09 PST ---
Adrian, can you please describe a test scenario where I can see the problem?
Can I use the code currently in the AFP branch or do you need to commit
anything before that?
--
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
DO NOT REPLY [Bug 46141] Graphics2D ImageConverters make coordinate
system assumption which is incorrect for AFP
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46141
Adrian Cumiskey <de...@cumiskey.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #2 from Adrian Cumiskey <de...@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