UNIDRV Banding Line Count error?

Hello,
I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
24.) The conversion itself works fine, *except*:
when UNIDRV is doing banding, if the last band is shorter than
the previous bands, the difference (in lines) is added to the print as
garbage raster data.
E.G: for a 3300 line Letter page:
ImageProcessing reports 4 x bands of 664 lines, then one of 644.
What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
of garbage.
For a 3750 line page:
ImageProcessing reports 4 x bands of 752 lines, then one of 742.
The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.

It *looks* like when Unidrv splits the page into bands, it's not
tracking the actual count when passing the bands to Output.

Comments? Suggestions??
I'd rather not do the compression and output
to spooler myself, if there's a known fix for this issue.
Thanks! -- Joe C.

--
J.C.

bobbym
Mon Oct 17 19:38:04 CDT 2005

------=_NextPart_0001_1AA8BC33
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


J.C,
I am not aware of any bugs in the unidrv banding code.
It is very unlikely (we would have heard about it long back)
Can you make sure you have read and followed comments section in the ddk
docs on "ImageProcessing
"?
Also look at the bitmap sample on server 2003 ddk to see an implementation
of imageprocessing.

Hope this helps.

Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Thread-Topic: UNIDRV Banding Line Count error?


Hello,
I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
24.) The conversion itself works fine, *except*:
when UNIDRV is doing banding, if the last band is shorter than
the previous bands, the difference (in lines) is added to the print as
garbage raster data.
E.G: for a 3300 line Letter page:
ImageProcessing reports 4 x bands of 664 lines, then one of 644.
What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
of garbage.
For a 3750 line page:
ImageProcessing reports 4 x bands of 752 lines, then one of 742.
The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.

It *looks* like when Unidrv splits the page into bands, it's not
tracking the actual count when passing the bands to Output.

Comments? Suggestions??
I'd rather not do the compression and output
to spooler myself, if there's a known fix for this issue.
Thanks! -- Joe C.

--
J.C.

------=_NextPart_0001_1AA8BC33
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par \pard\li720 J.C,
\par I am not aware of any bugs in the unidrv banding code.
\par It is very unlikely (we would have heard about it long back)
\par Can you make sure you have read and followed comments section in the ddk docs on "ImageProcessing
\par "?
\par Also look at the bitmap sample on server 2003 ddk to see an implementation of imageprocessing.
\par
\par Hope this helps.
\par
\par Thank you,
\par Bobby Mattappally
\par Microsoft
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par --------------------
\par Thread-Topic: UNIDRV Banding Line Count error?
\par
\par
\par Hello,
\par I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
\par custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
\par 24.) The conversion itself works fine, *except*:
\par when UNIDRV is doing banding, if the last band is shorter than
\par the previous bands, the difference (in lines) is added to the print as
\par garbage raster data.
\par E.G: for a 3300 line Letter page:
\par ImageProcessing reports 4 x bands of 664 lines, then one of 644.
\par What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
\par of garbage.
\par For a 3750 line page:
\par ImageProcessing reports 4 x bands of 752 lines, then one of 742.
\par The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
\par
\par It *looks* like when Unidrv splits the page into bands, it's not
\par tracking the actual count when passing the bands to Output.
\par
\par Comments? Suggestions??
\par I'd rather not do the compression and output
\par to spooler myself, if there's a known fix for this issue.
\par Thanks! -- Joe C.
\par
\par --
\par J.C.
\par \pard
\par
\par }
------=_NextPart_0001_1AA8BC33--

JLC
Tue Oct 18 20:14:03 CDT 2005


--
J.C.


"Bobby Mattappally [MS]" wrote:

>
> J.C,
> I am not aware of any bugs in the unidrv banding code.
> It is very unlikely (we would have heard about it long back)
> Can you make sure you have read and followed comments section in the ddk
> docs on "ImageProcessing
> "?
> Also look at the bitmap sample on server 2003 ddk to see an implementation
> of imageprocessing.
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> --------------------
> Thread-Topic: UNIDRV Banding Line Count error?
>
>
> Hello,
> I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> 24.) The conversion itself works fine, *except*:
> when UNIDRV is doing banding, if the last band is shorter than
> the previous bands, the difference (in lines) is added to the print as
> garbage raster data.
> E.G: for a 3300 line Letter page:
> ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
> of garbage.
> For a 3750 line page:
> ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
>
> It *looks* like when Unidrv splits the page into bands, it's not
> tracking the actual count when passing the bands to Output.
>
> Comments? Suggestions??
> I'd rather not do the compression and output
> to spooler myself, if there's a known fix for this issue.
> Thanks! -- Joe C.
>
> --
> J.C

JLC
Wed Oct 19 11:20:07 CDT 2005

Bobby,
Many thanks for the reply:
I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
I will take a look at the server 2003 example, as you suggest.

This problem is a little surprising, since we've got ImageProcessing() code
for 1BPP and 8BPP, that has no banding problems of this kind: this has been
released for a few years. Maybe the 4 planes / 1BPP is a special case?

