monochrome bitmap palette in monolithic printer driver

I have written a monolithic printer driver.
An application is BitBlt-ing a monochrome, 8-bit bitmap.
I know it is monochrome because I asked the application developers.

When I query the XLATEOBJ* in BitBlt, I get 4 colors, 0xFFFFFF, 0xFEFFFF,
0xFAFAFA and 0xFAFAFA (in that order). I am querying it using the member
pulXlate, (the flXlate flag is set to XO_TABLE). I also tried querying it
using XLATEOBJ_cGetPalette with XO_SRCPALETTE. I get the same results.

It seems to me that the palette should consist of just 2 colors (the bitmap
data certainly only contains 2 different values).

So I am outputting the bitmap with an incorrect palette, and the results are
predictably incorrect.

A competitor's printer driver, when printing the same file from the same
application, outputs the same bitmap but with the palette consisting of only
2 colors (RGB(0,0,0) and RGB(255,255,255)).

If I print to file and then edit the output of my driver, and replace the
palette I generate with the one the competitor generates (and leave
everything else the same), the file prints correctly.

So my question is, what could be causing this and where should I look? How
can I find the correct palette information for this bitmap? All the rest of
the time, calling the XLATEOBJ for color information works correctly.

(In EnablePDEV, I set the hpalDefault member of the DEVINFO to the result
from EngCreatePalette(PAL_RGB, 0, 0, 0, 0, 0);)

Thanks in advance,
--
ScottR
Scott Robins

Vipin[MVP]
Tue Oct 18 16:30:07 CDT 2005


I guess it should be the problem with the way you are translatting the
palette.
It works properly if properly done, I use it in my driver. And there is no
code
you have posted to suggest where the problem could be.

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"Scott Robins" <ScottRobins@discussions.microsoft.com> wrote in message
news:D9482371-64D8-4111-8E44-844FC053DF2E@microsoft.com...
>I have written a monolithic printer driver.
> An application is BitBlt-ing a monochrome, 8-bit bitmap.
> I know it is monochrome because I asked the application developers.
>
> When I query the XLATEOBJ* in BitBlt, I get 4 colors, 0xFFFFFF, 0xFEFFFF,
> 0xFAFAFA and 0xFAFAFA (in that order). I am querying it using the member
> pulXlate, (the flXlate flag is set to XO_TABLE). I also tried querying it
> using XLATEOBJ_cGetPalette with XO_SRCPALETTE. I get the same results.
>
> It seems to me that the palette should consist of just 2 colors (the
> bitmap
> data certainly only contains 2 different values).
>
> So I am outputting the bitmap with an incorrect palette, and the results
> are
> predictably incorrect.
>
> A competitor's printer driver, when printing the same file from the same
> application, outputs the same bitmap but with the palette consisting of
> only
> 2 colors (RGB(0,0,0) and RGB(255,255,255)).
>
> If I print to file and then edit the output of my driver, and replace the
> palette I generate with the one the competitor generates (and leave
> everything else the same), the file prints correctly.
>
> So my question is, what could be causing this and where should I look?
> How
> can I find the correct palette information for this bitmap? All the rest
> of
> the time, calling the XLATEOBJ for color information works correctly.
>
> (In EnablePDEV, I set the hpalDefault member of the DEVINFO to the result
> from EngCreatePalette(PAL_RGB, 0, 0, 0, 0, 0);)
>
> Thanks in advance,
> --
> ScottR
> Scott Robins
>

ScottRobins
Wed Oct 19 09:56:04 CDT 2005

Thanks for the reply.

But, I think the problem is more than a simple coding mistake.
I think I am not understanding something fundamental.

However, here is the code in question:

