Re: future renderer design (was: Reverting changes in AFP Renderer)

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 27.02.2008 17:09:49 Adrian Cumiskey wrote:
> 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?

Only to a certain extent. For painting text, you still have to write a
text matrix (Tm) to the output format because otherwise, you'd have to
paint the text using shapes which is not what we want. And for painting
nested graphics you'd also have no other way than to establish new
coordinate systems in the output format because you may not have full
control over what plug-ins do in terms of painting code production (EPS,
for example). At any rate, I'd find it unfortunate if we didn't make use
of some of the basic features of such document formats.

> 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.

I don't buy the "faster" and "smaller" argument. The "smaller" maybe to
a very small extent. You'd still have to write many transformation
matrices to the output format. And these will be more complex (and more
difficult to debug) if they are always combined with all previous
transformations. You'd only save a bit if you have many fixed positioned
block-containers (break-out & restore). Concerning the performance
aspect, the critical parts are the parsing of the intermediate format, handling
nested graphics and font embedding, not the renderer itself. Whether you
do the transformation inside FOP or in the output format I don't expect
a significant change in performance. Or did you do some profiling that
would lead you in this direction?

Jeremias Maerki