[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-cvs
Subject:    [Xmlgraphics-fop Wiki] Update of "ImageSupport" by JeremiasMaerki
From:       Apache Wiki <wikidiffs () apache ! org>
Date:       2007-02-17 23:05:30
Message-ID: 20070217230530.9179.31840 () eos ! apache ! osuosl ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]