I am confused about how to use the bBlankBand variable in the
ImageProcessing function. When the print driver is banding, bBlankBand
will be 1 for the first band and then 0 for the remaining bands. The
documentation says that if it is 0 then the data is invalid. But I
never receive any further calls to ImagePricessing with bBlankBand set
to 1. As a result I only get the top portion of the image. Do I have to
do something else to get the remaining bands rendered? I am using the
oemdll example in the DDK. When the driver is not banding then I get
the whole image in one shot but higher DPI's force me to deal with
banding in ImageProcessing which I can't seem to get to function
correctly.

Thanks,
Bob Herzberg

Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Tue Jan 11 17:17:28 CST 2005

From the Windows 2000 DDK:

"However if a region is blank, the bBlankBand member of the IPPARAMS
structure will be TRUE, which indicates the block is blank and the data is
invalid. "

Below you say that "if it is 0 then the data is invalid", but that is the
opposite of what the DDK says.

If bBlankBand == 0, then the band being passed to you is NOT blank, so the
data IS valid.

If bBlankBand != 0, then the band being passed to you IS blank, so the data
is NOT valid.


"Orbian" <orbian123@hotmail.com> wrote in message
news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> I am confused about how to use the bBlankBand variable in the
> ImageProcessing function. When the print driver is banding, bBlankBand
> will be 1 for the first band and then 0 for the remaining bands. The
> documentation says that if it is 0 then the data is invalid. But I
> never receive any further calls to ImagePricessing with bBlankBand set
> to 1. As a result I only get the top portion of the image. Do I have to
> do something else to get the remaining bands rendered? I am using the
> oemdll example in the DDK. When the driver is not banding then I get
> the whole image in one shot but higher DPI's force me to deal with
> banding in ImageProcessing which I can't seem to get to function
> correctly.
>
> Thanks,
> Bob Herzberg
>



Re: UNIDRV IOemUni::ImageProcessing Question by Orbian

Orbian
Tue Jan 11 17:58:09 CST 2005

Sorry, I miss-typed my post. I accept the bitmap when bBlankBand is 0
and ignore it when it is 1. But I still only get the first valid band.
What follows is a series of call to ImageProcessing with bBlankBand =1.
I never see another call where bBlankBand =0. So I only get part of the
image. There must be some trick to getting more bands with bBlankBand
set to 0. Any ideas?

Thank you,
Bob Herzberg


Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Tue Jan 11 19:07:06 CST 2005

Too bad it was not that simple!!

Are you returning S_OK and setting the result-pointer to TRUE?



"Orbian" <orbian123@hotmail.com> wrote in message
news:1105487889.252985.241140@z14g2000cwz.googlegroups.com...
> Sorry, I miss-typed my post. I accept the bitmap when bBlankBand is 0
> and ignore it when it is 1. But I still only get the first valid band.
> What follows is a series of call to ImageProcessing with bBlankBand =1.
> I never see another call where bBlankBand =0. So I only get part of the
> image. There must be some trick to getting more bands with bBlankBand
> set to 0. Any ideas?
>
> Thank you,
> Bob Herzberg
>



Re: UNIDRV IOemUni::ImageProcessing Question by Orbian

Orbian
Tue Jan 11 19:30:26 CST 2005