One approach that has **almost** worked:
1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
2. In OEMStartDoc, save the band length to OEMPDEV.
3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
If the end of the current band will overshoot the saved page length,
change pso->sizelBitmap->cy to the size that will match the end of page.
4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved initial

bandsize, and reset it if necessary.

This has eliminated the extra garbage data, but I'm now 1 pixel short /
page....
Thanks again for the suggestions--
Joe C.
--
J.C.


"JLC" wrote:

>
> --
> J.C.
>
>
> "Bobby Mattappally [MS]" wrote:
>
> >
> > J.C,
> > I am not aware of any bugs in the unidrv banding code.
> > It is very unlikely (we would have heard about it long back)
> > Can you make sure you have read and followed comments section in the ddk
> > docs on "ImageProcessing
> > "?
> > Also look at the bitmap sample on server 2003 ddk to see an implementation
> > of imageprocessing.
> >
> > Hope this helps.
> >
> > Thank you,
> > Bobby Mattappally
> > Microsoft
> >
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> >
> > --------------------
> > Thread-Topic: UNIDRV Banding Line Count error?
> >
> >
> > Hello,
> > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> > 24.) The conversion itself works fine, *except*:
> > when UNIDRV is doing banding, if the last band is shorter than
> > the previous bands, the difference (in lines) is added to the print as
> > garbage raster data.
> > E.G: for a 3300 line Letter page:
> > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> > What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
> > of garbage.
> > For a 3750 line page:
> > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
> >
> > It *looks* like when Unidrv splits the page into bands, it's not
> > tracking the actual count when passing the bands to Output.
> >
> > Comments? Suggestions??
> > I'd rather not do the compression and output
> > to spooler myself, if there's a known fix for this issue.
> > Thanks! -- Joe C.
> >
> > --
> > J.C

JLC
Wed Oct 19 11:38:05 CDT 2005

Um, that's DDK ** 3790 ** .

--
J.C.


"JLC" wrote:

> Bobby,
> Many thanks for the reply:
> I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
> I will take a look at the server 2003 example, as you suggest.
>
> This problem is a little surprising, since we've got ImageProcessing() code
> for 1BPP and 8BPP, that has no banding problems of this kind: this has been
> released for a few years. Maybe the 4 planes / 1BPP is a special case?
>
> One approach that has **almost** worked:
> 1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
> 2. In OEMStartDoc, save the band length to OEMPDEV.
> 3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
> If the end of the current band will overshoot the saved page length,
> change pso->sizelBitmap->cy to the size that will match the end of page.
> 4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved initial
>
> bandsize, and reset it if necessary.
>
> This has eliminated the extra garbage data, but I'm now 1 pixel short /
> page....
> Thanks again for the suggestions--
> Joe C.
> --
> J.C.
>
>
> "JLC" wrote:
>
> >
> > --
> > J.C.
> >
> >
> > "Bobby Mattappally [MS]" wrote:
> >
> > >
> > > J.C,
> > > I am not aware of any bugs in the unidrv banding code.
> > > It is very unlikely (we would have heard about it long back)
> > > Can you make sure you have read and followed comments section in the ddk
> > > docs on "ImageProcessing
> > > "?
> > > Also look at the bitmap sample on server 2003 ddk to see an implementation
> > > of imageprocessing.
> > >
> > > Hope this helps.
> > >
> > > Thank you,
> > > Bobby Mattappally
> > > Microsoft
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > >
> > > --------------------
> > > Thread-Topic: UNIDRV Banding Line Count error?
> > >
> > >
> > > Hello,
> > > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> > > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> > > 24.) The conversion itself works fine, *except*:
> > > when UNIDRV is doing banding, if the last band is shorter than
> > > the previous bands, the difference (in lines) is added to the print as
> > > garbage raster data.
> > > E.G: for a 3300 line Letter page:
> > > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> > > What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
> > > of garbage.
> > > For a 3750 line page:
> > > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> > > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
> > >
> > > It *looks* like when Unidrv splits the page into bands, it's not
> > > tracking the actual count when passing the bands to Output.
> > >
> > > Comments? Suggestions??
> > > I'd rather not do the compression and output
> > > to spooler myself, if there's a known fix for this issue.
> > > Thanks! -- Joe C.
> > >
> > > --
> > > J.C

JLC
Wed Oct 19 12:31:05 CDT 2005

Sorry for the endless follow-ons:
We *did* have this issue before, on an experimental 8BPP-> 1BPP
ImageProcessing callback, and I had to compress/spool the data myself.
Less than 18 months ago, no less, and I'd posted to this group.
Time for a new pot of coffee....
------------------------------------------
The question at hand then, is:

If the bands are being set up as small working surfaces,
*how* is the mismatch of the sum-of-band size to page size handled in UNIDRV?
In ImageProcessing, the bitmap for each band *is* accurately sized, to end
at the
end of the page.
The *surface*, however, in NextBand, is always the *same* size,
and that size is what is passed on to compression / spooling. This results
in garbage data in the output on the last band, since the bitmap area is
shorter.

