On 24.11.2008 16:50:48 Adrian Cumiskey wrote:
> 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.

Again: this is done for the renderers which are likely to become less
important (the majority even deprecated) in the future when the new IF
branch is finished. The new IF branch already contains an ImageHandler
interface which already serves all output formats. I suggest that be
reviewed and tuned for long-term service. That, together with the image
loader framework, represents a very flexible mechanism to handle and
convert all sorts of images and functionality and for all output formats.

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

Partially agreed, although the AbstractFOPTextPainter is a dead end, I'm
afraid. It only works for the simple cases. To paint almost all text as
shapes, something like the current PDFTextPainter has to be developed.

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




Jeremias Maerki

Reply via email to