Simple solutions seem to evade me... ;( I do return S_OK. By
result-pointer do you mean ppbResult? I set that to pSrcBitmap because
I didn't have any other bitmap to point to and the documentation states
to set to a valid bitmap.

Thank you,
Bob Herzberg


Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Tue Jan 11 20:03:22 CST 2005

The ppbResult parameter to ImageProcessing() receives either the pSrcBitmap,
NULL, TRUE or FALSE, depending on what else you do. If you are writing the
data to the spooler, you should be returning TRUE via *ppbResult =
IntToPtr(TRUE).




"Orbian" <orbian123@hotmail.com> wrote in message
news:1105493426.352658.8880@z14g2000cwz.googlegroups.com...
> Simple solutions seem to evade me... ;( I do return S_OK. By
> result-pointer do you mean ppbResult? I set that to pSrcBitmap because
> I didn't have any other bitmap to point to and the documentation states
> to set to a valid bitmap.
>
> Thank you,
> Bob Herzberg
>



Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Tue Jan 11 20:08:03 CST 2005

I think that if you do not set ppbResult = IntToPtr(TRUE) and instead set it
to pSrcBitmap, then UNIDRV interprets that to mean that you are not going to
perform any conversion, and so it does not send you any more data.


"Orbian" <orbian123@hotmail.com> wrote in message
news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> I am confused about how to use the bBlankBand variable in the
> ImageProcessing function. When the print driver is banding, bBlankBand
> will be 1 for the first band and then 0 for the remaining bands. The
> documentation says that if it is 0 then the data is invalid. But I
> never receive any further calls to ImagePricessing with bBlankBand set
> to 1. As a result I only get the top portion of the image. Do I have to
> do something else to get the remaining bands rendered? I am using the
> oemdll example in the DDK. When the driver is not banding then I get
> the whole image in one shot but higher DPI's force me to deal with
> banding in ImageProcessing which I can't seem to get to function
> correctly.
>
> Thanks,
> Bob Herzberg
>



Re: UNIDRV IOemUni::ImageProcessing Question by Orbian

Orbian
Wed Jan 12 14:40:44 CST 2005

Thanks Bart,

I set ppbResult to TRUE which seems to get more bands now. Problem
is in order to get this to work I have to set *DevNumOfPlanes: 0 and
*DevBPP: 0 in the GPD file. But when I do this the images at 150 DPI
come out complete but the vertical spacing is wrong. When its at 300
DPI I usually only get part of the image. Its like it prints the first
bitmap on the page and then gives up at 300 DPI. I was under the
impression that ImageProcessing got the whole image and I could dump it
out there. But at high resolutions only part of the page gets sent. Am
I supposed to assemble the image somehow? I can understand just
appending bands to a file but assembling individual parts of the image
doen't seem correct.

Initially I had set *DevNumOfPlanes: 3 and *DevBPP: 24 in my GPD
file. Jobs at 150 DPI would print in one band and be dimensionally
correct. At 300 DPI I would get banding and then that's where my
probelms started. Changing *DevNumOfPlanes: 0 and *DevBPP: 0 gets me
more bands but the images aren't correct. I really wish MS had a simple
dump to bitmap file example. That's all I really need to do. I don't
want to do any real rendering myself or processing in the driver.
Apparently they had an example for Windows 95 but I need XP. Maybe that
example will show how I can do the banding correctly but I am totally
confused by the driver architecture at this point.


Thanks



Bart Crane wrote:
> I think that if you do not set ppbResult = IntToPtr(TRUE) and instead
set it
> to pSrcBitmap, then UNIDRV interprets that to mean that you are not
going to
> perform any conversion, and so it does not send you any more data.
>
>
> "Orbian" <orbian123@hotmail.com> wrote in message
> news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> > I am confused about how to use the bBlankBand variable in the
> > ImageProcessing function. When the print driver is banding,
bBlankBand
> > will be 1 for the first band and then 0 for the remaining bands.
The
> > documentation says that if it is 0 then the data is invalid. But I
> > never receive any further calls to ImagePricessing with bBlankBand
set
> > to 1. As a result I only get the top portion of the image. Do I
have to
> > do something else to get the remaining bands rendered? I am using
the
> > oemdll example in the DDK. When the driver is not banding then I
get
> > the whole image in one shot but higher DPI's force me to deal with
> > banding in ImageProcessing which I can't seem to get to function
> > correctly.
> >
> > Thanks,
> > Bob Herzberg
> >


Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Wed Jan 12 15:19:11 CST 2005

If you specify more than one color plane, then you also specify the order in
which the color-planes are to be sent. Could it have been that UNIDRV was
setting bBlankBand=TRUE because for that particular color-plane there was no
data?

Setting DevBPP and DevNumOfPlanes to 0 and DrvBPP to 24 should get you a
BMP-ready (24-bit) stream of data. Just keep setting
ppbResult=IntToPtr(TRUE), and ImageProcessing() should keep getting called.
If UNIDRV sends data with bBlankBand=TRUE, you still use the
pBitmapInfoHeader->biHeight (or biWidth for portrait-mode) to do the
vertical spacing.


"Orbian" <orbian123@hotmail.com> wrote in message
news:1105562444.457532.48600@f14g2000cwb.googlegroups.com...
> Thanks Bart,
>
> I set ppbResult to TRUE which seems to get more bands now. Problem
> is in order to get this to work I have to set *DevNumOfPlanes: 0 and
> *DevBPP: 0 in the GPD file. But when I do this the images at 150 DPI
> come out complete but the vertical spacing is wrong. When its at 300
> DPI I usually only get part of the image. Its like it prints the first
> bitmap on the page and then gives up at 300 DPI. I was under the
> impression that ImageProcessing got the whole image and I could dump it
> out there. But at high resolutions only part of the page gets sent. Am
> I supposed to assemble the image somehow? I can understand just
> appending bands to a file but assembling individual parts of the image
> doen't seem correct.
>
> Initially I had set *DevNumOfPlanes: 3 and *DevBPP: 24 in my GPD
> file. Jobs at 150 DPI would print in one band and be dimensionally
> correct. At 300 DPI I would get banding and then that's where my
> probelms started. Changing *DevNumOfPlanes: 0 and *DevBPP: 0 gets me
> more bands but the images aren't correct. I really wish MS had a simple
> dump to bitmap file example. That's all I really need to do. I don't
> want to do any real rendering myself or processing in the driver.
> Apparently they had an example for Windows 95 but I need XP. Maybe that
> example will show how I can do the banding correctly but I am totally
> confused by the driver architecture at this point.
>
>
> Thanks
>
>
>
> Bart Crane wrote:
> > I think that if you do not set ppbResult = IntToPtr(TRUE) and instead
> set it
> > to pSrcBitmap, then UNIDRV interprets that to mean that you are not
> going to
> > perform any conversion, and so it does not send you any more data.
> >
> >
> > "Orbian" <orbian123@hotmail.com> wrote in message
> > news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> > > I am confused about how to use the bBlankBand variable in the
> > > ImageProcessing function. When the print driver is banding,
> bBlankBand
> > > will be 1 for the first band and then 0 for the remaining bands.
> The
> > > documentation says that if it is 0 then the data is invalid. But I
> > > never receive any further calls to ImagePricessing with bBlankBand
> set
> > > to 1. As a result I only get the top portion of the image. Do I
> have to
> > > do something else to get the remaining bands rendered? I am using
> the
> > > oemdll example in the DDK. When the driver is not banding then I
> get
> > > the whole image in one shot but higher DPI's force me to deal with
> > > banding in ImageProcessing which I can't seem to get to function
> > > correctly.
> > >
> > > Thanks,
> > > Bob Herzberg
> > >
>



Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Wed Jan 12 15:35:21 CST 2005

Maybe you should use the FilterGraphics method instead of ImageProcessing.
Set DevBPP=24 and DevNumOfPlanes=1 and UNIDRV will do all the rendering, and
then it will call your FilterGraphics instead of writing it to the spooler.
(But I am not an expert at this...)

"Orbian" <orbian123@hotmail.com> wrote in message
news:1105562444.457532.48600@f14g2000cwb.googlegroups.com...
> Thanks Bart,
>
> I set ppbResult to TRUE which seems to get more bands now. Problem
> is in order to get this to work I have to set *DevNumOfPlanes: 0 and
> *DevBPP: 0 in the GPD file. But when I do this the images at 150 DPI
> come out complete but the vertical spacing is wrong. When its at 300
> DPI I usually only get part of the image. Its like it prints the first
> bitmap on the page and then gives up at 300 DPI. I was under the
> impression that ImageProcessing got the whole image and I could dump it
> out there. But at high resolutions only part of the page gets sent. Am
> I supposed to assemble the image somehow? I can understand just
> appending bands to a file but assembling individual parts of the image
> doen't seem correct.
>
> Initially I had set *DevNumOfPlanes: 3 and *DevBPP: 24 in my GPD
> file. Jobs at 150 DPI would print in one band and be dimensionally
> correct. At 300 DPI I would get banding and then that's where my
> probelms started. Changing *DevNumOfPlanes: 0 and *DevBPP: 0 gets me
> more bands but the images aren't correct. I really wish MS had a simple
> dump to bitmap file example. That's all I really need to do. I don't
> want to do any real rendering myself or processing in the driver.
> Apparently they had an example for Windows 95 but I need XP. Maybe that
> example will show how I can do the banding correctly but I am totally
> confused by the driver architecture at this point.
>
>
> Thanks
>
>
>
> Bart Crane wrote:
> > I think that if you do not set ppbResult = IntToPtr(TRUE) and instead
> set it
> > to pSrcBitmap, then UNIDRV interprets that to mean that you are not
> going to
> > perform any conversion, and so it does not send you any more data.
> >
> >
> > "Orbian" <orbian123@hotmail.com> wrote in message
> > news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> > > I am confused about how to use the bBlankBand variable in the
> > > ImageProcessing function. When the print driver is banding,
> bBlankBand
> > > will be 1 for the first band and then 0 for the remaining bands.
> The
> > > documentation says that if it is 0 then the data is invalid. But I
> > > never receive any further calls to ImagePricessing with bBlankBand
> set
> > > to 1. As a result I only get the top portion of the image. Do I
> have to
> > > do something else to get the remaining bands rendered? I am using
> the
> > > oemdll example in the DDK. When the driver is not banding then I
> get
> > > the whole image in one shot but higher DPI's force me to deal with
> > > banding in ImageProcessing which I can't seem to get to function
> > > correctly.
> > >
> > > Thanks,
> > > Bob Herzberg
> > >
>



Re: UNIDRV IOemUni::ImageProcessing Question by Bart

Bart
Wed Jan 12 16:00:25 CST 2005

... making sure that you have not set the GCAPS_CMYKCOLOR in DEVINFO...

"Bart Crane" <bart.crane@bil.konicaminolta.us> wrote in message
news:uZBqw6O#EHA.3840@tk2msftngp13.phx.gbl...
> Maybe you should use the FilterGraphics method instead of ImageProcessing.
> Set DevBPP=24 and DevNumOfPlanes=1 and UNIDRV will do all the rendering,
and
> then it will call your FilterGraphics instead of writing it to the
spooler.
> (But I am not an expert at this...)
>
> "Orbian" <orbian123@hotmail.com> wrote in message
> news:1105562444.457532.48600@f14g2000cwb.googlegroups.com...
> > Thanks Bart,
> >
> > I set ppbResult to TRUE which seems to get more bands now. Problem
> > is in order to get this to work I have to set *DevNumOfPlanes: 0 and
> > *DevBPP: 0 in the GPD file. But when I do this the images at 150 DPI
> > come out complete but the vertical spacing is wrong. When its at 300
> > DPI I usually only get part of the image. Its like it prints the first
> > bitmap on the page and then gives up at 300 DPI. I was under the
> > impression that ImageProcessing got the whole image and I could dump it
> > out there. But at high resolutions only part of the page gets sent. Am
> > I supposed to assemble the image somehow? I can understand just
> > appending bands to a file but assembling individual parts of the image
> > doen't seem correct.
> >
> > Initially I had set *DevNumOfPlanes: 3 and *DevBPP: 24 in my GPD
> > file. Jobs at 150 DPI would print in one band and be dimensionally
> > correct. At 300 DPI I would get banding and then that's where my
> > probelms started. Changing *DevNumOfPlanes: 0 and *DevBPP: 0 gets me
> > more bands but the images aren't correct. I really wish MS had a simple
> > dump to bitmap file example. That's all I really need to do. I don't
> > want to do any real rendering myself or processing in the driver.
> > Apparently they had an example for Windows 95 but I need XP. Maybe that
> > example will show how I can do the banding correctly but I am totally
> > confused by the driver architecture at this point.
> >
> >
> > Thanks
> >
> >
> >
> > Bart Crane wrote:
> > > I think that if you do not set ppbResult = IntToPtr(TRUE) and instead
> > set it
> > > to pSrcBitmap, then UNIDRV interprets that to mean that you are not
> > going to
> > > perform any conversion, and so it does not send you any more data.
> > >
> > >
> > > "Orbian" <orbian123@hotmail.com> wrote in message
> > > news:1105473723.915219.172670@c13g2000cwb.googlegroups.com...
> > > > I am confused about how to use the bBlankBand variable in the
> > > > ImageProcessing function. When the print driver is banding,
> > bBlankBand
> > > > will be 1 for the first band and then 0 for the remaining bands.
> > The
> > > > documentation says that if it is 0 then the data is invalid. But I
> > > > never receive any further calls to ImagePricessing with bBlankBand
> > set
> > > > to 1. As a result I only get the top portion of the image. Do I
> > have to
> > > > do something else to get the remaining bands rendered? I am using
> > the
> > > > oemdll example in the DDK. When the driver is not banding then I
> > get
> > > > the whole image in one shot but higher DPI's force me to deal with
> > > > banding in ImageProcessing which I can't seem to get to function
> > > > correctly.
> > > >
> > > > Thanks,
> > > > Bob Herzberg
> > > >
> >
>
>