Is it the *bitmap* height, or the *surface* height that is being passed
downstream for output by UNIDRV?

I'm not sure *what* I can do to control this behavior in a documented way--
any suggestions would be greatly appreciated.

Thanks again!


--
J.C.


"JLC" wrote:

> Um, that's DDK ** 3790 ** .
>
> --
> J.C.
>
>
> "JLC" wrote:
>
> > Bobby,
> > Many thanks for the reply:
> > I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
> > I will take a look at the server 2003 example, as you suggest.
> >
> > This problem is a little surprising, since we've got ImageProcessing() code
> > for 1BPP and 8BPP, that has no banding problems of this kind: this has been
> > released for a few years. Maybe the 4 planes / 1BPP is a special case?
> >
> > One approach that has **almost** worked:
> > 1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
> > 2. In OEMStartDoc, save the band length to OEMPDEV.
> > 3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
> > If the end of the current band will overshoot the saved page length,
> > change pso->sizelBitmap->cy to the size that will match the end of page.
> > 4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved initial
> >
> > bandsize, and reset it if necessary.
> >
> > This has eliminated the extra garbage data, but I'm now 1 pixel short /
> > page....
> > Thanks again for the suggestions--
> > Joe C.
> > --
> > J.C.
> >
> >
> > "JLC" wrote:
> >
> > >
> > > --
> > > J.C.
> > >
> > >
> > > "Bobby Mattappally [MS]" wrote:
> > >
> > > >
> > > > J.C,
> > > > I am not aware of any bugs in the unidrv banding code.
> > > > It is very unlikely (we would have heard about it long back)
> > > > Can you make sure you have read and followed comments section in the ddk
> > > > docs on "ImageProcessing
> > > > "?
> > > > Also look at the bitmap sample on server 2003 ddk to see an implementation
> > > > of imageprocessing.
> > > >
> > > > Hope this helps.
> > > >
> > > > Thank you,
> > > > Bobby Mattappally
> > > > Microsoft
> > > >
> > > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > > >
> > > > --------------------
> > > > Thread-Topic: UNIDRV Banding Line Count error?
> > > >
> > > >
> > > > Hello,
> > > > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> > > > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> > > > 24.) The conversion itself works fine, *except*:
> > > > when UNIDRV is doing banding, if the last band is shorter than
> > > > the previous bands, the difference (in lines) is added to the print as
> > > > garbage raster data.
> > > > E.G: for a 3300 line Letter page:
> > > > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> > > > What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
> > > > of garbage.
> > > > For a 3750 line page:
> > > > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> > > > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
> > > >
> > > > It *looks* like when Unidrv splits the page into bands, it's not
> > > > tracking the actual count when passing the bands to Output.
> > > >
> > > > Comments? Suggestions??
> > > > I'd rather not do the compression and output
> > > > to spooler myself, if there's a known fix for this issue.
> > > > Thanks! -- Joe C.
> > > >
> > > > --
> > > > J.C

bobbym
Wed Oct 19 19:16:24 CDT 2005

------=_NextPart_0001_24F00593
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi JlC,

Unidrv is doing something similar to what you mentioned in the previous
message.
It checks (in the DrvNextBand) to make sure the band doesn't shoot over the
printable area and then adjusts the clipping to the bottom of the image
area in that scenario. Are you trying to implement NextBand on your own and
not calling back into unidrv's NextBand function?
Then you would have to do something similar.



Hope this helps.

Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.



--------------------
Thread-Topic: UNIDRV Banding Line Count error?
thread-index: AcXU0uJsRaNqauvWR5iB5DCky2ogsQ==
X-WBNR-Posting-Host: 208.37.22.158


Sorry for the endless follow-ons:
We *did* have this issue before, on an experimental 8BPP-> 1BPP
ImageProcessing callback, and I had to compress/spool the data myself.
Less than 18 months ago, no less, and I'd posted to this group.
Time for a new pot of coffee....
------------------------------------------
The question at hand then, is:

If the bands are being set up as small working surfaces,
*how* is the mismatch of the sum-of-band size to page size handled in
UNIDRV?
In ImageProcessing, the bitmap for each band *is* accurately sized, to end
at the
end of the page.
The *surface*, however, in NextBand, is always the *same* size,
and that size is what is passed on to compression / spooling. This results
in garbage data in the output on the last band, since the bitmap area is
shorter.

Is it the *bitmap* height, or the *surface* height that is being passed
downstream for output by UNIDRV?

I'm not sure *what* I can do to control this behavior in a documented way--
any suggestions would be greatly appreciated.

Thanks again!


--
J.C.


"JLC" wrote:

