Loading image data from non file URLs (custom image loading)?

[neek]

I've got simple img tags working in our headless server application
(running in a servlet container):

<img src="file://whatever/foo/bar.jpg"/>

Images can be read off disk and rendered to the output pdf document.
Great.

Now, a lot of images in our system are generated dynamically via
servlets. This means the web frontend requests e.g.:

<img src="/imageServer?foo=bar"/>

The 'imageServer' endpoint generates image data, returning an
appropriate Content-Type etc header.

How should I go about being able to use that kind of URL in an xhtml
document input to flyingsaucer?

I don't know if it's flyingsaucer that actually resolves these URLs
and fetches the images data, or iText. I've found
http://markmail.org/message/w7i6jbdv3he3aqya where a discussion seems
to cover resource loading in the context of rendering to a Swing
panel. That's not my situation.

A random guess at the API revealed:

ITextRenderer renderer = new ITextRenderer();
SharedContext sc = renderer.getSharedContext();
sc.setUserAgentCallback(new NaiveUserAgent(device))

However I don't have a Device handle, I'm simply trying to call
renderer.layout()/createPDF() to get a PDF document. Any actual
Device and rendering context mechanisms seem to be hidden from me by
the flyingsaucer facade.

Can I provide either flyingsaucer or iText with a custom object which
will resolve URLs itself and return the image data to render, or can I
use true HTTP URLs in my <img> tags, or what? I'm a bit lost as to
where to go with this.

Thanks
Nick

[Daniel López]

I've always used full URLs with my images and other resources, like CSS stylesheets, with FlyingSaucer, so it should work fine. I never tried the other route, a resolver that handles relative URLs.

S!

D.

2011/8/17 neek <neekf...@gmail.com>

[neek]

On Aug 18, 1:39 am, Daniel López <d.lope...@gmail.com> wrote:
> I've always used full URLs with my images and other resources, like CSS
> stylesheets, with FlyingSaucer, so it should work fine. I never tried the
> other route, a resolver that handles relative URLs.

Well, almost too simple! :) I obviously hadn't tried this simple
approach.

As I have an appUrl variable already exposed in my xhtml generator,
it's trivial to put my app server's URL into the xhtml, so this works:

<img src="http://example.server.com:8080/imageServer?foo=bar"/>

I find that a URL without the full scheme/host/port specified doesn't
work:

<img src="/imageServer?foo=bar"/>

In fact if I put a random image in my current directory and run the
app server again, it finds it:

<img src="image.png"/>

So I guess the default resolution of an img src is a file URL relative
to the current directory of the java process it's running in, in which
case, any HTTP request is always going to have to be fully qualified.
Please correct me if I'm wrong.

Thanks for the tip :)
Nick

[neek]

Incidentally, now they're rendering, I see my images are very dark on
the resultant PDF in Acrobat on linux, but appear well in evince (a
linux document viewer). I haven't figured out how to attach images
here, so see this: http://nickfenwick.com/dark.jpg

On the left is Acrobat Reader showing the output PDF with a dark
image, on the right a plain web browser viewing exactly the same URL
that was in the xhtml input to flyingsaucer, and at the bottom is
evince showing the same pdf as Acrobat. The same image appears quite
differently in the two PDF viewers. Strange that Acrobat shows it so
dark. I've opened the same pdf in Acrobat on Windows and it appears
fine.

[Peter Brant]

The image (via the iText APIs) is copied basically verbatim into the
PDF (i.e. what you're seeing is some viewer artifact vs. something to
do with the PDF itself).

Pete

[neek]

On Aug 18, 6:05 pm, Peter Brant <peter.br...@gmail.com> wrote:
> The image (via the iText APIs) is copied basically verbatim into the
> PDF (i.e. what you're seeing is some viewer artifact vs. something to
> do with the PDF itself).

Good. Yeah, I figured as much. Thanks for the confirmation. Images
can be tricky, what with colour profiles, versions of codec, and so on.