[Xmlgraphics-fop Wiki] Update of "ImageSupport" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/ImageSupport

The comment on the change is:
Writing down my analysis and thoughts on images in FOP

New page:
This page documents aspects around images in Apache FOP. Older design documentation can be found here: http://xmlgraphics.apache.org/fop/design/images.html

= Current problems =

Certain renderers can embed images directly (JPEG, EPS and certain TIFF subformats, for example) but other renderers still require a decoded bitmap image. Currently, the cache only provides the first requested variant of an image. If the PDF renderer rendered an FO file with a JPEG image and then the same document is rendered with the Java2DRenderer, there will be a problem because JPEGImage loaded the original data and did not decode the JPEG image.

= Format support matrix =

The following matrix tries to show all the possible combinations.

=== JPEG ===

''fo:external-graphic only''

||Renderer||required/preferred variant||Comments||
||PDF||1:1 embedding||
||PostScript||1:1 embedding||Requires PostScript Level 2||
||Java2D||decoded bitmap||
||PCL||decoded bitmap||
||SVG||referenced or RFC2396 data URL||
||RTF||decoded bitmap||

1:1 embedding through FOP's own code. No support for decoding JPEG images through an image library, yet.

=== PNG, BMP, GIF ===

''fo:external-graphic only''

||Renderer||required/preferred variant||Comments||
||PDF||decoded bitmap||
||PostScript||decoded bitmap||
||Java2D||decoded bitmap||
||PCL||decoded bitmap||
||SVG||referenced or RFC2396 data URL||
||RTF||decoded bitmap||

=== TIFF ===

''fo:external-graphic only''

||Renderer||required/preferred variant||Comments||
||PDF||decoded bitmap||1:1 embedding for CCITT encoded images||
||PostScript||decoded bitmap||1:1 embedding for CCITT encoded images (NYI)||
||Java2D||decoded bitmap||
||PCL||decoded bitmap||
||SVG||referenced or RFC2396 data URL||
||RTF||decoded bitmap||

1:1 embedding through the help of Batik's TIFF codec plus FOP's own code.

=== SVG ===

''fo:instream-foreign-object and fo:external-graphic''

||Renderer||required/preferred variant||Comments||
||PDF||native conversion with Batik||
||PostScript||native conversion with Batik||
||Java2D||native conversion with Batik||
||PCL||TBD||
||SVG||referenced or embedded||
||RTF||TBD||

Output formats (like PCL and RTF) for which no native conversion is available we need an alternative to provide the SVG as a bitmap image. This is NYI.

=== EPS ===

''fo:external-graphic only''

||Renderer||required/preferred variant||Comments||
||PDF||embedded||PDF support is deprecated and not supported by newer Acrobat Readers||
||PostScript||embedded||
||Java2D||not supported||
||PCL||not supported||
||SVG||not supported||
||RTF||not supported||

If we ever have a PostScript interpreter available to FOP we can support EPS images for other output formats. An alternative could be to extract the TIFF previews provided by certain EPS images but this is better solved through a better suited image format.

=== MathML ===

''fo:instream-foreign-object and fo:external-graphic''

MathML is internally converted to SVG in the MathML extension and subsequently handled as such. So see the SVG section for details. Same problems, too.

=== Barcode4J ===

''fo:instream-foreign-object only''

||Renderer||required/preferred variant||Comments||
||PDF||internally converted to SVG||
||PostScript||internally converted to EPS||
||Java2D||direct painting to Graphics2D possible (NYI)||
||PCL||direct support could be implemented, otherwise go through SVG (NYI)||
||SVG||internally converted to SVG (NYI)||
||RTF||internally converted to bitmap (NYI)||

Work in progress. The FOP Trunk compatible FOP extension is not finished and not published, yet.

=== Other foreign XML formats ===

The easyest way is to convert to SVG internally and let the renderers handle that format. Examples for this section: Example plan extension, JCharts support etc.

= Requirements for the whole solution =

 * Extensions which support foreign XML formats should be able to convert their content at least to SVG. Generating bitmaps is also desirable so output formats like RTF can also be supported.
 * Renderers need to expose APIs to output directly supported formats other than bitmap formats. EPS for PostScript, Graphics2D for at least Java2DRenderer but possibly also for PDF and PS.
 * Different renderers support different source formats/flavors for the images to be embedded. The current cache only supports exactly one flavor. If the same image is rendered with another renderer this might result in problems.
 * During layout only the image dimensions need to be determined so the image can be properly placed. The actual image data only needs to be available during rendering. Ideally, the InputStream to load the dimensions from should be available to the component fully loading the image later on to avoid additional round-trips to fetch the image. Should additional flavors be needed, the InputStream can probably be reopened.
 * If we (later on) create a XML-based intermediate format to represent the area tree, the layout and the rendering might happen in different VMs, so the actual image data might actually never be loaded at all, so the InputStream still needs to be closed properly!

= Random thoughts =

It might be good to separate the image dimension object for the layout process from the actual decoded image, thus providing separate caches for both.

For high-volume PostScript environments it might be worthwhile not to fully load images at all but to simply insert resource placeholders (DSC comment %%IncludeResource) into the stream. This would speed up the rendering process considerably for environments where such an approach is possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org