> Um, that's DDK ** 3790 ** .
>
> --
> J.C.
>
>
> "JLC" wrote:
>
> > Bobby,
> > Many thanks for the reply:
> > I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
> > I will take a look at the server 2003 example, as you suggest.
> >
> > This problem is a little surprising, since we've got ImageProcessing()
code
> > for 1BPP and 8BPP, that has no banding problems of this kind: this has
been
> > released for a few years. Maybe the 4 planes / 1BPP is a special case?
> >
> > One approach that has **almost** worked:
> > 1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
> > 2. In OEMStartDoc, save the band length to OEMPDEV.
> > 3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
> > If the end of the current band will overshoot the saved page length,
> > change pso->sizelBitmap->cy to the size that will match the end of
page.
> > 4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved
initial
> >
> > bandsize, and reset it if necessary.
> >
> > This has eliminated the extra garbage data, but I'm now 1 pixel short /
> > page....
> > Thanks again for the suggestions--
> > Joe C.
> > --
> > J.C.
> >
> >
> > "JLC" wrote:
> >
> > >
> > > --
> > > J.C.
> > >
> > >
> > > "Bobby Mattappally [MS]" wrote:
> > >
> > > >
> > > > J.C,
> > > > I am not aware of any bugs in the unidrv banding code.
> > > > It is very unlikely (we would have heard about it long back)
> > > > Can you make sure you have read and followed comments section in
the ddk
> > > > docs on "ImageProcessing
> > > > "?
> > > > Also look at the bitmap sample on server 2003 ddk to see an
implementation
> > > > of imageprocessing.
> > > >
> > > > Hope this helps.
> > > >
> > > > Thank you,
> > > > Bobby Mattappally
> > > > Microsoft
> > > >
> > > > This posting is provided "AS IS" with no warranties, and confers no
rights.
> > > >
> > > > --------------------
> > > > Thread-Topic: UNIDRV Banding Line Count error?
> > > >
> > > >
> > > > Hello,
> > > > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> > > > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> > > > 24.) The conversion itself works fine, *except*:
> > > > when UNIDRV is doing banding, if the last band is shorter than
> > > > the previous bands, the difference (in lines) is added to the print
as
> > > > garbage raster data.
> > > > E.G: for a 3300 line Letter page:
> > > > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> > > > What is printed is the 3300 lines expected, plus (664 - 644 =)20
lines
> > > > of garbage.
> > > > For a 3750 line page:
> > > > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> > > > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
> > > >
> > > > It *looks* like when Unidrv splits the page into bands, it's not
> > > > tracking the actual count when passing the bands to Output.
> > > >
> > > > Comments? Suggestions??
> > > > I'd rather not do the compression and output
> > > > to spooler myself, if there's a known fix for this issue.
> > > > Thanks! -- Joe C.
> > > >
> > > > --
> > > > J.C

