bitmap printer driver

Hi everyone,

since MS does not seem to release the long awaited bitmap printer driver
sample
for Longhorn (with backwards-compatiblity to W2K), I am finally starting to
develop my own, based on the rendering-plugin-sample as a replacement
of the existing NT 4.0 kernel-mode driver.

I already discovered quite a bit about what I need when browsing through the
msdn/ddk-online-help and some of the newsgroup-posts.

Still some questions remain:

How can I find out in my rendering-plugin, at what point there is a
page-break?
As far as I understand the IPrintOemUni::FilterGraphics could be called
multiple
times per page - right?

I use filtergraphics to convert the rendered data into my format and write
it down
into a file, but I need to provide
a.) a document header
b.) a page header
c.) an end-of-file header
So I need to get the information about those states / state-changes. I have
only
found an interface for this information in the ui-plugin - but this really
does not
help me during the rendering/conversion process :-(

At the end of the printing process I want to start up an executable with a
graphical-frontend for further processing of the generated file. This exe
must be run in the context of the user that has invoked the print-task.
How can this be done?

Thanks a lot in advance for any pointers in the right direction :-)

Tobias

Vipin
Wed Sep 22 22:28:07 CDT 2004

Shouldn't it be dumpiong at EndPage for more than 1 page documents instead
of EndDoc???

"Ashwin [MS]" <ashwinn@online.microsoft.com> wrote in message
news:231C48F1-B607-4E51-9655-33F3CF3F9471@microsoft.com...
> I would suggest that you use IPrintOemUni::ImageProcessing instead of the
> FilterGraphics callback. This is the approach I have used in the Longhorn
> bitmap driver sample. The bitmap driver implements the ImageProcessing
> callback in order to get access to bitmap data one band at a time. The
> driver's implementation of ImageProcessing buffers the band data every
time
> it is called. The function is also responsible for filling in the
> BITMAPINFOHEADER and COLORTABLE structures that are necessary for dumping
the
> data out to a bitmap file. The bitmap driver also implements the OEMEndDoc
> DDI hook in order to dump the buffered bitmap data out to the spooler at
the
> end of the print job. The driver's implementation of OEMEndDoc dumps the
> headers first and then the buffered data.
>
> Hope this helps.
>
> - Ashwin
>
>
> "Tobias Erichsen" wrote:
>
> > Hi everyone,
> >
> > since MS does not seem to release the long awaited bitmap printer driver
> > sample
> > for Longhorn (with backwards-compatiblity to W2K), I am finally starting
to
> > develop my own, based on the rendering-plugin-sample as a replacement
> > of the existing NT 4.0 kernel-mode driver.
> >
> > I already discovered quite a bit about what I need when browsing through
the
> > msdn/ddk-online-help and some of the newsgroup-posts.
> >
> > Still some questions remain:
> >
> > How can I find out in my rendering-plugin, at what point there is a
> > page-break?
> > As far as I understand the IPrintOemUni::FilterGraphics could be called
> > multiple
> > times per page - right?
> >
> > I use filtergraphics to convert the rendered data into my format and
write
> > it down
> > into a file, but I need to provide
> > a.) a document header
> > b.) a page header
> > c.) an end-of-file header
> > So I need to get the information about those states / state-changes. I
have
> > only
> > found an interface for this information in the ui-plugin - but this
really
> > does not
> > help me during the rendering/conversion process :-(
> >
> > At the end of the printing process I want to start up an executable with
a
> > graphical-frontend for further processing of the generated file. This
exe
> > must be run in the context of the user that has invoked the print-task.
> > How can this be done?
> >
> > Thanks a lot in advance for any pointers in the right direction :-)
> >
> > Tobias
> >
> >
> >

Tobias
Thu Sep 23 01:00:17 CDT 2004


"Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
news:231C48F1-B607-4E51-9655-33F3CF3F9471@microsoft.com...
> I would suggest that you use IPrintOemUni::ImageProcessing instead of the
> FilterGraphics callback. This is the approach I have used in the Longhorn
> bitmap driver sample. The bitmap driver implements the ImageProcessing
> callback in order to get access to bitmap data one band at a time. The
> driver's implementation of ImageProcessing buffers the band data every
time
> it is called. The function is also responsible for filling in the
> BITMAPINFOHEADER and COLORTABLE structures that are necessary for dumping
the
> data out to a bitmap file. The bitmap driver also implements the OEMEndDoc
> DDI hook in order to dump the buffered bitmap data out to the spooler at
the
> end of the print job. The driver's implementation of OEMEndDoc dumps the
> headers first and then the buffered data.

