printer driver retrieving filename

From what I’ve read on http://www.osronline.com/showThread.cfm?link=19117, Ashwin answered the fact that the printer driver/rendering plugin cannot retrieve the output filename. But I’m not sure about why that can’t be done easily within the printer driver programmatically. Is it b/c the functionality of the rendering plugin is only responsible for rendering the image, whereas a custom print processor or language/port monitor is responsible for the output processing?

To further clear up my problem, I was trying to acquire the output filename from the DOCINFO structure passed in a test app when calling StartDoc(…) in the virtual printer driver. According to Ashwin’s reply on that link, it’s not possible to do so. However, I have tested using PDF Tools’ printer driver and that printer driver managed to access the DOCINFO structure somehow and save the file to the intended location. Is there a specific function/methodology that I’m overlooking to achieve what I wanted to do?

I had tried for this and failed. I was unable to find out how to get that file name. After lot of readings we had concluded that it is not possible to get the same.

-Srikanth


From: xxxxx@lists.osr.com on behalf of xxxxx@hotmail.com
Sent: Fri 6/27/2008 3:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] printer driver retrieving filename

To further clear up my problem, I was trying to acquire the output filename from the DOCINFO structure passed in a test app when calling StartDoc(…) in the virtual printer driver. According to Ashwin’s reply on that link, it’s not possible to do so. However, I have tested using PDF Tools’ printer driver and that printer driver managed to access the DOCINFO structure somehow and save the file to the intended location. Is there a specific function/methodology that I’m overlooking to achieve what I wanted to do?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

On Fri, Jun 27, 2008 at 05:02:30PM -0400, xxxxx@hotmail.com wrote:

From what I’ve read on
http://www.osronline.com/showThread.cfm?link=19117, Ashwin answered the
fact that the printer driver/rendering plugin cannot retrieve the output
filename. But I’m not sure about why that can’t be done easily within
the printer driver programmatically. Is it b/c the functionality of the
rendering plugin is only responsible for rendering the image, whereas a
custom print processor or language/port monitor is responsible for the
output processing?

It’s because a file in the print spool is just a stream of printer
commands. They don’t necessary have ANYTHING to do with a file or a
file name. Some application might have produced the spool file from
the contents of another file, but that information ins not part of
the spool file.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

If this is for situations where “…user has chosen to ‘Print to
file’…” you should be able to read this information from the UI plugin
when hooking StartDoc, you could then relay it to the rendering plugin
by storing it in the DEVMODE struc or some other way

/christoph

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-328476-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, June 27, 2008 11:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] printer driver retrieving filename

From what I’ve read on
http://www.osronline.com/showThread.cfm?link=19117,
Ashwin answered the fact that the printer driver/rendering plugin
cannot
retrieve the output filename. But I’m not sure about why that can’t be
done easily within the printer driver programmatically. Is it b/c the
functionality of the rendering plugin is only responsible for
rendering
the image, whereas a custom print processor or language/port monitor
is
responsible for the output processing?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks for the explanations. I do have a follow up question to Christoph’s reply: after looking at the DEVMODE structure description in the DDK documentations, I am having trouble finding parameters that look highly likely to contain output filename/filepath. How easy would it be to implement a print processor/monitor (even though the functionality of the printer driver that i’m working on seems to be a print processor as well, as it’s converting from emf spooler file to another format that I want) that would save the output file to the appropriate desired location?

After doing more fishing in the DDK documentation in the document explorer, I found that DOCINFO structure can be accessed through a pointer in DrvDocumentEvent callback in DOCUMENTEVENT_STARTDOC flag option for iEsc (imo, I think the DOCINFO access methodogy should be documented in a more obvious place in the DDK documentation). Thanks for all your suggestions.

Sorry for the third consecutive email on this topic. I probably should’ve tested the DrvDocumentEvent callback with accessing the DOCINFO structure before posting the last email. Basically this is what I have so far in my attempt to access the filename from the DOCINFO structure passed by the StartDoc function called in the client application (the code below is in the interface application of the printer driver):

wstring outputfp; // <- this is a global variable in the ui.cpp file

INT DrvDocumentEvent(
HANDLE hPrinter,
HDC hdc,
int iEsc,
ULONG ulcIn,
PVOID pulIn, //PULONG pulIn,
ULONG ulcOut,
PVOID pulOut //PULONG pulOut
)
{

switch(iEsc)
{

case DOCUMENTEVENT_STARTDOC: // aka DOCUMENTEVENT_STARTDOCPRE
DEBUGMESSAGE((“DrvDocumentEvent - STARTDOC”));

// obtain DOCINFO here?
tempDI = (DOCINFO *) pulIn;
outputfp = wstring(tempDI->lpszDocName);

break;

}
}

I found that pulIn contains very different contents (i.e. blank, but not invalid pointer) from the DOCINFO that I passed in StartDoc in the client test application. What fundamentally am I doing improperly on my DOCINFO structure pointer that I have obtained in this case scenario?

As of now, I have managed to access DOCINFO structure inside DrvDocumentEvent before DrvStartDoc. However, according to the DDK documentation, I can’t use the output buffer to transfer the filename to my private devmode structure right now, therefore leaving it to using global variables right now. Is there anything that I have overlooked (and what I’ve overlooked) in terms of communicating the DOCINFO structure between DrvDocumentEvent in the ui and DrvStartDoc?

My apologies in advance if the wording in my last email sounded too vague. Basically, I’m trying to access the devmode/extended devmode structure in DrvDocumentEvent when iEsc == DOCUMENTEVENT_STARTDOC. How would I do so by using hPrinter and hdc handles? Thanks in advance for advices.