------=_NextPart_0001_24F00593
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Hi JlC,
\par
\par Unidrv is doing something similar to what you mentioned in the previous message.
\par It checks (in the DrvNextBand) to make sure the band doesn't shoot over the printable area and then adjusts the clipping to the bottom of the image area in that scenario. Are you trying to implement NextBand on your own and not calling back into unidrv's NextBand function?
\par Then you would have to do something similar.
\par
\par
\par
\par Hope this helps.
\par
\par Thank you,
\par Bobby Mattappally
\par Microsoft
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par \pard\li720 --------------------
\par Thread-Topic: UNIDRV Banding Line Count error?
\par thread-index: AcXU0uJsRaNqauvWR5iB5DCky2ogsQ==
\par X-WBNR-Posting-Host: 208.37.22.158
\par
\par
\par Sorry for the endless follow-ons:
\par We *did* have this issue before, on an experimental 8BPP-> 1BPP
\par ImageProcessing callback, and I had to compress/spool the data myself.
\par Less than 18 months ago, no less, and I'd posted to this group.
\par Time for a new pot of coffee....
\par ------------------------------------------
\par The question at hand then, is:
\par
\par If the bands are being set up as small working surfaces,
\par *how* is the mismatch of the sum-of-band size to page size handled in UNIDRV?
\par In ImageProcessing, the bitmap for each band *is* accurately sized, to end
\par at the
\par end of the page.
\par The *surface*, however, in NextBand, is always the *same* size,
\par and that size is what is passed on to compression / spooling. This results
\par in garbage data in the output on the last band, since the bitmap area is
\par shorter.
\par
\par Is it the *bitmap* height, or the *surface* height that is being passed
\par downstream for output by UNIDRV?
\par
\par I'm not sure *what* I can do to control this behavior in a documented way--
\par any suggestions would be greatly appreciated.
\par
\par Thanks again!
\par
\par
\par --
\par J.C.
\par
\par
\par "JLC" wrote:
\par
\par > Um, that's DDK ** 3790 ** .
\par >
\par > --
\par > J.C.
\par >
\par >
\par > "JLC" wrote:
\par >
\par > > Bobby,
\par > > Many thanks for the reply:
\par > > I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
\par > > I will take a look at the server 2003 example, as you suggest.
\par > >
\par > > This problem is a little surprising, since we've got ImageProcessing() code
\par > > for 1BPP and 8BPP, that has no banding problems of this kind: this has been
\par > > released for a few years. Maybe the 4 planes / 1BPP is a special case?
\par > >
\par > > One approach that has **almost** worked:
\par > > 1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
\par > > 2. In OEMStartDoc, save the band length to OEMPDEV.
\par > > 3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
\par > > If the end of the current band will overshoot the saved page length,
\par > > change pso->sizelBitmap->cy to the size that will match the end of page.
\par > > 4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved initial
\par > >
\par > > bandsize, and reset it if necessary.
\par > >
\par > > This has eliminated the extra garbage data, but I'm now 1 pixel short /
\par > > page....
\par > > Thanks again for the suggestions--
\par > > Joe C.
\par > > --
\par > > J.C.
\par > >
\par > >
\par > > "JLC" wrote:
\par > >
\par > > >
\par > > > --
\par > > > J.C.
\par > > >
\par > > >
\par > > > "Bobby Mattappally [MS]" wrote:
\par > > >
\par > > > >
\par > > > > J.C,
\par > > > > I am not aware of any bugs in the unidrv banding code.
\par > > > > It is very unlikely (we would have heard about it long back)
\par > > > > Can you make sure you have read and followed comments section in the ddk
\par > > > > docs on "ImageProcessing
\par > > > > "?
\par > > > > Also look at the bitmap sample on server 2003 ddk to see an implementation
\par > > > > of imageprocessing.
\par > > > >
\par > > > > Hope this helps.
\par > > > >
\par > > > > Thank you,
\par > > > > Bobby Mattappally
\par > > > > Microsoft
\par > > > >
\par > > > > This posting is provided "AS IS" with no warranties, and confers no rights.
\par > > > >
\par > > > > --------------------
\par > > > > Thread-Topic: UNIDRV Banding Line Count error?
\par > > > >
\par > > > >
\par > > > > Hello,
\par > > > > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
\par > > > > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
\par > > > > 24.) The conversion itself works fine, *except*:
\par > > > > when UNIDRV is doing banding, if the last band is shorter than
\par > > > > the previous bands, the difference (in lines) is added to the print as
\par > > > > garbage raster data.
\par > > > > E.G: for a 3300 line Letter page:
\par > > > > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
\par > > > > What is printed is the 3300 lines expected, plus (664 - 644 =)20 lines
\par > > > > of garbage.
\par > > > > For a 3750 line page:
\par > > > > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
\par > > > > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
\par > > > >
\par > > > > It *looks* like when Unidrv splits the page into bands, it's not
\par > > > > tracking the actual count when passing the bands to Output.
\par > > > >
\par > > > > Comments? Suggestions??
\par > > > > I'd rather not do the compression and output
\par > > > > to spooler myself, if there's a known fix for this issue.
\par > > > > Thanks! -- Joe C.
\par > > > >
\par > > > > --
\par > > > > J.C
\par \pard
\par
\par }
------=_NextPart_0001_24F00593--

JLC
Thu Oct 20 10:39:06 CDT 2005

Bobby,
I'm not doing anything in OEMNextBand; just handing off the surface and the
pointl unmodifed. (I *did* try to solve this by adjusting the pso cy before
the call, but that left a 1 pixel whitespace at end of page.)

When I use standard halftoning, with a long enough page to force banding
(DevBPP 1, DevNumOfPlanes 4, DrvBPP 4), the output is correct.
In OEMNextBand, I can see that the last band pso..cy would overshoot, but
the output, as you've described, is just to end of page.


So, without ImageProcessing(), all is OK.

Could it be the format change in my custom halftoning?
Here's some of the GPD (omitting the ordinary stuff):
=========================
...
*MasterUnits: PAIR(300, 300)

...

*Feature: ColorMode
{
*Name: "Color Interpretation"
*DefaultOption: My4bppHT

*Option: My4bppHT
{
*Name: "CMYK - My Halftone"
*DevNumOfPlanes: 4
*DevBPP: 1
*DrvBPP: 24
*Color?: TRUE
*RasterMode: DIRECT
EXTERN_GLOBAL: *RasterSendAllData?: TRUE
*ColorPlaneOrder: LIST (CYAN, MAGENTA, YELLOW, BLACK)
*IPCallbackID: 107
*Constraints: Halftone.HT_PATSIZE_AUTO
*Constraints: Halftone.HT_PATSIZE_SUPERCELL_M
*Constraints: Halftone.HT_PATSIZE_8x8_M
*Constraints: Halftone.HT_PATSIZE_6x6_M
*Constraints: Halftone.HT_PATSIZE_4x4_M
*Constraints: Halftone.HT_PATSIZE_2x2_M
}

*Option: 4bppPlane
{
*Name: "CMYK - Std Halftone"
*ColorPlaneOrder: LIST (CYAN, MAGENTA, YELLOW, BLACK)
*DevNumOfPlanes: 4
*DevBPP: 1
*DrvBPP: 4
*RasterMode: DIRECT
EXTERN_GLOBAL: *RasterSendAllData?: TRUE
*Constraints: Halftone.MyHT
}

}

