diff options
| author | arved <arved@unknown> | 2002-03-17 17:24:10 +0000 |
|---|---|---|
| committer | arved <arved@unknown> | 2002-03-17 17:24:10 +0000 |
| commit | e817266a9f7d1b0579839cc2383fe988ab5c3bc8 (patch) | |
| tree | 01977c8281b32489adbee64edf7125fbe47b0245 /docs/design/understanding/images.xml | |
| parent | 63636d3149af05ddc01e8ac38a5d794c36c7af53 (diff) | |
| download | xmlgraphics-fop-e817266a9f7d1b0579839cc2383fe988ab5c3bc8.tar.gz xmlgraphics-fop-e817266a9f7d1b0579839cc2383fe988ab5c3bc8.zip | |
Extra design commentary
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@194703 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/design/understanding/images.xml')
| -rw-r--r-- | docs/design/understanding/images.xml | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/docs/design/understanding/images.xml b/docs/design/understanding/images.xml new file mode 100644 index 000000000..6aaa82bc8 --- /dev/null +++ b/docs/design/understanding/images.xml @@ -0,0 +1,146 @@ +<?xml version="1.0" standalone="no"?> +<!-- Overview --> +<document> + <header> + <title>Images</title> + <subtitle>All you wanted to know about Images in FOP !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body> + + + <s1 title="Images in FOP"> <note> this is still in progress, input in the code is welcome. Needs documenting formats, testing. + So all those people interested in images should get involved.</note> + <p>Images may only be needed to be loaded when the image is rendered to the +output or to find the dimensions.<br/> +An image url may be invalid, this can be costly to find out so we need to +keep a list of invalid image urls.</p> +<p>We have a number of different caching schemes that are possible.</p> +<p>All images are referred to using the url given in the XSL:FO after +removing "url('')" wrapping. This does +not include any sort of resolving such as relative -> absolute. The +external graphic in the FO Tree and the image area in the Area Tree only +have the url as a reference. +The images are handled through a static interface in ImageFactory.<br/></p> + + +<p>(insert image)</p> + + +<s2 title="Threading"> + + + +<p>In a single threaded case with one document the image should be released +as soon as the renderer caches it. If there are multiple documents then +the images could be held in a weak cache in case another document needs to +load the same image.</p> + + +<p>In a multi threaded case many threads could be attempting to get the same +image. We need to make sure an image will only be loaded once at a +particular time. Once a particular document is finished then we can move +all the images to a common weak cache.</p> +</s2> + +<s2 title="Caches"> +<s3 title="LRU"> +<p>All images are in a common cache regardless of context. To limit the size +of the cache the LRU image is removed to keep the amount of memory used +low. Each image can supply the amount of data held in memory.</p> +</s3> + +<s3 title="Context"> +<p>Images are cached according to the context, using the FOUserAgent as a key. +Once the context is finished the images are added to a common weak hashmap +so that other contexts can load these images or the data will be garbage +collected if required.</p> +<p>If images are to be used commonly then we cannot dispose of data in the +FopImage when cached by the renderer. Also if different contexts have +different base directories for resolving relative url's then the loading +and caching must be separate. We can have a cache that shares images among +all contexts or only loads an image for a context.</p> +</s3> + +<p>The cache uses an image loader so that it can synchronize the image +loading on an image by image basis. Finding and adding an image loader to +the cache is also synchronized to prevent thread problems.</p> +</s2> + +<s2 title="Invalid Images"> + + +<p> +If an image cannot be loaded for some reason, for example the url is +invalid or the image data is corrupt or an unknown type. Then it should +only attempt to load the image once. All other attempts to get the image +should return null so that it can be easily handled.<br/> +This will prevent any extra processing or waiting.</p> +</s2> + + +<s2 title="Reading"> +<p>Once a stream is opened for the image url then a set of image readers is +used to determine what type of image it is. The reader can peek at the +image header or if necessary load the image. The reader can also get the +image size at this stage. +The reader then can provide the mime type to create the image object to +load the rest of the information.<br/></p></s2> + + + +<s2 title="Data"> + + + +<p>The data usually need for an image is the size and either a bitmap or the +original data. Images such as jpeg and eps can be embedded into the +document with the original data. SVG images are converted into a DOM which +needs to be rendered to the PDF. Other images such as gif, tiff etc. are +converted into a bitmap. +Data is loaded by the FopImage by calling load(type) where type is the type of data to load.<br/></p></s2> + + +<s2 title="Rendering"> + +<p>Different renderers need to have the information in different forms.</p> + + +<s3 title="PDF"> +<dl><dt>original data</dt> <dd>JPG, EPS</dd> +<dt>bitmap</dt> <dd>gif, tiff, bmp, png</dd> +<dt>other</dt> <dd>SVG</dd></dl> +</s3> + +<s3 title="PS"> +<dl><dt>bitmap</dt> <dd>JPG, gif, tiff, bmp, png</dd> +<dt>other</dt> <dd>SVG</dd></dl> +</s3> + +<s3 title="awt"> +<dl><dt>bitmap</dt> <dd>JPG, gif, tiff, bmp, png</dd> +<dt>other</dt> <dd>SVG</dd></dl></s3> + + + +<p>The renderer uses the url to retrieve the image from the ImageFactory and +then load the required data depending on the image mime type. If the +renderer can insert the image into the document and use that data for all +future references of the same image then it can cache the reference in the +renderer and the image can be released from the image cache.</p></s2> +</s1> + </body></document> + + + + + + + + + + + + + |