On 25.11.2008 13:27:19 Adrian Cumiskey wrote: > Jeremias, > > Jeremias Maerki wrote: > >>> 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. > > Just reporting the ImageRawStream as a supported class is risky as AFP is not > guaranteed to support > all natively embedded all (raw) object types, only the fixed list of ones > that are registered in the > MOD:CA Registry.
The image flavors are there for that. They are what's used to determine which image instance the image loading framework shall produce. If the set of supported flavors matches the available image handlers, there's no problem. > > 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 found an alternative solution that does not involve the method > signature change in the > PDFImageHandler interface, so you won't need to release a new plugin. I will > take care of this. Thanks. Work done twice but so be it. Jeremias Maerki
