On 25.11.2008 09:28:18 Jeremias Maerki wrote: > On 24.11.2008 16:11:00 Adrian Cumiskey 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 :). > > Let's look at that. There are: > > AFPImageHandlerRawCCITTFax handling ImageRawCCITTFax.class, priority 400 > AFPImageHandlerRawStream handling ImageRawJPEG.class, ImageRawCCITTFax.class, > ImageRawEPS.class, priority 100 > AFPImageHandlerRenderedImage handling ImageBuffered.class, > ImageRendered.class, priority 300 > > ImageBuffered is also a ImageRendered, so reporting the handling of > ImageBuffered is unnecessary. > ImageRawJPEG, ImageRawCCITTFax and ImageRawEPS all derive from > ImageRawStream. Just reporting that class as supported class would have > been enough. The ImageFlavors are there to indicate what formats are > supported. > > Essentially, that means that the interface change was unnecessary. And > is the AFPImageHandlerRawCCITTFax even used? It has a lower priority > than AFPImageHandlerRawStream. > > So it seems that actually offers up an additional opportunity to resolve > the whole problem. A shame I haven't taken a closer look earlier. I > volunteer to revert the interface change and to change the plug-ins here > so they still work as envisioned. That minimizes the regression testing > necessary. After that, I'll vote +1 for the merge. >
I have locally changed "Class[] getSupportedClasses()" to "getSupportedClass()" and everything seems to work as before. The only thing I noticed is still AFPImageHandlerRawCCITTFax used because if reports support for ImageRawCCITTFax.class and is therefore picked before the more generic raw stream handler. I tried removing the CCITT handler but then get a fatal error in AFP Worbench whereas I get an empty space but no error message when the CCITT handler is active. I assume AFP Workbench doesn't support CCITT images. Unfortunately, I have no AFP printer to test with. I assume it would be best to remove the CCITT flavor from the raw stream handler. Adrian, if you can confirm my assumptions here, I can commit my changes and we've got one problem fixed. Jeremias Maerki
