[Xmlgraphics-fop Wiki] Trivial 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:
Some smaller updates

------------------------------------------------------------------------------
  
  = Current status =
  
- Some of the content below is slightly out-dated. The "current problems" are mostly "past problems" now, after the [http://xmlgraphics.apache.org/commons/image-loader.html image loader framework in XML Graphics Commons] has been introduced. Performance and memory consumption has been improved as expected. Still, the image handling in the various renderers is still done in different ways. As an example: Barcode4J currently makes calls against the Graphics2DAdapter interface, the ImageAdapter interface, the PSRenderer class and can still use the fallback via SVG. The coupling is too high. The PDFRenderer also still has a slightly different approach at image handling than, say, the PSRenderer. Now, with the intermediate format, all the code that is directly dependent on the Renderer interface becomes a problem for code reuse.
+ Some of the content below is slightly out-dated. The "current problems" are mostly "past problems" now, after the [http://xmlgraphics.apache.org/commons/image-loader.html image loader framework in XML Graphics Commons] has been introduced. Performance and memory consumption has been improved as expected. Still, the image handling in the various renderers is still done in different ways. As an example: Barcode4J currently makes calls against the Graphics2DAdapter interface, the ImageAdapter interface, the PSRenderer class and can still use the fallback via SVG. The coupling is too high. The PDFRenderer also still has a slightly different approach at image handling than, say, the PSRenderer. Now, with the new intermediate format, all the code that is directly dependent on the Renderer interface becomes a problem for code reuse.
  
  = Current problems =
  
@@ -93, +93 @@

  ||PDF||native conversion with Batik||
  ||PostScript||native conversion with Batik||
  ||Java2D||native conversion with Batik||
- ||PCL||conversion to bitmap with Batik||
- ||AFP||conversion to bitmap with Batik||
+ ||PCL||conversion to bitmap with Batik||HP/GL Graphics2D implementation only for the simplest of SVGs available||
+ ||AFP||conversion to bitmap with Batik||GOCA implementation in the works||
  ||SVG||referenced or embedded||
  ||RTF||conversion to bitmap with Batik||
  
@@ -139, +139 @@

  ||PCL||direct painting to Graphics2D||
  ||AFP||direct painting to Graphics2D||See [http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 Bugzilla #41995] for an alternative using BCOCA||
  ||SVG||internally converted to SVG (NYI)||
- ||RTF||internally converted to bitmap (NYI)||
+ ||RTF||internally converted to bitmap||
  
  The new FOP extension is available since Barcode4J 2.0alpha1.
  

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