Hi Clay,
Yes with the refactoring and code reuse changes in the Temp_AFPGOCAResource branch, other renderers
can now also take advantage of creating specialized concrete implementations of
AbstractImageHandlerRegistry and ImageHandler. Prior to these changes these features were only
available for PDF. But now both the PDF and AFP renderers make use of this same service oriented
framework.
There are also now some new extensible Batik bridges in org.apache.fop.svg that have been refactored
that were previously only available for PDF, these could also be extended for other output formats.
Adrian.
The Web Maestro wrote:
Can other potential renderers take advantage of this new declaration,
or is done in an AFP-specific way?
Clay
On 11/24/08, Adrian Cumiskey <[EMAIL PROTECTED]> wrote:
Hi Chris (and all),
Chris Bowditch wrote:
Adrian,
you've put a lot of work into the GOCA branch and it has some great
features, but....
There's one thing I don't like, which Jeremias points out in this thread:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL
PROTECTED]
We currently use the PDF plugin in our software and I prefer not to
upgrade the plugin without knowing what the justification the interface
change is?
Providing support for native image embedding in AFP involves providing the
image data (in whatever
form it may be) without any requirement for any image specific processing.
So there is one handler
which takes care of this in AFP, and this handler needs to declare itself
able to support the
handling of more than one image class. This use case was probably not
envisaged when the
PDFImageHandler interface was first introduced. Hope this explanation helps
:).
Adrian.
