in reply to Getting the picture

First the arrangement, and apologies if you already know this. The image should be sent over the wire in response to a separate HTTP request. Your generated HTML should just include an IMG tag (or have Javascript that writes an IMG tag on demand); the browser, seeing this, will make the request for the image.

Now, the above means that you can basically point your browser to the URL given in the first page, and expect to receive an image/png response containing your image. So do just that: request the image manually. Look at the HTTP headers. One of them should contain the Content-type, before the double newline separator. If you have LWP installed, you can use GET -U http://... on the command line to examine the headers. Post the header here if you spot no problems.

Replies are listed 'Best First'.
Re^2: Getting the picture
by bret.foreman (Acolyte) on Aug 11, 2004 at 17:15 UTC
    Forgive me for being a little slow about all this. From your comments above, I presume I should "print" the IMG tag as explicit html code to the browswer, but what should be the exact string for that tag in this context? Remember that, even though there is an image file handle, there is no image file - it exists only in memory. Can the IMG tag specify that?

    Bret

      You need to provide a URL that somehow encodes everything you need to retrieve the image with, and — yes — have a separate CGI/handler/whatever provide the actual image data.

      You may defer creating the data to the second request, if you like: that means no temporary files, and that the IMG url needs to contain ebough info to *create* the image. Alternatively, you can have the first request create the image, store it somewhere (DB or file, doesn't really matter) and only communicate a request ID to the client, which is used to fetch the precomputed image.

      You have to think a bit about security here, considering that the second request may need its own authentication so that other people can't "steal" somebody else's image. Also, there's a nice feature of using stored and precomputed images in that caching becomes very easy: *anyone* who requests an image with the paramaters that have already been computed (and optionally, who also passes authentication) will get the data very quickly. You can have a scheduled task that clears up old data from sotrage to prevent it from growing too large (or too stale).

      One common way to do this is to save the image to a temp directory, then print out an <IMG SRC="..."> line that points to that temp file. Another process can periodically delete old images.

      If you're feeling lucky, you could try using a data URL to embed the image directly into the HTML, but it's not supported in all browsers, and will only work for small files IIRC.