BOOL
DrvStrokePath(SURFOBJ* pso, PATHOBJ* ppo,
CLIPOBJ* pco, XFORMOBJ* pxo,
BRUSHOBJ* pbo, POINTL* pptlBrushOrg,
LINEATTRS* plineattrs, MIX mix)
{

...

ULONG ii;
if (pxlo->flXlate & XO_TABLE)
{
for (ii=0; ii<pxlo->cEntries; ii++)
{
if (pxlo->pulXlate[ii] == 0xFFFF)
{
break;
}
else
OutputColor(pxlo->pulXlate[ii]);
}
}

...

Another version used this code:
...
ULONG ii;
ULONG cPal;
ULONG pal[256];
ULONG* pPal;
pPal = &pal[0];

cPal = XLATEOBJ_cGetPalette(pxlo, XO_SRCPALETTE, 256, pPal);
if (cPal != 0)
{
for (ii=0; ii<pxlo->cEntries; ii++)
{
if (pPal[ii] == 0xFFFF)
{
break;
}
else
OutputColor(pPal[ii]);
}
}
...
("OutputColor" simply breaks the parameter apart into RGB values
and outputs it as the HP-Gl/2 command "<esc>*v<R>a<G>b<B>c<N>I".)

Thanks,

--
ScottR
Scott Robins


"Vipin[MVP]" wrote:

>
> I guess it should be the problem with the way you are translatting the
> palette.
> It works properly if properly done, I use it in my driver. And there is no
> code
> you have posted to suggest where the problem could be.
>
> --
> Vipin Aravind
> MVP [Windows - Printing/Imaging]
>

ScottRobins
Wed Oct 19 10:01:08 CDT 2005

Sorry, I am working on 2 problems at once. The code should be wrapped
in the header for DrvBitBlt, not DrvStrokePath.
--
ScottR
Scott Robins


"Scott Robins" wrote:

> Thanks for the reply.
>
> But, I think the problem is more than a simple coding mistake.
> I think I am not understanding something fundamental.
>
> However, here is the code in question:
>
> BOOL
> DrvStrokePath(SURFOBJ* pso, PATHOBJ* ppo,
> CLIPOBJ* pco, XFORMOBJ* pxo,
> BRUSHOBJ* pbo, POINTL* pptlBrushOrg,
> LINEATTRS* plineattrs, MIX mix)
> {
>
> ...
>
> ULONG ii;
> if (pxlo->flXlate & XO_TABLE)
> {
> for (ii=0; ii<pxlo->cEntries; ii++)
> {
> if (pxlo->pulXlate[ii] == 0xFFFF)
> {
> break;
> }
> else
> OutputColor(pxlo->pulXlate[ii]);
> }
> }
>
> ...
>
> Another version used this code:
> ...
> ULONG ii;
> ULONG cPal;
> ULONG pal[256];
> ULONG* pPal;
> pPal = &pal[0];
>
> cPal = XLATEOBJ_cGetPalette(pxlo, XO_SRCPALETTE, 256, pPal);
> if (cPal != 0)
> {
> for (ii=0; ii<pxlo->cEntries; ii++)
> {
> if (pPal[ii] == 0xFFFF)
> {
> break;
> }
> else
> OutputColor(pPal[ii]);
> }
> }
> ...
> ("OutputColor" simply breaks the parameter apart into RGB values
> and outputs it as the HP-Gl/2 command "<esc>*v<R>a<G>b<B>c<N>I".)
>
> Thanks,
>
> --
> ScottR
> Scott Robins
>
>
> "Vipin[MVP]" wrote:
>
> >
> > I guess it should be the problem with the way you are translatting the
> > palette.
> > It works properly if properly done, I use it in my driver. And there is no
> > code
> > you have posted to suggest where the problem could be.
> >
> > --
> > Vipin Aravind
> > MVP [Windows - Printing/Imaging]
> >
>

Vipin[MVP]
Wed Oct 19 16:30:25 CDT 2005

That doesn't look proper, if it is a PAL_INDEXED based, you should get the
vector
using XLATEOBJ_piVector and then proceed. Fundamentally you need to get hold
of
the palette vector first.

But I am still wondering what you are trying to do. Are you creating stream
for a real printer?
Then I guess you should be looking at pre-built unidrv based drivers.

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"Scott Robins" <ScottRobins@discussions.microsoft.com> wrote in message
news:F7EE6639-75BF-499F-A951-ECCF70990800@microsoft.com...
> Thanks for the reply.
>
> But, I think the problem is more than a simple coding mistake.
> I think I am not understanding something fundamental.
>
> However, here is the code in question:
>
> BOOL
> DrvStrokePath(SURFOBJ* pso, PATHOBJ* ppo,
> CLIPOBJ* pco, XFORMOBJ* pxo,
> BRUSHOBJ* pbo, POINTL* pptlBrushOrg,
> LINEATTRS* plineattrs, MIX mix)
> {
>
> ...
>
> ULONG ii;
> if (pxlo->flXlate & XO_TABLE)
> {
> for (ii=0; ii<pxlo->cEntries; ii++)
> {
> if (pxlo->pulXlate[ii] == 0xFFFF)
> {
> break;
> }
> else
> OutputColor(pxlo->pulXlate[ii]);
> }
> }
>
> ...
>
> Another version used this code:
> ...
> ULONG ii;
> ULONG cPal;
> ULONG pal[256];
> ULONG* pPal;
> pPal = &pal[0];
>
> cPal = XLATEOBJ_cGetPalette(pxlo, XO_SRCPALETTE, 256, pPal);
> if (cPal != 0)
> {
> for (ii=0; ii<pxlo->cEntries; ii++)
> {
> if (pPal[ii] == 0xFFFF)
> {
> break;
> }
> else
> OutputColor(pPal[ii]);
> }
> }
> ...
> ("OutputColor" simply breaks the parameter apart into RGB values
> and outputs it as the HP-Gl/2 command "<esc>*v<R>a<G>b<B>c<N>I".)
>
> Thanks,
>
> --
> ScottR
> Scott Robins
>
>
> "Vipin[MVP]" wrote:
>
>>
>> I guess it should be the problem with the way you are translatting the
>> palette.
>> It works properly if properly done, I use it in my driver. And there is
>> no
>> code
>> you have posted to suggest where the problem could be.
>>
>> --
>> Vipin Aravind
>> MVP [Windows - Printing/Imaging]
>>
>

ScottRobins
Thu Oct 20 12:17:02 CDT 2005

Thanks for the reply.

The pointer which XLATEOBJ_piVector returns is the same as the pulXlate
member of the XLATEOBJ, and contains the same data. Maybe I just don't
understand what I am supposed to do with this data? I've been using it as
the palette in other places and it works fine there.

My goal is to output the bitmap as HP-RTL data.

We can't use Unidrv because of several reasons. Our printer has a lot of
value-added features, Unidrv has many rendering bugs which our driver doesn't
have, Unidrv rasterizes *way* too much, and I don't know if Unidrv support
really long plots (our printer supports > 80 foot long plots).

Thanks,
--
ScottR
Scott Robins


"Vipin[MVP]" wrote:

> That doesn't look proper, if it is a PAL_INDEXED based, you should get the
> vector
> using XLATEOBJ_piVector and then proceed. Fundamentally you need to get hold
> of
> the palette vector first.
>
> But I am still wondering what you are trying to do. Are you creating stream
> for a real printer?
> Then I guess you should be looking at pre-built unidrv based drivers.
>
> --
> Vipin Aravind
> MVP [Windows - Printing/Imaging]
>

Vipin[MVP]
Fri Oct 21 16:39:53 CDT 2005

It should be working fine if you translate the palette and then retreive the
palette.Please refer ddk for details. Can you tell the application name and
probably the sample file,so I can tell you what exatly is the palette for
the bitmap?

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"Scott Robins" <ScottRobins@discussions.microsoft.com> wrote in message
news:F272015B-F25B-4D03-9F7B-0F3830BA5B24@microsoft.com...
> Sorry, I am working on 2 problems at once. The code should be wrapped
> in the header for DrvBitBlt, not DrvStrokePath.
> --
> ScottR
> Scott Robins
>
>
> "Scott Robins" wrote:
>
>> Thanks for the reply.
>>
>> But, I think the problem is more than a simple coding mistake.
>> I think I am not understanding something fundamental.
>>
>> However, here is the code in question:
>>
>> BOOL
>> DrvStrokePath(SURFOBJ* pso, PATHOBJ* ppo,
>> CLIPOBJ* pco, XFORMOBJ* pxo,
>> BRUSHOBJ* pbo, POINTL* pptlBrushOrg,
>> LINEATTRS* plineattrs, MIX mix)
>> {
>>
>> ...
>>
>> ULONG ii;
>> if (pxlo->flXlate & XO_TABLE)
>> {
>> for (ii=0; ii<pxlo->cEntries; ii++)
>> {
>> if (pxlo->pulXlate[ii] == 0xFFFF)
>> {
>> break;
>> }
>> else
>> OutputColor(pxlo->pulXlate[ii]);
>> }
>> }
>>
>> ...
>>
>> Another version used this code:
>> ...
>> ULONG ii;
>> ULONG cPal;
>> ULONG pal[256];
>> ULONG* pPal;
>> pPal = &pal[0];
>>
>> cPal = XLATEOBJ_cGetPalette(pxlo, XO_SRCPALETTE, 256, pPal);
>> if (cPal != 0)
>> {
>> for (ii=0; ii<pxlo->cEntries; ii++)
>> {
>> if (pPal[ii] == 0xFFFF)
>> {
>> break;
>> }
>> else
>> OutputColor(pPal[ii]);
>> }
>> }
>> ...
>> ("OutputColor" simply breaks the parameter apart into RGB values
>> and outputs it as the HP-Gl/2 command "<esc>*v<R>a<G>b<B>c<N>I".)
>>
>> Thanks,
>>
>> --
>> ScottR
>> Scott Robins
>>
>>
>> "Vipin[MVP]" wrote:
>>
>> >
>> > I guess it should be the problem with the way you are translatting the
>> > palette.
>> > It works properly if properly done, I use it in my driver. And there is
>> > no
>> > code
>> > you have posted to suggest where the problem could be.
>> >
>> > --
>> > Vipin Aravind
>> > MVP [Windows - Printing/Imaging]
>> >
>>