*%---------------------------------------------------------------

*Feature: Halftone
{
*Name: "Halftone Pattern"
*DefaultOption: MyHT
*Option: HT_PATSIZE_AUTO
{
*rcNameID: =HT_AUTO_SELECT_DISPLAY
}
*Option: HT_PATSIZE_SUPERCELL_M
{
*rcNameID: =HT_SUPERCELL_DISPLAY
}
*Option: HT_PATSIZE_8x8_M
{
*rcNameID: =HT_DITHER8X8_DISPLAY
}
*Option: HT_PATSIZE_6x6_M
{
*rcNameID: =HT_DITHER6X6_DISPLAY
}
*Option: HT_PATSIZE_4x4_M
{
*Name: "Dither 4x4"
}
*Option: HT_PATSIZE_2x2_M
{
*Name: "Dither 2x2"
}
*Option: MyHT
{
*Name: "My Halftoning"
}

}

..........

*EnableGDIColorMapping?: TRUE
*Command: CmdEnableTIFF4 { *Cmd : "" }
*Command: CmdCR { *Cmd : "<00>" }
*Command: CmdLF { *Cmd : "<00>" }
*YMoveThreshold: *
*YMoveUnit: 300
*Command: CmdYMoveRelDown{ *Cmd : "<1B>_J" %m[0,65535]{max_repeat(DestYRel )
}}
*RotateCoordinate?: FALSE
*RotateRaster?: FALSE
*RotateFont?: FALSE
*CursorXAfterCR: AT_CURSOR_X_ORIGIN
*OutputDataFormat: H_BYTE
*OptimizeLeftBound?: FALSE
*CursorXAfterSendBlockData: AT_GRXDATA_ORIGIN
*CursorYAfterSendBlockData: AUTO_INCREMENT
*DefaultCTT: -1
*CharPosition: UPPERLEFT
-----------------------------------------------------

Then, in ImageProcessing():

HRESULT __stdcall IOemUni::ImageProcessing( ...)
{
....
// check the IPPARAMS, for null bmp; return now if so:
if(pIPParams->bBlankBand){
VERBOSE(DLLTEXT(" blank band. returning S_OK.\r\n"));
// from MSDN newsgroup.... 8/3/05
// ONLY if we send to spooler...*ppbResult= (PBYTE) IntToPtr(TRUE);
*ppbResult = pSrcBitmap;

return S_OK;
}

.....
pIn = pSrcBitmap;
pOut = pSrcBitmap;
iInHeight = pBitmapInfoHeader->biHeight;
iInWidth = pBitmapInfoHeader->biWidth;

iSrcLineBytes = pBitmapInfoHeader->biSizeImage/ iInHeight;


[halftone 24bpp input band to 4bpp output format]

// set presult = pinput....
*ppbResult = pSrcBitmap;

return S_OK;
}

... Anything suspicious? Would a cursor move help?

Thanks again,
Joe C.

--
J.C.


"Bobby Mattappally [MS]" wrote:

