Malin Norrstrand wrote:
1. In the fop specs it says that output images will have a resolution of
72 dpi. I have tried generating pdf with jpgs and gifs of both 72 dpi
and 600 dpi, and it seems like fop does not care about changing
resolution. Does anybody know how this works?

I'm not sure how you managed to create GIFs or JPGs with a specific resolution. Both are bitmap formats, their size is primarily mesured in pixels. In order to render bitmaps on physical media which lacks a pixel structure (like paper), the resolution in form of dpi measurements kicks in. A resolution of 72dpi means thet 72 dots (pixels) are printed per inch, or roughly 100 pixels per 3.53 cm. There may be metadata in the image files specifying some resolution, AFAIK FOP ignores this completely. You can, however, specify the absolute height and/or width on the fo:external-graphic object. If you use <fo:external-graphic src="foo.gif" width="1cm"/> the image is scaled so that it is exactly one centimeter wide in the rendering result, regardless of number of pixels or resolution measurements.

2. When trying to generate a pdf with a bmp image in it, I get an
exception. Does fop only support some types of bmp, and if so, which
ones? I have tried with screenshots and downloaded images, and some bmps
saved in Photoshop. The exception:

FOP understands uncompressed BMP, presumably the Windows variant (there is an OS/2 too), with true color (24bit per pixel), 256 color (8bit), 16 color (4 bit) and b/w (1 bit). I'm not a graphic format guru, so I can't tell about various subvariants involving palette sizes and inverted colors and RLE and other compression schemes.

I have no problems rendering BMP files created with MS Paint
or the netpbm toolkit. The exception:

        at org.apache.fop.image.BmpImage.loadImage(

signals an array overflow while reading the pixel array. That's strange, if FOP doesn't understand the format, it should have thrown an exception already. If you still get the same error with a 50x50 pixel BMP created with MS paint, I'd suspect a buggy or corrupted JVM which doesn't correctly report EOF conditions.


Reply via email to