RFE: JRGraphics2DExporter problem

[gdressino]

Hi,

 

I have some problems using JRGraphics2DExporter with some rendering algorithms based on Graphics2D extensions.

 

JRGraphics2DExporter uses Graphic2D.setTransform at exportEllipse and exportRectangle. This method calls cause some problems with offscreen buffering algorithms.

 

This is from Graphic2d javadoc: "This method should never be used to apply a new coordinate transform on top of an existing transform because the Graphics2D might already have a transform that is needed for other purposes, such as rendering Swing components or applying a scaling transformation to adjust for the resolution of a printer."

 

Graphic2D.setTransform calls at exportEllipse and exportRectangle are used to restore the original transform after performing some transformations. That calls could be avoided undoing the transformations preformed:

 

----- with getTransform -----

// Get the current transform

AffineTransform transform = grx.getTransform();

 

// Perform transformation

grx.translate(x, y);

grx.scale(a/b,a/b);

 

// Render

grx.draw(...);

 

// Restore original transform

grx.setTransform(transform);

------------------------------

 

----- without getTransform ---

// Perform transformation

grx.translate(x, y);

grx.scale(a/b,a/b);

 

// Render

grx.draw(...);

 

// Restore original transform (reverse order and values)

grx.scale(b/a,b/a);

grx.translate(-x,-y);

------------------------------

 

Could be possible to rewrite JRGraphics2DExporter in order to avoid Graphic2D.setTransform calls?

 

This would be great to be nicer with some rendering algorithms based on Graphics2D extensions.

 

Thanks!

[lucianc]

Hi

 

A further quote from the Graphics2D.setTransform() javadoc:

 

The setTransform method is intended only for restoring the original Graphics2D transform after rendering, as shown in this example: Code: // Get the current transform AffineTransform saveAT = g2.getTransform(); // Perform transformation g2d.transform(...); // Render g2d.draw(...); // Restore original transform g2d.setTransform(saveAT);   This is exactly what happens in JRGraphics2DExporter. How is it wrong?   We could apply the inverse operations to restore the original transformation, but the doing it via getTransform() and setTransform() seems safer to me. For instance, doing g.scale(sx, sy) and g.scale(1/sx, 1/sy) might not lead to the same transformation due to floating point errors.   Regards, Lucian

[gdressino]

Hi

 

I've looking for a generic print/preview/export system for years. Each product has it own print/preview/export algorithms and is realy hard to mix pages generated by diferent products (even mix diferent pages from the same product).

 

Since almost all products produce Graphic2D output, it's a good idea just to buffer that output and asume 1 page = 1 graphics2d buffer. Then you can handle that pages to flush them on a printer, do previews, export as PDF, vector formats, image formats, etc.

 

I'm working with an offscreen buffer algorithm designed to buffer Graphics2D calls (and their parameters). That buffer could be serialized, stored, retrieved, etc.

 

The problem is with getTransform(). That method gets the current transform. When setTransform call is buffered, the "original Graphics2D transform" is buffered too.

 

When the buffer is flushed on a new Graphics2D instance with some previous transforms (i.e. scaling for zoom), setTransform is restoring the original "original" Graphics2D transform. The rest of the buffer produces an unscaled output.

 

The use of setTransform (in this particular case) becomes a graphic equivalent to use "absolute paths" in scripts instead of relative paths. Then, "setTransform" is too "absolute" for this case and this is the problem.

 

Probably this buffering algorithm is not so good and there is no reason to introduce changes on JasperReports. Indeed, you are right about floating point. Well, I hope at least this comments can bring for new ideas.

 

Thank you for your reply.