> Hi JlC,
>
> Unidrv is doing something similar to what you mentioned in the previous
> message.
> It checks (in the DrvNextBand) to make sure the band doesn't shoot over the
> printable area and then adjusts the clipping to the bottom of the image
> area in that scenario. Are you trying to implement NextBand on your own and
> not calling back into unidrv's NextBand function?
> Then you would have to do something similar.
>
>
>
> Hope this helps.
>
> Thank you,
> Bobby Mattappally
> Microsoft
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>
> --------------------
> Thread-Topic: UNIDRV Banding Line Count error?
> thread-index: AcXU0uJsRaNqauvWR5iB5DCky2ogsQ==
> X-WBNR-Posting-Host: 208.37.22.158
>
>
> Sorry for the endless follow-ons:
> We *did* have this issue before, on an experimental 8BPP-> 1BPP
> ImageProcessing callback, and I had to compress/spool the data myself.
> Less than 18 months ago, no less, and I'd posted to this group.
> Time for a new pot of coffee....
> ------------------------------------------
> The question at hand then, is:
>
> If the bands are being set up as small working surfaces,
> *how* is the mismatch of the sum-of-band size to page size handled in
> UNIDRV?
> In ImageProcessing, the bitmap for each band *is* accurately sized, to end
> at the
> end of the page.
> The *surface*, however, in NextBand, is always the *same* size,
> and that size is what is passed on to compression / spooling. This results
> in garbage data in the output on the last band, since the bitmap area is
> shorter.
>
> Is it the *bitmap* height, or the *surface* height that is being passed
> downstream for output by UNIDRV?
>
> I'm not sure *what* I can do to control this behavior in a documented way--
> any suggestions would be greatly appreciated.
>
> Thanks again!
>
>
> --
> J.C.
>
>
> "JLC" wrote:
>
> > Um, that's DDK ** 3790 ** .
> >
> > --
> > J.C.
> >
> >
> > "JLC" wrote:
> >
> > > Bobby,
> > > Many thanks for the reply:
> > > I'm using DDK3700, xp env. We need to support Win2K SP3 and beyond.
> > > I will take a look at the server 2003 example, as you suggest.
> > >
> > > This problem is a little surprising, since we've got ImageProcessing()
> code
> > > for 1BPP and 8BPP, that has no banding problems of this kind: this has
> been
> > > released for a few years. Maybe the 4 planes / 1BPP is a special case?
> > >
> > > One approach that has **almost** worked:
> > > 1. In OEMEnablePDEV, save the page length in pixels to OEMPDEV.
> > > 2. In OEMStartDoc, save the band length to OEMPDEV.
> > > 3. In OEMNextBand, save the accumulated band lengths to OEMPDEV.
> > > If the end of the current band will overshoot the saved page length,
> > > change pso->sizelBitmap->cy to the size that will match the end of
> page.
> > > 4. In OEMStartPage, check the pso->sizelBitmap->cy against the saved
> initial
> > >
> > > bandsize, and reset it if necessary.
> > >
> > > This has eliminated the extra garbage data, but I'm now 1 pixel short /
> > > page....
> > > Thanks again for the suggestions--
> > > Joe C.
> > > --
> > > J.C.
> > >
> > >
> > > "JLC" wrote:
> > >
> > > >
> > > > --
> > > > J.C.
> > > >
> > > >
> > > > "Bobby Mattappally [MS]" wrote:
> > > >
> > > > >
> > > > > J.C,
> > > > > I am not aware of any bugs in the unidrv banding code.
> > > > > It is very unlikely (we would have heard about it long back)
> > > > > Can you make sure you have read and followed comments section in
> the ddk
> > > > > docs on "ImageProcessing
> > > > > "?
> > > > > Also look at the bitmap sample on server 2003 ddk to see an
> implementation
> > > > > of imageprocessing.
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > Thank you,
> > > > > Bobby Mattappally
> > > > > Microsoft
> > > > >
> > > > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > > > >
> > > > > --------------------
> > > > > Thread-Topic: UNIDRV Banding Line Count error?
> > > > >
> > > > >
> > > > > Hello,
> > > > > I've got a rendering plugin with ImageProcessing doing RGB24 to CMYK
> > > > > custom halftoning. (That is, DevNumPlanes = 4, DevBPP = 1, DrvBPP=
> > > > > 24.) The conversion itself works fine, *except*:
> > > > > when UNIDRV is doing banding, if the last band is shorter than
> > > > > the previous bands, the difference (in lines) is added to the print
> as
> > > > > garbage raster data.
> > > > > E.G: for a 3300 line Letter page:
> > > > > ImageProcessing reports 4 x bands of 664 lines, then one of 644.
> > > > > What is printed is the 3300 lines expected, plus (664 - 644 =)20
> lines
> > > > > of garbage.
> > > > > For a 3750 line page:
> > > > > ImageProcessing reports 4 x bands of 752 lines, then one of 742.
> > > > > The expected 3750 lines print, plus 10 lines (752 - 742) of garbage.
> > > > >
> > > > > It *looks* like when Unidrv splits the page into bands, it's not
> > > > > tracking the actual count when passing the bands to Output.
> > > > >
> > > > > Comments? Suggestions??
> > > > > I'd rather not do the compression and output
> > > > > to spooler myself, if there's a known fix for this issue.
> > > > > Thanks! -- Joe C.
> > > > >
> > > > > --
> > > > > J

JLC
Fri Oct 21 11:58:05 CDT 2005

Bobby,
The one-pixel gap I ended up with is a red herring:
I was using a test page that was a *custom* form, 4.25" long.
At 300 DPI, (MU are 300 x 300), that *seems* like it would be 1275 pixels
high.
The value I pick up for page length, in OEMEnablePDEV, is from
gdiInfo->ulVertRes, and that reports *1274* high.
Further, in OEMStartDoc, I've found that UNIDRV standard variable
PhysPageLength = 1274 too.

However, *even when I use Standard halftoning, with NO banding*,
there is an extra vertical move at the start of each page.
That is, *1275* lines are printed.

When I use a Letter size page (3300 high), I get the correct output,
both with my halftoning (with band size correction hack) and standard
halftoning. This is also true for our 12.5" long page (3750), which also
prints correctly.

The Fix:
Disabling CUSTOMSIZE forms, and adding a 4.25" printer form
to the GPD (1275 long), all is _OK_.

So then:
1. The banding page-position accounting problem (output overshooting
end-of-page position when banding) is fixed, by changing
pso->sizelBitmap->cy on the last band of page before calling
UNIDRV's DrvNextBand, then restoring it on the following OEMStartPage.
This will work for me, I think. However, if there is a more rational
solution,
correcting my own design error, I would prefer that.


