[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:
Some more thoughts

------------------------------------------------------------------------------
  ||PCL||decoded bitmap||
  ||AFP||decoded bitmap||
  ||SVG||referenced or RFC2396 data URL||
- ||RTF||PNG: 1:1 embedding||
+ ||RTF||1:1 embedding||
  
- === BMP, GIF ===
+ === BMP ===
+ 
+ ''fo:external-graphic only''
+ 
+ ||Renderer||required/preferred variant||Comments||
+ ||PDF||decoded bitmap||
+ ||PostScript||decoded bitmap||
+ ||Java2D||decoded bitmap||
+ ||PCL||decoded bitmap||
+ ||AFP||decoded bitmap||
+ ||SVG||referenced or RFC2396 data URL||
+ ||RTF||1:1 embedding||
+ 
+ === GIF ===
  
  ''fo:external-graphic only''
  
@@ -83, +96 @@

  
  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.
+ 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. The difficulty there are features like links which would need to be handled separately since they are not part of a Form object.
+ 
+ Similary for PostScript, the SVG could be rendered as an EPS file which could be reused within the document.
  
  === EPS ===
  
@@ -107, +122 @@

  
  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.
  
+ One small issue here: a math expression usually has a baseline. This baseline should be aligned with the FO baseline. 
+ 
  === Barcode4J ===
  
  ''fo:instream-foreign-object only''
@@ -120, +137 @@

  ||SVG||internally converted to SVG (NYI)||
  ||RTF||internally converted to bitmap (NYI)||
  
- The new FOP extension is in Barcode4J's CVS and functional.
+ The new FOP extension is available since Barcode4J 2.0alpha1.
  
  === 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.
+ The easiest 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.
+  * 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. Rendering to Java2D may be preferred to SVG as it can reduce some overhead.
-  * 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.
+  * 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. See Graphics2D!ImagePainter/Graphics2DAdapter as an example for a solution which is already implemented for some renderers.
   * 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.
+    * The image cache should store one entry per URI and flavor.
+    * Examples of possible flavors are: raw/undecoded, !RenderedImage/!BufferedImage, Graphics2D!ImagePainter, EPS, XML (SVG, MathML...), RFC2396 URL, etc.
+    * Renderers would provide a prioritized list of supported/preferred flavors. The image package would then do necessary decoding/conversions and deliver the best flavor it can deliver in a particular case.
-  * 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.
+  * 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.
+    * To handle all kinds of formats, we may need a special !PushBackInputStream which supports arbitrarily sized buffers to reset a stream to position 0. PNG is a case where the resolution information of an image is not guaranteed to be within the first 4KB of the file.
-  * 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!
+    * When someone works with the 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 (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.
  
+ 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.
+ 
+ We need to get rid of those byte array approach for storing decoded images. This should be done entirely using Java2D/AWT means.
+ 

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