The color palette of .bmp files with 1 bit/pixel is not used when loading image.
Example of a bmp header I've received from Alchemy on Unix:

0000  424DAE8E01000000 00003E0000002800
0010  000016030000FC03 0000010001000000
0020  0000708E0100C21E 0000C21E00000000
0030  000000000000FFFF FF00000000000000
0040  0000000000000000 0000000000000000

The palette is inverted (why, I don't know). So a 0 bit means a white pixel and 
a 1 bit means a black pixel.
In class org.apache.fop.image.BmpImage, method loadImage ignores the palette in 
that case (it's not even constructed). For FOP, a 0 bit means always black 
pixel and a 1 bit means always white pixel.
So my image appears in Acrobat Reader as inverted video.

I have fixed the bug with the following statements :

if (headermap[28] == 4 || headermap[28] == 8 || headermap[28] == 1) {

to always build the palette and 

for (int countr = 0; countr < 8 && x < this.m_width;
		countr++) {
	if ((p & 0x80) != 0) {
		this.m_bitmaps[3 * (i * this.m_width + x)] =
//			(byte)0xFF;
			palette[3];
		this.m_bitmaps[3 * (i * this.m_width + x) + 1] =
//			(byte)0xFF;
			palette[4];
		this.m_bitmaps[3 * (i * this.m_width + x) + 2] =
//			(byte)0xFF;
			palette[5];
	} else {
		this.m_bitmaps[3 * (i * this.m_width + x)] =
//			(byte)0;
			palette[0];
		this.m_bitmaps[3 * (i * this.m_width + x) + 1] =
//			(byte)0;
			palette[1];
		this.m_bitmaps[3 * (i * this.m_width + x) + 2] =
//			(byte)0;
			palette[2];
}

to use it.
I think it could help.

Frédéric.