Hi Jeremias,

My general view: we want to get rid of Renderers as soon as possible. We
don’t have enough resources to maintain two different rendering paths.
As far as I’m concerned, I don’t have knowledge about the rendering
stage. But if I ever had to work on that area, and now that
IFDocumentHandler exists, I would be strongly reluctant to invest any
time in the Renderer path.

As to your more specific questions:

Jeremias Maerki wrote:
> Follow-up issues for after the merge where I'd be glad for feedback:
> 
> - The new implementations currently all use a MIME suffix ";mode=painter".
> They are now sufficiently tested that I'm confident that we can switch
> over to them by default. One idea would be to put a switch in
> RendererFactory so we can say: prefer IFDocumentHandler instead of
> Renderer implementation. Or rather the opposite: by default use the
> IFDocumentHandler but allow to switch to the old mode should there be an
> unexpected incompatibility. Good idea or bad?

Is that realistic to do it this way: no switch, we directly use
IFDocumentHandler, any rendering difference is a bug that shall be
corrected sooner rather than later. Anyway, we will first release a beta
version for that very purpose IIC.

If that really is unfeasible, then +1 to your latter proposal:
IFDocumentHandler by default, with a possibility to fall back to the old
Renderer if really necessary.


> - Given the performance figures I think it would be possible to
> deprecate the following implementations: PDF, PS, PCL and AFP. As for
> the Java2D implementations: the PNG, Print and AWT Preview parts are not
> implemented, yet, so a deprecation here is premature. TXT is probably
> good enough like it is. No change necessary there. After all, we won't
> deprecate the Renderer interface itself. Good idea or bad?

Well, I think it’s perfect time for reconsidering which outputs we
really want to support. For me, that should be outputs for which there
is commercial support, or for which there is a large user base, or an
active committer willing to maintain them. Which means: do we care about
PNG and TXT? Both can easily be obtained from PDF. Let’s make a poll on
fop-users, and abandon those that don’t attract enough interest. Those
users whose business critically depends on a particular output can
always make sure that it gets moved into the ‘commercially supported’
category. (Same question about Print and AWT, although I believe they
fall into one of the first two categories.)

Why wouldn’t we deprecate the Renderer interface? Does it have any
feature that the new interface can’t provide? Let’s deprecate it, and
remove it after ‘enough time’ has passed.


> - A note primarily for Max: For JEuclid to work with the new
> implementations, it will require an ImageConverter implementation (from
> XML Graphics Commons' image loading framework). I haven't investigated
> how hard it would be to provide a compatibility layer so the old
> implementations could be used. The old stuff is in many parts tied into
> the Renderer architecture. For Barcode4J, I've written such an
> implementation already. I can also try to find time to do it for you, if
> you like. The good thing is that the ImageConverter implementation is
> not FOP-specific but can also be used by anyone using the image loading
> framework. Actually, that part might influence the decision for the
> first and second points above!
> 
> 
> Jeremias Maerki

Vincent

Reply via email to