xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Edge" <Martin.E...@asmorphic.net.au>
Subject RE: Issues for after the IF branch merge
Date Wed, 18 Feb 2009 06:33:55 GMT
Hi Jeremias,

Is this a IF XML structure change? Or merely the way it's being processed?

I make changes to the IF prior to rendering my final document as I need to
put information on each page generated and be aware of the total amount of
pages rendered (a barcode as it was). 

When you say deprecate following implementations, do you mean the fact that
the IF previously held some reference on what type of output the IF was
created for?

Where can I get more information on this change?

Thanks :-)



-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
Sent: Tuesday, February 17, 2009 3:12 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Issues for after the IF branch merge

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?

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

- 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

View raw message