sclaridge1

I am trying to modify a GS driver which implements the copy_mono
function (among others). If GS is run without the -dTextAlphaBits=4
flag then everything is fine, the bitmap created from copy_mono is OK,
but rough looking. If I use the -dTextAlphaBits=4 flag then the
'raster' variable in copy_mono increases, I take it this means that it
takes 4 bits to represent a pixel instead of the usual 1? If this is
the case, then why is copy_mono being called instead of copy_color as
we may be displaying with more than 2 colours? If I'm doing this right
and I still need to handle copy_mono even if TextAlphaBits=4 then what
pallete options do I use, the color0 and color1 local vars are now
meaningless. I'm trying to output a Windows .bmp structure, if anyone
has any ideas or example code I'd be very grateful.

Thanks,

Steve.

alex cherepanov

Take a look at the following devices.
bmp16 bmp16m bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8

Perhaps all you need to say is -sDEVICE=bmpgray

sclaridge1

Thanks Alex,

I have been looking at gdevbmp.c and gdevbmpc.c a lot to try and
figure out what is happening. In write_bmp_header is the following
code:

for (i = 0; i != 1 << depth; i++)
{
(*dev_proc(pdev, map_color_rgb))((gx_device *)pdev, (gx_color_index)i, rgb);
q.red = gx_color_value_to_byte(rgb[0]);
q.green = gx_color_value_to_byte(rgb[1]);
q.blue = gx_color_value_to_byte(rgb[2]);
palette[i] = q;
}

Which I though was useful when copy_mono was called when TextAlphaBits=4 and
thus I could get all the palette colours in use but this still gives me
garbage on the output bitmap.

My main confusion is that copy_mono is called to draw a character even though
TextAlphaBits=4, the chars are not mono anymore so why isn't copy_color called
instead? copy_mono has two input params of color0 and color1 but these become
useless when TextAlphaBits=4.

Help!

Steve.