Dear All,
I want to generate a pictorial snapshot of all documents
going into a printer (both network and local).
I have gone through the DDK sample for the same (bitmap), and have the
following
queries:
- Would the sample work for both local and network printers (all kinds
of them).
- Is it possible to have a stack of rendering plugins? Normally the
printer driver installer installs one for us, can I add one of my own
into this stack, or do I need to hook into the existing COM interfaces.
Please help.
Regards
-
It could work in both local and network scenarios but might need some
modification. It is currently set to be installed on the FILE: port
which thereby prompts the user for the filename at the time of
rendering. If you are fine with the user inputting the filename, you
shouldn’t have to change anything. But if you want the file to be saved
on the server, that’s a whole different story.
-
Yes…you can have a chain of rendering plugins. You would just list
them as OEMDriverFile1, OEMDriverFile2, OEMDriverFilen in the ini file.
Hope this helps.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Tuesday, August 29, 2006 11:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] rendering plugins
Dear All,
I want to generate a pictorial snapshot of all documents
going into a printer (both network and local).
I have gone through the DDK sample for the same (bitmap), and have the
following
queries:
- Would the sample work for both local and network printers (all kinds
of them).
- Is it possible to have a stack of rendering plugins? Normally the
printer driver installer installs one for us, can I add one of my own
into this stack, or do I need to hook into the existing COM interfaces.
Please help.
Regards — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ashwin,
Thanks for the reply. But I have some doubts.
here is the hpc4345b.ini file that is installed as pat of the HP laserjet
series.
OEM plugin configuration files for Unidrv
Unified UI/Render plug-ins
[OEMFiles]
OEMDriverFile1=HPZ5R043.DLL
OEMConfigFile1=HPZUI043.DLL
I tried adding the bitmap driver to this stack like this:
[OEMFiles]
OEMDriverFile1=Mybitmap.DLL
OEMDriverFile2=HPZ5R043.DLL
OEMConfigFile1=HPZUI043.DLL
What I observe is that only my DLL gets called and not the HP one.
reversing the oder ensures that only the HP DLL is called and not mine.
What changes do I have to make in bitmap sample to get it to work properly
with other rendering plugins.
On 8/30/06, Ashwin Needamangala wrote:
>
> 1. It could work in both local and network scenarios but might need some
> modification. It is currently set to be installed on the FILE: port which
> thereby prompts the user for the filename at the time of rendering. If you
> are fine with the user inputting the filename, you shouldn’t have to change
> anything. But if you want the file to be saved on the server, that’s a whole
> different story.
>
> 2. Yes…you can have a chain of rendering plugins. You would just list
> them as OEMDriverFile1, OEMDriverFile2, OEMDriverFilen in the ini file.
>
> Hope this helps.
>
> - Ashwin
>
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Bedanto
> Sent: Tuesday, August 29, 2006 11:48 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] rendering plugins
>
>
> Dear All,
>
> I want to generate a pictorial snapshot of all documents
> going into a printer (both network and local).
>
> I have gone through the DDK sample for the same (bitmap), and have the
> following
> queries:
>
> 1. Would the sample work for both local and network printers (all kinds
> of them).
> 2. Is it possible to have a stack of rendering plugins? Normally the
> printer driver installer installs one for us, can I add one of my own
> into this stack, or do I need to hook into the existing COM interfaces.
>
> Please help.
>
> Regards — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
…just wondering…
is it possible to do this:
write a rendering plugin that behaves properly in any rendering stack and
also redirects output to a file.
What i mean is, the plugin will intercept the calls to the driver (or the
next plugin) and do some processing(like dumping a bitmap…etc) and pass on
the acll to another plugin which actually writes the data to a real
printer???
On 8/30/06, Bedanto wrote:
>
> Ashwin,
>
> Thanks for the reply. But I have some doubts.
>
> here is the hpc4345b.ini file that is installed as pat of the HP laserjet
> series.
>
>
>
> #
> # OEM plugin configuration files for Unidrv
> #
> #
> # Unified UI/Render plug-ins
> #
>
> [OEMFiles]
> OEMDriverFile1=HPZ5R043.DLL
> OEMConfigFile1=HPZUI043.DLL
>
>
>
> I tried adding the bitmap driver to this stack like this:
>
> [OEMFiles]
>
> OEMDriverFile1=Mybitmap.DLL
> OEMDriverFile2=HPZ5R043.DLL
> OEMConfigFile1=HPZUI043.DLL
>
>
> What I observe is that only my DLL gets called and not the HP one.
>
> reversing the oder ensures that only the HP DLL is called and not mine.
> What changes do I have to make in bitmap sample to get it to work properly
> with other rendering plugins.
>
>
>
>
> On 8/30/06, Ashwin Needamangala wrote:
> >
> > 1. It could work in both local and network scenarios but might need
> > some modification. It is currently set to be installed on the FILE: port
> > which thereby prompts the user for the filename at the time of rendering. If
> > you are fine with the user inputting the filename, you shouldn’t have to
> > change anything. But if you want the file to be saved on the server, that’s
> > a whole different story.
> >
> > 2. Yes…you can have a chain of rendering plugins. You would just list
> > them as OEMDriverFile1, OEMDriverFile2, OEMDriverFilen in the ini file.
> >
> > Hope this helps.
> >
> > - Ashwin
> >
> >
> > ------------------------------
> > From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
> > *On Behalf Of *Bedanto
> > Sent: Tuesday, August 29, 2006 11:48 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] rendering plugins
> >
> >
> > Dear All,
> >
> > I want to generate a pictorial snapshot of all documents
> > going into a printer (both network and local).
> >
> > I have gone through the DDK sample for the same (bitmap), and have the
> > following
> > queries:
> >
> > 1. Would the sample work for both local and network printers (all kinds
> > of them).
> > 2. Is it possible to have a stack of rendering plugins? Normally the
> > printer driver installer installs one for us, can I add one of my own
> > into this stack, or do I need to hook into the existing COM interfaces.
> >
> > Please help.
> >
> > Regards — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
You can do that if the rest of the plugins are also part of your driver.
You cannot insert a rendering plugin into *any* driver and have it
intercept all calls. The rendering plugin is installed via the printer
INF. So unless your plugin is installed as part of any print queue that
you want to track, it cannot intercept calls. But once you have your own
chain setup, what you do within each rendering plugin is upto you.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Wednesday, August 30, 2006 8:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] rendering plugins
…just wondering…
is it possible to do this:
write a rendering plugin that behaves properly in any rendering stack
and also redirects output to a file.
What i mean is, the plugin will intercept the calls to the driver (or
the next plugin) and do some processing(like dumping a bitmap…etc) and
pass on the acll to another plugin which actually writes the data to a
real printer???
On 8/30/06, Bedanto wrote:
Ashwin,
Thanks for the reply. But I have some doubts.
here is the hpc4345b.ini file that is installed as pat of the HP
laserjet series.
#
# OEM plugin configuration files for Unidrv
#
#
# Unified UI/Render plug-ins
#
[OEMFiles]
OEMDriverFile1=HPZ5R043.DLL
OEMConfigFile1=HPZUI043.DLL
I tried adding the bitmap driver to this stack like this:
[OEMFiles]
OEMDriverFile1=Mybitmap.DLL
OEMDriverFile2=HPZ5R043.DLL
OEMConfigFile1=HPZUI043.DLL
What I observe is that only my DLL gets called and not the HP
one.
reversing the oder ensures that only the HP DLL is called and
not mine.
What changes do I have to make in bitmap sample to get it to
work properly with other rendering plugins.
On 8/30/06, Ashwin Needamangala
wrote:
1. It could work in both local and network scenarios but
might need some modification. It is currently set to be installed on the
FILE: port which thereby prompts the user for the filename at the time
of rendering. If you are fine with the user inputting the filename, you
shouldn’t have to change anything. But if you want the file to be saved
on the server, that’s a whole different story.
2. Yes…you can have a chain of rendering plugins. You
would just list them as OEMDriverFile1, OEMDriverFile2, OEMDriverFilen
in the ini file.
Hope this helps.
- Ashwin
________________________________
From: xxxxx@lists.osr.com [mailto:
xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of Bedanto
Sent: Tuesday, August 29, 2006 11:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] rendering plugins
Dear All,
I want to generate a pictorial snapshot of all documents
going into a printer (both network and local).
I have gone through the DDK sample for the same
(bitmap), and have the following
queries:
1. Would the sample work for both local and network
printers (all kinds
of them).
2. Is it possible to have a stack of rendering plugins?
Normally the
printer driver installer installs one for us, can I add
one of my own
into this stack, or do I need to hook into the existing
COM interfaces.
Please help.
Regards — Questions? First check the Kernel Driver FAQ
at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR
Online at http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
- amitr0 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>
yes ashwin,
that is what I knew (from my very meagre knowledge). however, from the
previous post from the original poster, I thought that such a scoop was
possible!!
amitr0
On 8/30/06, Ashwin Needamangala wrote:
>
> You can do that if the rest of the plugins are also part of your driver.
> You cannot insert a rendering plugin into any driver and have it intercept
> all calls. The rendering plugin is installed via the printer INF. So unless
> your plugin is installed as part of any print queue that you want to track,
> it cannot intercept calls. But once you have your own chain setup, what you
> do within each rendering plugin is upto you.
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Wednesday, August 30, 2006 8:34 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] rendering plugins
>
>
> …just wondering…
>
> is it possible to do this:
>
> write a rendering plugin that behaves properly in any rendering stack and
> also redirects output to a file.
>
> What i mean is, the plugin will intercept the calls to the driver (or the
> next plugin) and do some processing(like dumping a bitmap…etc) and pass on
> the acll to another plugin which actually writes the data to a real
> printer???
>
>
>
>
>
> On 8/30/06, Bedanto wrote:
> >
> > Ashwin,
> >
> > Thanks for the reply. But I have some doubts.
> >
> > here is the hpc4345b.ini file that is installed as pat of the HP
> > laserjet series.
> >
> >
> >
> > #
> > # OEM plugin configuration files for Unidrv
> > #
> > #
> > # Unified UI/Render plug-ins
> > #
> >
> > [OEMFiles]
> > OEMDriverFile1=HPZ5R043.DLL
> > OEMConfigFile1=HPZUI043.DLL
> >
> >
> >
> > I tried adding the bitmap driver to this stack like this:
> >
> > [OEMFiles]
> >
> > OEMDriverFile1=Mybitmap.DLL
> > OEMDriverFile2=HPZ5R043.DLL
> > OEMConfigFile1=HPZUI043.DLL
> >
> >
> > What I observe is that only my DLL gets called and not the HP one.
> >
> > reversing the oder ensures that only the HP DLL is called and not mine.
> > What changes do I have to make in bitmap sample to get it to work
> > properly with other rendering plugins.
> >
> >
> >
> >
> > On 8/30/06, Ashwin Needamangala wrote:
> > >
> > > 1. It could work in both local and network scenarios but might need
> > > some modification. It is currently set to be installed on the FILE: port
> > > which thereby prompts the user for the filename at the time of rendering. If
> > > you are fine with the user inputting the filename, you shouldn’t have to
> > > change anything. But if you want the file to be saved on the server, that’s
> > > a whole different story.
> > >
> > > 2. Yes…you can have a chain of rendering plugins. You would just
> > > list them as OEMDriverFile1, OEMDriverFile2, OEMDriverFilen in the ini file.
> > >
> > >
> > > Hope this helps.
> > >
> > > - Ashwin
> > >
> > >
> > > ------------------------------
> > > From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
> > > *On Behalf Of *Bedanto
> > > Sent: Tuesday, August 29, 2006 11:48 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] rendering plugins
> > >
> > >
> > > Dear All,
> > >
> > > I want to generate a pictorial snapshot of all documents
> > > going into a printer (both network and local).
> > >
> > > I have gone through the DDK sample for the same (bitmap), and have the
> > > following
> > > queries:
> > >
> > > 1. Would the sample work for both local and network printers (all
> > > kinds
> > > of them).
> > > 2. Is it possible to have a stack of rendering plugins? Normally the
> > > printer driver installer installs one for us, can I add one of my own
> > > into this stack, or do I need to hook into the existing COM
> > > interfaces.
> > >
> > > Please help.
> > >
> > > Regards — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> > >
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> >
> > — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
>
>
> –
>
> - amitr0 — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
Ashwin,
Thanks for the reply.
You can do that if the rest of the plugins are also part of your driver.
See I need to somehow device a way of extracting the print job output as an
Image/PDF on way to the printer. The requirements are that it should work
for any printer installed either locally or via network. When a print is
fired, I get a snapshot in am image format, and the printer also prints the
hard copy.
Is there a way to do this actually? I am a novice in printer drivers, and
reading the DDK docs and OSR forums and googling didnt help much. Please
help.
You cannot insert a rendering plugin into *any* driver and have it
intercept all calls. The rendering plugin is installed >via the printer INF.
So unless your plugin is installed as part of any print queue that you want
to track, it cannot >intercept calls.
What if I write a port monitor driver? Or something below the rendering
plugins? Is something like that even possible?
But once you have your own chain setup, what you do within each rendering
plugin is upto you.
How do I do that?
Also, what if I hook the rendering plugins COM interfaces using some COM
hooking mechanism. Is that the only way to achieve what is required?
Bedanto
Search the archives for a thread entitled “Question regarding Rendering
Plug In for Printer Driver”. You will find the outline of a method that
is known to work. Some people have had problems using it with the PS
driver but I don’t know about that having never tried it with a PS
driver.
ScottR
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Wednesday, August 30, 2006 12:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] rendering plugins
Ashwin,
Thanks for the reply.
You can do that if the rest of the plugins are also part of
your driver.
See I need to somehow device a way of extracting the print job
output as an Image/PDF on way to the printer. The requirements are that
it should work for any printer installed either locally or via network.
When a print is fired, I get a snapshot in am image format, and the
printer also prints the hard copy.
Is there a way to do this actually? I am a novice in printer
drivers, and reading the DDK docs and OSR forums and googling didnt help
much. Please help.
You cannot insert a rendering plugin into *any* driver and have
it intercept all calls. The rendering plugin is installed >via the
printer INF. So unless your plugin is installed as part of any print
queue that you want to track, it cannot >intercept calls.
What if I write a port monitor driver? Or something below the
rendering plugins? Is something like that even possible?
But once you have your own chain setup, what you do within each
rendering plugin is upto you.
How do I do that?
Also, what if I hook the rendering plugins COM interfaces using
some COM hooking mechanism. Is that the only way to achieve what is
required?
Bedanto
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Bedanto-
I don’t believe there is any reasonably achievable way to do what you want to do.
(1) There are printer drivers that don’t use the universal drivers and hence have no plugin support at all (usually called “monolithic” printer drivers).
(2) I used to do this sort of thing using a print processor. This is wonderful when EMF is spooled at app render time. But not all drivers spool EMF, particularly in network print situations [at one time I understood it was going to be deprecated, but I no longer work in printing, so someone else will have to address that for you]. EMF playback also has problems with some restrictive TT font licenses (Acrobat used to be a problem, IIRC). Also, the technique I favored [which I’d rather not disclose, because I don’t think it will help you] didn’t work well beginning with Windows XP (although there was a clumsy workaround for it). Finally, some parts of the print stream (separator pages, for instance) do not pass through the print processor.
(3) You might be able to create a “filtering port monitor” and see the stream before it goes on to the “real” port monitor the printer is normally connected to- but that means you are now creating your image from the printer’s PDL, not from GDI calls, EMF, or any other format. If you cover PCL, HPGL, and Postscript, you can get pretty wide coverage, but it isn’t easy, and there are always proprietary quirks. Maintenance can be a real nightmare. Finally, you are borrowing further trouble in keeping potentially quirky configuration information for the port monitor you are frontending.
This is not a project I would suggest for a novice. I worked in printer components heavily for about a decade, and while I think I could make it work if I kept hacking at it, I also think it would be economically unattractive- high NRE cost and likely very high maintenance, as well.
Just to be clear- I also haven’t worked in the printing area for at least three years. But an awful lot would have to have changed for this to have become easy.
Scott,
Thanks for the link, but I had already read it. Is there another simpler
way?
Robert,
Your inputs are in detail, but looks scary to me.
On 8/30/06, xxxxx@microsoft.com wrote:
>
> Bedanto-
>
> I don’t believe there is any reasonably achievable way to do what you want
> to do.
>
> (1) There are printer drivers that don’t use the universal drivers and
> hence have no plugin support at all (usually called “monolithic” printer
> drivers).
>
> (2) I used to do this sort of thing using a print processor. This is
> wonderful when EMF is spooled at app render time. But not all drivers spool
> EMF, particularly in network print situations [at one time I understood it
> was going to be deprecated, but I no longer work in printing, so someone
> else will have to address that for you]. EMF playback also has problems with
> some restrictive TT font licenses (Acrobat used to be a problem,
> IIRC). Also, the technique I favored [which I’d rather not disclose,
> because I don’t think it will help you] didn’t work well beginning with
> Windows XP (although there was a clumsy workaround for it). Finally, some
> parts of the print stream (separator pages, for instance) do not pass
> through the print processor.
>
> (3) You might be able to create a “filtering port monitor” and see the
> stream before it goes on to the “real” port monitor the printer is normally
> connected to- but that means you are now creating your image from the
> printer’s PDL, not from GDI calls, EMF, or any other format. If you cover
> PCL, HPGL, and Postscript, you can get pretty wide coverage, but it isn’t
> easy, and there are always proprietary quirks. Maintenance can be a real
> nightmare. Finally, you are borrowing further trouble in keeping
> potentially quirky configuration information for the port monitor you are
> frontending.
>
> This is not a project I would suggest for a novice. I worked in printer
> components heavily for about a decade, and while I think I could make it
> work if I kept hacking at it, I also think it would be economically
> unattractive- high NRE cost and likely very high maintenance, as well.
>
> Just to be clear- I also haven’t worked in the printing area for at least
> three years. But an awful lot would have to have changed for this to have
> become easy.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
after reading all these posts…I have an idea, I have never worked with
printers myself, so shooting from the hip here(as matt would say).
Experts please comment on it, I would learn from your rebukes.
All print jobs start with StartDoc.
Why not compile and install the bitmap driver in the ddk sample on the
machine.
Hook startdoc, and inside it, create yet anotehr print job with the same
buffer and send it to the bitmap printer. After that let the original API do
it’s work.
Would that work?
amitr0
>>Robert,
Your inputs are in detail, but looks scary to me.
<<
They’re meant to be. I’ve seen this sort of thing attempted a few times. I’ve built and used technologies that do this when I had control over the printer driver and every other piece you are allowed to build. Even then, I bent rules, used heuristically learned behaviors (hacked all over the place, in short), and many hours of hard work to get it in shape with reasonable eprformance. Then XP came along and it all broke again. Even without that, there were numerous shortcomings and performance issues basically designed in that I could do almost nothing about (eg, there are some graphics apps that execute so many drawing commands to do a page that the EMF exceeds the size of a 24bpp bitmap at page resolution by a breathtaking factor- yes, I could and did page the thing and could make it render, but performance matters, too, and that AIN’T fast).
Now you wish to do the same with an even tougher set of rules (for any printer installed on the system), and I’m thinking- “there’s someone in for a world of hurt”.
Consider that a 24bpp bitmap (3 bytes per pixel) at 600 dpi resolution (360K pixels per square inch) thus requires about 1MB / square inch. An 8.5 x 11 piece of paper with quarter inch unprintable area thus requires 84 MB- that’s one page image. A dozen of those will take up 1GB. I think you can see where this is leading. Even at monochrome, this page is over 1MB. If you scale down resolution, you degrade the image quality. You can find youself facing every graphics issue there is before you’re done. (At least it can seem that way).
I’m not saying don’t try to do it. But it won’t be easy, unless you’re willing to blow off anything that seems to difficult , so make sure it’s worth it.
>>Hook startdoc, and inside it, create yet anotehr print job with the same
buffer and send it to the bitmap printer. After that let the original API do
it’s work.
Would that work?
<<
(1) Blithely hooking an API is much easier to say than to do.
(2) It’s not enough, anyway. You also would have to hook each graphics call and process it the same way as the Startdoc call.
There are similar, but different, issues if you create a printer driver that gets all the printing calls from GDI, then passes the calls along to the “real” driver (something like a kernel filter driver). You could probably make this work by saving the calls off to the side, and then later asking GDI to create the bitmaps for you. But you’ve got something of an issue in actually making your printer driver get substituted every time someone adds a printer to the system.
Plus there are some nasty surprises regarding font substitution (printers can and do have their own fonts, and you do not know anything about their real appearance in the most general case) waiting for you here.
Perhaps bad form to post twice with no intervening replies, but I’ll add that another problem you’ll encounter eventually is the issue of PDL escapes- some applications will see that they are printing to a particular printing technology, and in the belief (sometimes true) that they can do a better job of rendering the image directly in the PDL than by asking Windows to do it, will emit the PDL directly into the data stream. To faithfully render these, you will need your own imaging engines for these PDLs.
If you’re willing to do that, then I believe the best approach would be a language monitor you somehow attach to every printer [that’s a bit of handwaving, BTW]- but if the printer already has one, you’re possibly getting into dangerous territory again. Filter the writes, identify the PDL in use for said printer, then use the appropriate rendering engine.
Real fun when you’ve got a printer that supports more than one PDL, although most of those that I can remember typically switch at the document boundaries. So if you sniff to decide (or for that matter, you can interpret the switch commands, since they should be in the stream by then), you’re probably OK.
But myself, I’d still be paranoid (perhaps one reason I’m working on kernel drivers, instead).