Thanks for pointing this out.
The Jimi documentation mentions extendability "via its Open Image I/O
interface. Any format handler implemented under this interface will inherit
all of Jimi's powerful features. Using this interface, developers are able
to create modules to support new formats and register them with the Jimi
runtime system".
So maybe an interface between the com.lowagie.text.Image class and Jimi's
image format could make an easy exchange method.
Personally, I'd be curious if Jimi could use less memory when opening large
bitmaps and then hand it off to iText for processing into the PDF. I ask
this because I've had problems in the past having iText open an image
scanned in as a 25 MB bitmap. The line that I kept getting "Out of Memory
error" on was "Image image = Image.getInstance("scanned001.bmp")". I'm sure
that once iText got the image into memory it was probably must less memory
intensive to process the image, but that initial conversion seemed to
require 2-3 times the image's size to do the one time conversion.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions
