> I think btw that it is not too nice to use hard links to the servlets, > because you have to think of adding the application context then (otherwise > the page is not portable). > > You can generate the URL to the image with the mm:image tag, to avoid this. > > But this will not currently fix your problem....
True... But the page with the problem is still SCAN, so it's not that big a problem. > mm:url will at least add the context for you.. > <mm:url page="/attachment.db?$number" /> That would do for now, if we were to migrate to jsp. Which we will anyway... :) But it would be very nice if the img.db servlet did not do any conversions unless an image-size, file-format or what-have-you was specified. That would probably mean some extra info would need to be stored in the database, like original image type and size. That could be determined at upload-time (by identify; convert's counterpart, also part of the ImageMagick package). This would allow both a nice <IMG> tag with width & height (which should speed up page rendering a bit, or a lot for mobile devices), and would be needed to provide the correct mime-type in the http response for the img.db url. (Unless you want to figure that out at request time by doing a magic-byte lookup every time the image is requested). Or these fields could be filled in optionally at request time if they're not there already. That would allow easier migration to an image builder that supported this functionality... But I think I'm suddenly posting in the wrong mailing-list.... :) Regards, GRG.
