Dear Fop developers,

after a while and some thinking, here is my concept for extensible image handlers for fop, or even better for xmlgraphics. If desired, I can implement this concept for xmlgraphics / fop with support for imageio, jimi and batik.

Image handling is a three-step process. Step one is detecting the file format, step two is loading the image, step three is outputting the image into whatever the output renderer is.


Step 1: Detecting the file format.

In most handlers this currently happens by trying to load the files, which is very inefficient. Instead, detectors like jmimemagic should be used. These should return a mime-type or null if the type can not be detected.

To speed up the process, a mime-type may be guessed from the file extension, and added as "hint"

Example interface:

public interface MimeTypeDetector {
String detectMimeType(URL file, String probableType) throws IOException;
}

Step 2: Loading the image.

The image can then be loaded by any image handler that supports this type.

Example:

public interface ImageHandler {
  void setImage(URL file) throws IOException;
  // ...
}

Step 3:  Outputting the image.

Generally there are three types of images. Vector images (SVG, MML), bitmap images (GIF, BMP, JPEG), and uninterpreted images (EPS)

- Vector images must supply a paint(Graphics g) function
- Bitmap images must supply a method to get the image contents as a Raster (similar to java.awt.RenderedImage) - Bitmap images may supply a method to get the image contents in LZW, ZLIB, DCT, format, such as in JPEG or TIFF compression (used in PDF) - Uninterpreted images just provide a method to get the contents in its original format.

Reflection may be used in the renderer to find out the image type, rather than checking for the type. Example:

if (image instanceOf VectorImage)  {
  ((VectorImage)image).paint(graphics)
} else if (image instanceOf DCTEncodedImage) {
  addResource(image.getDCTData)
// ...


To support extensibility, a registration mechanism is provided. Here is the basic idea:

Java provides standard mechanisms to find all resources with a given name in all classpath items. This allows to find all META-INF/ MANIFEST.MF files given in all JAR files in the classpath (1). These files can be parsed using standard Manifest functionality.

The files contain some attributes that describe classes used. For image handlers, this could be a classname and the supported image type. It may contain additional attributes, such as supported subtypes (e.g. LZW for TIFF). Ideally the exact specification of these attributes would be coordinated between fop and foray to support reuse.

This information can be parsed once and stored.

This mechanism requires the user to change only the classpath, and nothing else.

I have written a short proof-of concept code for the registration, available at
  http://max.berger.name/tmp/extTestMain.jar
and
  http://max.berger.name/tmp/extTestProvider.jar

(source is included in the jar files).

To run, try:
  java -cp extTestMain.jar name.berger.max.test.ext.Main
or
java -cp extTestMain.jar:extTestProvider.jar name.berger.max.test.ext.Main



(1) Of course, it doesn't have to be MANIFEST.MF. For resources such as fonts this may well be META-INF/FontDescriptor.xml or something else.



questions? comments?

Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name


Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to