Thanks a lot for this fast reply. I think that will help a lot. I didn't
know that
you wrote the bitmap driver sample. It's a shame that MS has not released
it yet for the MSDN folks...

Tobias

Tobias
Thu Sep 23 01:18:10 CDT 2004


"Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
news:231C48F1-B607-4E51-9655-33F3CF3F9471@microsoft.com...
> I would suggest that you use IPrintOemUni::ImageProcessing instead of the

One little further question: the method above does not seem part of the
W2K or XP ddk. I only found it in the W2K3 ddk - has this function
been backported to W2K and XP?

Tobias

ashwinn
Wed Sep 22 13:11:06 CDT 2004

I would suggest that you use IPrintOemUni::ImageProcessing instead of the
FilterGraphics callback. This is the approach I have used in the Longhorn
bitmap driver sample. The bitmap driver implements the ImageProcessing
callback in order to get access to bitmap data one band at a time. The
driverâ??s implementation of ImageProcessing buffers the band data every time
it is called. The function is also responsible for filling in the
BITMAPINFOHEADER and COLORTABLE structures that are necessary for dumping the
data out to a bitmap file. The bitmap driver also implements the OEMEndDoc
DDI hook in order to dump the buffered bitmap data out to the spooler at the
end of the print job. The driverâ??s implementation of OEMEndDoc dumps the
headers first and then the buffered data.

Hope this helps.

- Ashwin


"Tobias Erichsen" wrote:

> Hi everyone,
>
> since MS does not seem to release the long awaited bitmap printer driver
> sample
> for Longhorn (with backwards-compatiblity to W2K), I am finally starting to
> develop my own, based on the rendering-plugin-sample as a replacement
> of the existing NT 4.0 kernel-mode driver.
>
> I already discovered quite a bit about what I need when browsing through the
> msdn/ddk-online-help and some of the newsgroup-posts.
>
> Still some questions remain:
>
> How can I find out in my rendering-plugin, at what point there is a
> page-break?
> As far as I understand the IPrintOemUni::FilterGraphics could be called
> multiple
> times per page - right?
>
> I use filtergraphics to convert the rendered data into my format and write
> it down
> into a file, but I need to provide
> a.) a document header
> b.) a page header
> c.) an end-of-file header
> So I need to get the information about those states / state-changes. I have
> only
> found an interface for this information in the ui-plugin - but this really
> does not
> help me during the rendering/conversion process :-(
>
> At the end of the printing process I want to start up an executable with a
> graphical-frontend for further processing of the generated file. This exe
> must be run in the context of the user that has invoked the print-task.
> How can this be done?
>
> Thanks a lot in advance for any pointers in the right direction :-)
>
> Tobias
>
>
>

ashwinn
Thu Sep 23 13:23:01 CDT 2004

The function is available on W2K and XP as well. All methods from the
IPrintOemUni interface are available on W2K, XP as well as Server 2003.

In response to your other question about the sample being made available to
MSDN folks, it was part of the WinHEC release of the Longhorn Driver Kit
(LDK). But my understanding is that if you didn't attend WinHEC, there is no
easy way to get a hold of that copy. In any case, we are investigating
alternate release options for this sample given the number of requests I have
seen for it. I am not sure at this point if or how it will be released...but
we are working on it.

In response to Vipin's post, OEMEndDoc is only one possible implementation.
It really depends on what your particular driver needs to do. If you want
each page as an individual bitmap file, then OEMEndPage is the correct place.

- Ashwin


"Tobias Erichsen" wrote:

>
> "Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
> news:231C48F1-B607-4E51-9655-33F3CF3F9471@microsoft.com...
> > I would suggest that you use IPrintOemUni::ImageProcessing instead of the
>
> One little further question: the method above does not seem part of the
> W2K or XP ddk. I only found it in the W2K3 ddk - has this function
> been backported to W2K and XP?
>
> Tobias
>
>
>

Tobias
Thu Sep 23 15:35:35 CDT 2004


"Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
news:36FD05F3-4DB3-4C7F-9C21-CEE351BCAFD6@microsoft.com...
> The function is available on W2K and XP as well. All methods from the
> IPrintOemUni interface are available on W2K, XP as well as Server 2003.
>
> In response to your other question about the sample being made available
to
> MSDN folks, it was part of the WinHEC release of the Longhorn Driver Kit
> (LDK). But my understanding is that if you didn't attend WinHEC, there is
no
> easy way to get a hold of that copy. In any case, we are investigating
> alternate release options for this sample given the number of requests I
have
> seen for it. I am not sure at this point if or how it will be
released...but
> we are working on it.

Actually I'm making good progress, so I think I won't be needing the
sample any more. I guess I will have my basic rendering to a file up
and running tomorrow. I could even copy and paste some stuff from
the user-mode-part of my old kernel-mode printer-driver.

The missing "link" for me still is the need to start up an external
application
which I hand over the filename of the rendered file as a parameter. This
program should be run with the users credentials who had started the print-
job.

Can I do this from within the rendering-plugin, or do I need to do this
from a ui-plugin? If the latter, how can I get the information about
the filename that the rendering-pluging generated to the ui-plugin?

Tobias

ashwinn
Thu Sep 23 17:45:02 CDT 2004

If you really need to do it, you would have to do it within a UI plugin since
the rendering plugin often runs in the context of the spooler process which
runs under the SYSTEM account. But that whole approach can be quite tricky
and may not work. So I would suggest that you install your "printer" on the
FILE: port instead and have the user provide the filename when he/she prints
as opposed to the rendering plug-in providing the filename back to the user.
The way you would do this is to dump the data from OEMEndDoc to
DrvWriteSpoolBuf instead of directly writing to a file yourself.
DrvWriteSpoolBuf eventually calls the spooler's WritePrinter function which
writes the data out to whichever port the printer is installed on...in this
case the FILE: port. This is what the bitmap sample driver does as well.

- Ashwin


"Tobias Erichsen" wrote:

>
> "Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
> news:36FD05F3-4DB3-4C7F-9C21-CEE351BCAFD6@microsoft.com...
> > The function is available on W2K and XP as well. All methods from the
> > IPrintOemUni interface are available on W2K, XP as well as Server 2003.
> >
> > In response to your other question about the sample being made available
> to
> > MSDN folks, it was part of the WinHEC release of the Longhorn Driver Kit
> > (LDK). But my understanding is that if you didn't attend WinHEC, there is
> no
> > easy way to get a hold of that copy. In any case, we are investigating
> > alternate release options for this sample given the number of requests I
> have
> > seen for it. I am not sure at this point if or how it will be
> released...but
> > we are working on it.
>
> Actually I'm making good progress, so I think I won't be needing the
> sample any more. I guess I will have my basic rendering to a file up
> and running tomorrow. I could even copy and paste some stuff from
> the user-mode-part of my old kernel-mode printer-driver.
>
> The missing "link" for me still is the need to start up an external
> application
> which I hand over the filename of the rendered file as a parameter. This
> program should be run with the users credentials who had started the print-
> job.
>
> Can I do this from within the rendering-plugin, or do I need to do this
> from a ui-plugin? If the latter, how can I get the information about
> the filename that the rendering-pluging generated to the ui-plugin?
>
> Tobias
>
>
>

Tobias
Fri Sep 24 00:49:06 CDT 2004


"Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
news:B64A075C-5F39-46D4-96C5-5A4ECF1EDF37@microsoft.com...
> If you really need to do it, you would have to do it within a UI plugin
since
> the rendering plugin often runs in the context of the spooler process
which
> runs under the SYSTEM account. But that whole approach can be quite tricky
> and may not work. So I would suggest that you install your "printer" on
the
> FILE: port instead and have the user provide the filename when he/she
prints
> as opposed to the rendering plug-in providing the filename back to the
user.
> The way you would do this is to dump the data from OEMEndDoc to
> DrvWriteSpoolBuf instead of directly writing to a file yourself.
> DrvWriteSpoolBuf eventually calls the spooler's WritePrinter function
which
> writes the data out to whichever port the printer is installed on...in
this
> case the FILE: port. This is what the bitmap sample driver does as well.

As this is a fax-printer-driver, this would not suffice. What I need is to
start
an executable, that will then send the fax-document out (by ISDN). This
program accesses the outlook-address-database and therefore must be
running in the context of the user. So the rendering-plugin generates the
target-file, which needs to be accessed by the ui-plugin - but how do
I communicate this filename between those two plugins?

Tobias

Vipin
Fri Sep 24 02:45:03 CDT 2004

It would run in the app context in the dont_journal mode.

