dynamic image/resource resolution

[TS...@gcr.com]

Gentlemen,

      Recently, there was a need in the implementation of a document
generation system based on the FO Processor to resolve resources
pretty much the same way as the URIResolver interface work in accordance
with JAXP compliant parsers,  which is to dynamically assign the correct
image resources in memory to FOP during the parse stage and having that
information available during rendering.  This is in regards to the
maintenance version. :: 0.20.5rc2 ::

I just could not get around the idea of not being able to resolve
resources, particularly images dynamically using FOP.

I have a macro solution to having this functionality but I am not sure if I
am defeating some other intended features that I am not seeing or that
someone already has a better or more elegant solution to this that's not
implemented yet.  I just would like to see anyone's opinion on this,
particularly the people that have worked and/or are managing this piece of
code.

What do you guys think of reusing the stream held in imageReader to be made
available to reread image information if needed.  The same logic would take
place in FopImageFactory to obtain a stream but that stream would be left
available to the Image classes where at any point the image could be loaded
by obtaining the stream from the ImageReader instead of reopening another
stream on the URL as is happening now.
This would allow the FopImageFactory through the implementation of an
"ImageResolver" to resolve href's in the parsed document dynamically from a
database, in memory construction, etc.

--The ImageResolver interface would have one method "public InputSource
resolve(String href)".  Any outside layer or implementing application can
implement this interface and register itself with the FopImageFactory to
resolve images from other sources.

--The FopImageFactory would hold on to a static instance of an
imageResolver and would try to first resolve the href through the
imageResolver otherwise proceed with the current logic of creating the
image stream.

--The Image classes, ie -- JAIImage, JimiImage, JpegImage, etc would now
ask their imageReaders for the image stream instead of reopening the URL.

--The outside implementing layer or class would have to be thread aware
when registering and resolving images for the FopImageFactory.

I have tested this implementation in a multi-threaded distributed
environment running FOP in a servlet container. Performance is superb and I
am able to render PDF with dynamic images without any issue.  I understand
that all formats would have to be tested and that I have yet to do this.

I would be more then happy to post my code revision here if there is any
interest in including these type of  extensions to the maintenance branch.
I can pursue full testing of all the supported formats again if there is
any interest or at least discussing what the future possibilities are in
this area.

On a side note:
I have seen some of the new code for version 1.0 and see some changes
pertaining to Image Creation involving context caching and hints of
InputSource type approach but I am wondering if a dynamic type of
resolution will be made available for version 1.0.


Thanks for any input.

-T. Seremet




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

Re: dynamic image/resource resolution

[Jeremias Maerki <de...@greenmail.ch>]

Comments inline...

On 12.05.2003 21:06:46 TSereme wrote:
>       Recently, there was a need in the implementation of a document
> generation system based on the FO Processor to resolve resources
> pretty much the same way as the URIResolver interface work in accordance
> with JAXP compliant parsers,  which is to dynamically assign the correct
> image resources in memory to FOP during the parse stage and having that
> information available during rendering.  This is in regards to the
> maintenance version. :: 0.20.5rc2 ::
> 
> I just could not get around the idea of not being able to resolve
> resources, particularly images dynamically using FOP.
> 
> I have a macro solution to having this functionality but I am not sure if I
> am defeating some other intended features that I am not seeing or that
> someone already has a better or more elegant solution to this that's not
> implemented yet.  I just would like to see anyone's opinion on this,
> particularly the people that have worked and/or are managing this piece of
> code.
> 
> What do you guys think of reusing the stream held in imageReader to be made
> available to reread image information if needed.  The same logic would take
> place in FopImageFactory to obtain a stream but that stream would be left
> available to the Image classes where at any point the image could be loaded
> by obtaining the stream from the ImageReader instead of reopening another
> stream on the URL as is happening now.

That's a Good Thing but you wrote it for the maintenance branch which
will be frozen after 0.20.5. We're only fixing bugs until then. After
that we need to concentrate on the redesign where these ideas are highly
welcome. You can certainly publish your changes but they will most
probably not make it into maintenance branch CVS. I'm sorry.

> This would allow the FopImageFactory through the implementation of an
> "ImageResolver" to resolve href's in the parsed document dynamically from a
> database, in memory construction, etc.

I would think that these are two different aspects which are unrelated.

> --The ImageResolver interface would have one method "public InputSource
> resolve(String href)".  Any outside layer or implementing application can
> implement this interface and register itself with the FopImageFactory to
> resolve images from other sources.

Something like that will be included in the redesign.

> --The FopImageFactory would hold on to a static instance of an
> imageResolver and would try to first resolve the href through the
> imageResolver otherwise proceed with the current logic of creating the
> image stream.

Statics are bad in server-oriented software. We're trying to get away
from them. Why don't you start at a lower level with your resolver and
modify org.apache.fop.util.URLBuilder which does the URI to URL
conversion for the whole FOP codebase? I think that's a more appropriate
place to include your resolver code.

> --The Image classes, ie -- JAIImage, JimiImage, JpegImage, etc would now
> ask their imageReaders for the image stream instead of reopening the URL.
> 
> --The outside implementing layer or class would have to be thread aware
> when registering and resolving images for the FopImageFactory.
> 
> I have tested this implementation in a multi-threaded distributed
> environment running FOP in a servlet container. Performance is superb and I
> am able to render PDF with dynamic images without any issue.  I understand
> that all formats would have to be tested and that I have yet to do this.
> 
> I would be more then happy to post my code revision here if there is any
> interest in including these type of  extensions to the maintenance branch.
> I can pursue full testing of all the supported formats again if there is
> any interest or at least discussing what the future possibilities are in
> this area.

As I said: The maintenance branch will be frozen and now new
functionality is added. Only bugs fixed.

> On a side note:
> I have seen some of the new code for version 1.0 and see some changes
> pertaining to Image Creation involving context caching and hints of
> InputSource type approach but I am wondering if a dynamic type of
> resolution will be made available for version 1.0.

Certainly and help is welcome. Just keep in mind that we will probably
use the SourceResolver package Cocoon also uses. No final decision here
but one goal is a nice integration with Cocoon and the SourceResolver
package fits nicely here.

http://avalon.apache.org/excalibur/sourceresolve/index.html



Jeremias Maerki


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