[Understanding] Images [4]

[Keiron Liddle <ke...@aftexsw.com>]

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.


Images in FOP
-------------

Images may only be needed to be loaded when the image is rendered to the
output or to find the dimensions.
An image url may be invalid, this can be costly to find out so we need to
keep a list of invalid image urls.

We have a number of different caching schemes that are possible.

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.

(insert image)

Threading
---------

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.

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.

Caches
------

LRU
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.

Context
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.
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.

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.

Invalid Images
--------------

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.
This will prevent any extra processing or waiting.


Reading
-------

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.


Data
----

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.

Rendering
---------

Different renderers need to have the information in different forms.

PDF:
original data - JPG, EPS
bitmap - gif, tiff, bmp, png
other - SVG

PS:
bitmap - JPG, gif, tiff, bmp, png
other - SVG

awt:
bitmap - JPG, gif, tiff, bmp, png
other - SVG


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.



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [Understanding] Images [4]

[Christian Geisert <ch...@isu-gmbh.de>]

Keiron Liddle wrote:

[..]

> There are a number of packages in Avalon that would be useful, such as 
> command line parsing.
> I would be for an integration in general espacially since cocoon uses it.


+1 Avalon sounds interesting (pooling etc.) but I did not have a
close look yet.

> There will be resistence to the extra jar.

So the consequence would be that we write our own xml-parser to save
a jar ;-)

Seriously, I think this does not really matter...
(Maybe we could produce a fop-all.jar which would include all the jars)

Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [Understanding] Images [4]

[Keiron Liddle <ke...@aftexsw.com>]

> Just as an idea: Have you looked at Avalon Excalibur's caching package?
> Pretty good stuff.
> 
> By the way: What's the current agreement whether to use Avalon or not? I
> mean, we're already using LogKit (which is cool). On the other side, if
> we moved to the newer org.apache.avalon.framework.logger.Logger
> interface we would be more Logging framework independent (which was
> something a few people wanted). And considering that Cocoon is one of
> FOP's biggest customers and that they're using Avalon, both, FOP and
> Cocoon, could profit from the synergies. Currently, some interesting
> stuff is being moved from Cocoon to Avalon Excalibur that FOP might also
> profit from. On the other side: Avalon is lean but it brings some more
> jars to include in the distribution (which some people don't like) and
> takes some time to understand to really profit from.
> 
> Hey, don't flame me because I have expressed this. I'm just dreaming
> aloud. :-) I mean, we're using Avalon here at Outline and we're starting
> to get good at it. It helps us very much in making better code.

There are a number of packages in Avalon that would be useful, such as 
command line parsing.
I would be for an integration in general espacially since cocoon uses it.

There will be resistence to the extra jar.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [Understanding] Images [4]

[Jeremias Maerki <je...@outline.ch>]

> 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.

<snip/>

> Threading

Thanks for thinking about this!

<snip/>

> Caches
> ------
> 
> LRU
> 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.

Just as an idea: Have you looked at Avalon Excalibur's caching package?
Pretty good stuff.

By the way: What's the current agreement whether to use Avalon or not? I
mean, we're already using LogKit (which is cool). On the other side, if
we moved to the newer org.apache.avalon.framework.logger.Logger
interface we would be more Logging framework independent (which was
something a few people wanted). And considering that Cocoon is one of
FOP's biggest customers and that they're using Avalon, both, FOP and
Cocoon, could profit from the synergies. Currently, some interesting
stuff is being moved from Cocoon to Avalon Excalibur that FOP might also
profit from. On the other side: Avalon is lean but it brings some more
jars to include in the distribution (which some people don't like) and
takes some time to understand to really profit from.

Hey, don't flame me because I have expressed this. I'm just dreaming
aloud. :-) I mean, we're using Avalon here at Outline and we're starting
to get good at it. It helps us very much in making better code.

<snip/>

> Rendering
> ---------
> 
> Different renderers need to have the information in different forms.
> 
> PDF:
> original data - JPG, EPS
> bitmap - gif, tiff, bmp, png
> other - SVG
> 
> PS:
> bitmap - JPG, gif, tiff, bmp, png
> other - SVG

PS Level 3 supports DCT encoding, so JPEG images could (one day) also be
included as original data.

EPS might also be directly embedded given the PostScript Levels are
compatible.

I'll have a look at it (real soon now).

> awt:
> bitmap - JPG, gif, tiff, bmp, png
> other - SVG
> 
> 
> 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.

Cheers,
Jeremias Märki

mailto:jeremias.maerki@outline.ch

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org