"Ashwin [MS]" <ashwinn@online.microsoft.com> wrote in message
news:B64A075C-5F39-46D4-96C5-5A4ECF1EDF37@microsoft.com...
> If you really need to do it, you would have to do it within a UI plugin
since
> the rendering plugin often runs in the context of the spooler process
which
> runs under the SYSTEM account. But that whole approach can be quite tricky
> and may not work. So I would suggest that you install your "printer" on
the
> FILE: port instead and have the user provide the filename when he/she
prints
> as opposed to the rendering plug-in providing the filename back to the
user.
> The way you would do this is to dump the data from OEMEndDoc to
> DrvWriteSpoolBuf instead of directly writing to a file yourself.
> DrvWriteSpoolBuf eventually calls the spooler's WritePrinter function
which
> writes the data out to whichever port the printer is installed on...in
this
> case the FILE: port. This is what the bitmap sample driver does as well.
>
> - Ashwin
>
>
> "Tobias Erichsen" wrote:
>
> >
> > "Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
> > news:36FD05F3-4DB3-4C7F-9C21-CEE351BCAFD6@microsoft.com...
> > > The function is available on W2K and XP as well. All methods from the
> > > IPrintOemUni interface are available on W2K, XP as well as Server
2003.
> > >
> > > In response to your other question about the sample being made
available
> > to
> > > MSDN folks, it was part of the WinHEC release of the Longhorn Driver
Kit
> > > (LDK). But my understanding is that if you didn't attend WinHEC, there
is
> > no
> > > easy way to get a hold of that copy. In any case, we are investigating
> > > alternate release options for this sample given the number of requests
I
> > have
> > > seen for it. I am not sure at this point if or how it will be
> > released...but
> > > we are working on it.
> >
> > Actually I'm making good progress, so I think I won't be needing the
> > sample any more. I guess I will have my basic rendering to a file up
> > and running tomorrow. I could even copy and paste some stuff from
> > the user-mode-part of my old kernel-mode printer-driver.
> >
> > The missing "link" for me still is the need to start up an external
> > application
> > which I hand over the filename of the rendered file as a parameter.
This
> > program should be run with the users credentials who had started the
print-
> > job.
> >
> > Can I do this from within the rendering-plugin, or do I need to do this
> > from a ui-plugin? If the latter, how can I get the information about
> > the filename that the rendering-pluging generated to the ui-plugin?
> >
> > Tobias
> >
> >
> >

Tobias
Fri Sep 24 07:31:52 CDT 2004


"Vipin" <vipin@nospam.com> schrieb im Newsbeitrag
news:ukY7AjgoEHA.800@TK2MSFTNGP14.phx.gbl...
> It would run in the app context in the dont_journal mode.

Can I force this mode either from the gpd file or my plugin-dll?

Tobias

ashwinn
Fri Sep 24 21:39:04 CDT 2004

You should use the IPrintOemUI2::DocumentEvent callback to communicated
between the two plug-ins. In fact, that is what the Microsoft fax driver does
as well. For example, if you want your UI plugin to popup a box after EndDoc,
you should use DOCUMENTEVENT_ENDDOC to display this.

- Ashwin


"Tobias Erichsen" wrote:

>
> "Ashwin [MS]" <ashwinn@online.microsoft.com> schrieb im Newsbeitrag
> news:B64A075C-5F39-46D4-96C5-5A4ECF1EDF37@microsoft.com...
> > If you really need to do it, you would have to do it within a UI plugin
> since
> > the rendering plugin often runs in the context of the spooler process
> which
> > runs under the SYSTEM account. But that whole approach can be quite tricky
> > and may not work. So I would suggest that you install your "printer" on
> the
> > FILE: port instead and have the user provide the filename when he/she
> prints
> > as opposed to the rendering plug-in providing the filename back to the
> user.
> > The way you would do this is to dump the data from OEMEndDoc to
> > DrvWriteSpoolBuf instead of directly writing to a file yourself.
> > DrvWriteSpoolBuf eventually calls the spooler's WritePrinter function
> which
> > writes the data out to whichever port the printer is installed on...in
> this
> > case the FILE: port. This is what the bitmap sample driver does as well.
>
> As this is a fax-printer-driver, this would not suffice. What I need is to
> start
> an executable, that will then send the fax-document out (by ISDN). This
> program accesses the outlook-address-database and therefore must be
> running in the context of the user. So the rendering-plugin generates the
> target-file, which needs to be accessed by the ui-plugin - but how do
> I communicate this filename between those two plugins?
>
> Tobias
>
>
>

