[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:
Added a few words on the current status

------------------------------------------------------------------------------
  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 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.
  
  = Current problems =
  
@@ -165, +169 @@

  
  = 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.
+ 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. [DONE]
  
- 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.
+ 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. [DONE]
  
- If it is known which renderer the document will be rendered to during the layout stage, the images could be loaded in a separate thread after the dimensions have been determined while the actual layout continues.
+ If it is known which renderer the document will be rendered to during the layout stage, the images could be loaded in a separate thread after the dimensions have been determined while the actual layout continues. [ignored for now]
  
- We need to get rid of our byte array approach for storing decoded images. This should be done entirely using Java2D/AWT means, i.e. RenderedImage/BufferedImage.
+ We need to get rid of our byte array approach for storing decoded images. This should be done entirely using Java2D/AWT means, i.e. RenderedImage/BufferedImage. [DONE]
  

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