[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:
bringing it up-to-date

------------------------------------------------------------------------------
  ||PostScript||1:1 embedding||Requires PostScript Level 2||
  ||Java2D||decoded bitmap||
  ||PCL||decoded bitmap||
+ ||AFP||decoded bitmap||
  ||SVG||referenced or RFC2396 data URL||
- ||RTF||decoded bitmap||
+ ||RTF||1:1 embedding||
  
  1:1 embedding through FOP's own code. No support for decoding JPEG images through an image library, yet.
  
@@ -33, +34 @@

  ||PostScript||decoded bitmap||
  ||Java2D||decoded bitmap||
  ||PCL||decoded bitmap||
+ ||AFP||decoded bitmap||
  ||SVG||referenced or RFC2396 data URL||
- ||RTF||decoded bitmap||
+ ||RTF||decoded bitmap (PNG: 1:1 embedding)||
  
  === TIFF ===
  
@@ -45, +47 @@

  ||PostScript||decoded bitmap||1:1 embedding for CCITT encoded images (NYI)||
  ||Java2D||decoded bitmap||
  ||PCL||decoded bitmap||
+ ||AFP||1:1 embedding for CCITT encoded images||
  ||SVG||referenced or RFC2396 data URL||
  ||RTF||decoded bitmap||
  
@@ -58, +61 @@

  ||PDF||native conversion with Batik||
  ||PostScript||native conversion with Batik||
  ||Java2D||native conversion with Batik||
- ||PCL||TBD||
+ ||PCL||conversion to bitmap with Batik||
+ ||AFP||conversion to bitmap with Batik||
  ||SVG||referenced or embedded||
- ||RTF||TBD||
+ ||RTF||conversion to bitmap with Batik||
  
- 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.
+ 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 currently implemented in AbstractGenericSVGHandler and, for RTF, in SVGConverter.
+ 
+ For PDF, it would be interesting to have a native picture painted into a Form XObject so such an image can be preprocessed and more easily reused.
  
  === EPS ===
  
@@ -78, +84 @@

  
  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.
  
+ The FOray project has the beginnings of a PostScript interpreter with a proof-of-concept implementation for rendering graphics. But making it usable would take a lot of work.
+ 
  === 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.
+ 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. The alternative is to render MathML directly using Java2D.
  
  === Barcode4J ===
  
  ''fo:instream-foreign-object only''
  
  ||Renderer||required/preferred variant||Comments||
- ||PDF||internally converted to SVG||
+ ||PDF||painted using Java2D or internally converted to SVG||
  ||PostScript||internally converted to EPS||
- ||Java2D||direct painting to Graphics2D possible (NYI)||
+ ||Java2D||direct painting to Graphics2D||
- ||PCL||direct support could be implemented, otherwise go through SVG (NYI)||
+ ||PCL||direct painting to Graphics2D||
+ ||AFP||direct painting to Graphics2D||
  ||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.
+ The new FOP extension is in Barcode4J's CVS and functional.
  
  === Other foreign XML formats ===
  
@@ -114, +123 @@

  
  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.
+ For high-volume PostScript environments (or PPML) 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