Vipin
Mon Sep 27 01:29:41 CDT 2004

STDMETHOD
(EnablePDEV) (
THIS_
PDEVOBJ pdevobj,
PWSTR pPrinterName,
ULONG cPatterns,
HSURF *phsurfPatterns,
ULONG cjGdiInfo,
GDIINFO *pGdiInfo,
ULONG cjDevInfo,
DEVINFO *pDevInfo,
DRVENABLEDATA *pded,
OUT PDEVOEM *pDevOem
) PURE;

in a plugin dll and then modify the DEVINFO's flGraphicsCaps can do it for
you.
Also you can change the PrintProcessor setting to "raw" from default mode of
EMF and you should
have the processing in the application context.

Thanks
Vipin

"Tobias Erichsen" <t.erichsen@gmx.de> wrote in message
news:2riidoF1acof6U1@uni-berlin.de...
>
> "Vipin" <vipin@nospam.com> schrieb im Newsbeitrag
> news:ukY7AjgoEHA.800@TK2MSFTNGP14.phx.gbl...
> > It would run in the app context in the dont_journal mode.
>
> Can I force this mode either from the gpd file or my plugin-dll?
>
> Tobias
>
>

Steve
Tue Jul 18 14:20:00 CDT 2006

"Tobias Erichsen" <t.erichsen@gmx.de> wrote in message
news:2rdpabF17tme4U1@uni-berlin.de...
> How can I find out in my rendering-plugin, at what point there is a
> page-break?
> As far as I understand the IPrintOemUni::FilterGraphics could be called
> multiple times per page - right?
>
> I use filtergraphics to convert the rendered data into my format and write
> it down into a file, but I need to provide
> a.) a document header
> b.) a page header
> c.) an end-of-file header
> So I need to get the information about those states / state-changes. I
> have
> only found an interface for this information in the ui-plugin - but this
> really
> does not help me during the rendering/conversion process :-(
>
> At the end of the printing process I want to start up an executable with a
> graphical-frontend for further processing of the generated file. This exe
> must be run in the context of the user that has invoked the print-task.
> How can this be done?
>
> Thanks a lot in advance for any pointers in the right direction :-)

Hi Tobias,

I've not used the Unidriver, but know a fair amount about the PostScript OEM
driver, and this smells to me a bit like you're going down the wrong road
with this. Take all this with a grain of salt - I'm winging it on Unidriver
issues.

FilterGraphics is called on a scanline basis, not text, and I don't think
that's really the avenue to solve this problem.

If you're trying to add a header and footer to each page, looking at the
Watermark sample in the DDK is probably your best bet. Look in
src\print\oemdll\watermarkuni\ for this sample code. There seem to be some
helper routines in IPrintOemDriverUni which will allow you to move around
(DrvXMoveTo, DrvYMoveTo, DrvUniTextOut) on the output bitmap.

Unfortunately, the only way I know of to get access to the start/end page
code in the rendering DLL is to implement IPrintOemUni::EnableDriver and
hook DrvStartPage / DrvEndPage. The bummer is that the low-level code has no
meaningful access to the DEVMODE: though it can reach the public and private
parts, the private part is the *Unidriver* private part.

There is no portable method for finding your part of the private DEVMODE,
though Microsoft told me they were "thinking about it" for Vista. The only
way I've been able to get around this is to hook
IPrintOemUI2::DocumentEvent's DOCUMENTEVENT_STARTDOCPOST to grab the job ID,
and stuff the parameters as a string into JOB_INFO_1.pParameters with
SetJob().

Then, in the rendernig DLL, you'd have to hook DrvStartDoc (likewise, from
EnableDriver), take the job ID provided to you there, and stuff it and the
parameters into your OEMPDEV. It's really cumbersome, but it works.

Hooking the output data is going to be even more tricky, because the UI part
doesn't ever get a hook to the actual output data stream. I guess one way to
handle this would be for the UI part to actually create a temp file, and
pass the name to the rendering DLL: "Please send your output here". You
might have to use the SetJob() thing.

If you want a *Document* header, that's really starting to smell like the
kind of thing that belongs in a print processor.

Good luck,
Steve

--
Steve Friedl / UNIX Wizard / Microsoft Security MVP / www.unixwiz.net