2. There appears to be a calculation mismatch, that is, *different* rounding
used when deriving lines per page, in different parts of UNIDRV (or
GDI) when
using CUSTOMFORM sizes.
CUSTOMFORMs are not a requirement for us; away they go.

Thanks for listening!
-- Joe C.



--
J.C.

bobbym
Wed Oct 26 18:25:52 CDT 2005

------=_NextPart_0001_48CE5499
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


JC,
I am not exactly sure I understood what is going on here.
If you want to send me a private mail (remove "online." from the address)
with driver and the repro steps, I can look into this.

Thank you,
Bobby Mattappally
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
Thread-Topic: UNIDRV Banding Line Count error?
Subject: RE: UNIDRV Banding Line Count error?
Date: Fri, 21 Oct 2005 09:58:05 -0700
Lines: 49
Bobby,
The one-pixel gap I ended up with is a red herring:
I was using a test page that was a *custom* form, 4.25" long.
At 300 DPI, (MU are 300 x 300), that *seems* like it would be 1275 pixels
high.
The value I pick up for page length, in OEMEnablePDEV, is from
gdiInfo->ulVertRes, and that reports *1274* high.
Further, in OEMStartDoc, I've found that UNIDRV standard variable
PhysPageLength = 1274 too.

However, *even when I use Standard halftoning, with NO banding*,
there is an extra vertical move at the start of each page.
That is, *1275* lines are printed.

When I use a Letter size page (3300 high), I get the correct output,
both with my halftoning (with band size correction hack) and standard
halftoning. This is also true for our 12.5" long page (3750), which also
prints correctly.

The Fix:
Disabling CUSTOMSIZE forms, and adding a 4.25" printer form
to the GPD (1275 long), all is _OK_.

So then:
1. The banding page-position accounting problem (output overshooting
end-of-page position when banding) is fixed, by changing
pso->sizelBitmap->cy on the last band of page before calling
UNIDRV's DrvNextBand, then restoring it on the following OEMStartPage.
This will work for me, I think. However, if there is a more rational
solution,
correcting my own design error, I would prefer that.


2. There appears to be a calculation mismatch, that is, *different*
rounding
used when deriving lines per page, in different parts of UNIDRV (or
GDI) when
using CUSTOMFORM sizes.
CUSTOMFORMs are not a requirement for us; away they go.

Thanks for listening!
-- Joe C.



--
J.C.




------=_NextPart_0001_48CE5499
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par \pard\li720 JC,
\par I am not exactly sure I understood what is going on here.
\par If you want to send me a private mail (remove "online." from the address) with driver and the repro steps, I can look into this.
\par
\par Thank you,
\par Bobby Mattappally
\par Microsoft
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par --------------------
\par Thread-Topic: UNIDRV Banding Line Count error?
\par Subject: RE: UNIDRV Banding Line Count error?
\par Date: Fri, 21 Oct 2005 09:58:05 -0700
\par Lines: 49
\par Bobby,
\par The one-pixel gap I ended up with is a red herring:
\par I was using a test page that was a *custom* form, 4.25" long.
\par At 300 DPI, (MU are 300 x 300), that *seems* like it would be 1275 pixels
\par high.
\par The value I pick up for page length, in OEMEnablePDEV, is from
\par gdiInfo->ulVertRes, and that reports *1274* high.
\par Further, in OEMStartDoc, I've found that UNIDRV standard variable
\par PhysPageLength = 1274 too.
\par
\par However, *even when I use Standard halftoning, with NO banding*,
\par there is an extra vertical move at the start of each page.
\par That is, *1275* lines are printed.
\par
\par When I use a Letter size page (3300 high), I get the correct output,
\par both with my halftoning (with band size correction hack) and standard
\par halftoning. This is also true for our 12.5" long page (3750), which also
\par prints correctly.
\par
\par The Fix:
\par Disabling CUSTOMSIZE forms, and adding a 4.25" printer form
\par to the GPD (1275 long), all is _OK_.
\par
\par So then:
\par 1. The banding page-position accounting problem (output overshooting
\par end-of-page position when banding) is fixed, by changing
\par pso->sizelBitmap->cy on the last band of page before calling
\par UNIDRV's DrvNextBand, then restoring it on the following OEMStartPage.
\par This will work for me, I think. However, if there is a more rational
\par solution,
\par correcting my own design error, I would prefer that.
\par
\par
\par 2. There appears to be a calculation mismatch, that is, *different* rounding
\par used when deriving lines per page, in different parts of UNIDRV (or
\par GDI) when
\par using CUSTOMFORM sizes.
\par CUSTOMFORMs are not a requirement for us; away they go.
\par
\par Thanks for listening!
\par -- Joe C.
\par
\par
\par
\par --
\par J.C.
\par
\par
\par
\par \pard
\par
\par }
------=_NextPart_0001_48CE5499--