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. > -- Regards, The Web Maestro -- <[EMAIL PROTECTED]> - <http://ourlil.com/> My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
