--- Comment #16 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-10-21 14:44:43 
PST ---
(In reply to comment #15)
> Okay, I think I fully understood this and this is basically okay. So, the
> URIResolver is no suitable way of changing these URIs, alas. So what is a
> URIResolver good for, if it's just ignored in some cases (here: image cache
> already has URI and doesn't call URIResolver anymore)? Even the first time my
> URIResolver is called, the image cache still has the original URI instead of
> the changed URI from the URIResolver. Or is this behaviour also as intended?

Yes, the URIResolver is ignored when the image is in the cache, but it's really
only used for loading the actual image. The behaviour is as I intended it to
be. I designed the cache so it uses the image's URI (i.e. an identifier) to
uniquely identify the resource. Let me explain the design decision with some
more information, to show you what kind of cases need to be handled:

We have to support different kinds of URIs on fo:external-graphic and for other
resources:   (this is a URL, and therefore a URI)
file:///C:/Images/logo.jpg   (this is a URL, and therefore a URI)

--> Direct access because they are URLs

urn:images:13487973   (this is a URN, and therefore a URI)

--> Identifier, the specifier doesn't care where the resource comes from

URI resolution means: Turn URI into a Resource.
The resource could be represented by a URL but doesn't have to be, because:

- CatalogResolver: Map URIs to URLs.
    urn:images:13487973 --> http://db-server/images?id=13487973 (provided by a
servlet somewhere on a server)
    (Resolved system ID (URL) available)

- Private URI Resolver: 
    urn:images:13487973 --> URIResolver directly returns a StreamSource with a
InputStream for accessing the image
    (There might or might not be a system ID (URL) in this case)

If we implemented what you're wishing for, what would we do if there's no
systemID? Can we be sure that the system ID is always more stable/correct than
the original URI for use in the image cache? How do we decide what to use? IMO,
if you use the same URI for different images, you violate the "identifier"
purpose of the URI. The resource is no longer unique. Using the resolved system
ID would only be a work-around. Well, this is my view and I can be wrong. But
it's also how FOP has done it the last few years even before the image loader

Notes on Image Loader Framework implementation:
For normal URLs (HTTP, FTP...) a stream is opened and decorated with an ImageIO
ImageInputStream which provides random I/O access to the image. For that, the
image is mirrored locally, either in memory or temporary file. Special care has
to be taken that for the same URL, no two requests have to be initiated (for
pre-loading and loading) which would cause additional round-trips.
File URLs are handled in a particular way. For those, direct random I/O access
can be provided directly.

I guess I'll look into prepending the base URI to relative URIs tomorrow to
make the original URI "more unique". That is almost certain to fix your

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to