Reply below..

Jeremias Maerki wrote:
I'm not sure I follow you. Do you mean that you'd always maintain the
transformation stack in the renderer? That's certainly something that
needs to be done in a uniform way.

Yes, a base renderer/painter could maintain both the transformation stack and common palette state features (paint color, brush thickness, font etc) as it traverses the block levels within the area tree.

For PDF/PS/Java2D you'd still always
apply any transformation to the output formats. For PCL (and probably
AFP) you wouldn't do that (because you can't) but instead apply the
current transformation to any coordinate that needs to be accessed in a
uniform way. Is that it? If yes, you could simply pull up the
graphicContext and graphicContextStack fields from PCLRenderer and
establish that pattern for all subclasses.

Could these coordinate transformations not be done by FOP as it is rendering the output file rather than delegating responsibility of performing these transformations to the PDF/PS interpreter? With this approach, the same rendering mechanism could be shared amongst renderers, just the absolute coordinates would be provided in the output file and not a series of matrices with which to derive the coordinates. This should result in printing/displaying being a little faster as the output format interpreter would be saved from having to do as many matrix calculations at runtime, also the resulting output file would be smaller for each document. Hope you follow my thinking.

Adrian.



Reply via email to