Adobe refuses to "server-side" render
Nate Clark
I have written a driver based on the pscript5 mini-driver.
Seems to work fine, but ...
It is important that this driver, when shared from another computer, execute
on that server.
The ddk docs speak of the "client-side" rendering introduced in Vista.
What is happening is that, as far as I can tell, EVERY application EXCEPT
Adobe Reader and Acrobat are honoring this - i.e., sending the job to the
server.
For some reason Reader and Acrobat refuse to do so, and always execute the
driver on the client - EVEN after setting both the EMFSpoolingSettings thing
AND after explicitly setting off the "client-side" option in the Vista
printer properties AND after setting a certain security setting in group
policy that allows this.
Again, only Reader and Acrobat refuse to honor these settings !? Every other
application I try works correctly.
Further, this is also true if I do this from an XP machine - driver is
getting executed client-side (even though I thought it was a Vista
enhancement only (?) )
I really need Reader to honor this setting.
Does anybody know of any reason why this might be ? Or a way to coerce Adobe
into following the standard ?
I am more than will to write a "print processor", or "print provider", or
"port monitor", but, for the life of me, I can't figure out which of these
might be the correct approach for this kind of problem (?)
Two other questions that might be related:
1) When Adobe prints - it never calls textOut in my driver. It seems to me
adobe is bypassing parts of pscript5, I guess that's okay, but I'd really
like to receive those textOuts.
2) For some reason, my driver is getting instantiated multiple (sometimes 4
or 5 times) during a print job. Have put logging in it to figure it out,
seems to create the COM object, call EnableDrv, then DisableDrv, then creates
a new one, etc. It looks like it has a bunch of "false starts" before
continuing on with the job.
As for #2 - is there some return code somewhere that I'm missing to allow
the initial print driver to handle the job ? Maybe this is related to why
Adobe ends up ultimately insisting on using the local driver all the time .
BTW - I also note that the local driver get's called at all times, even when
printing a test-page on the shared printer (from the client). I assume this
is alright - but for some reason the test-page does ultimately get to the
server, as I want.
Seems like there might be something I need to be doing in my driver to
force/or request the job to move on to the server ?
Thanks everybody, this is a very important to me and I really do appreciate
any help.
Nate Clark
Maxim S. Shatskih
> adobe is bypassing parts of pscript5
Yes. Adobe is known to do the job of PostScript generation for PostScript printers themselves, not relying on pscript5 Windows driver.
I think they use some "PostScript passthrough" call to the driver.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Jonathan Wilson
>> 1) When Adobe prints - it never calls textOut in my driver. It seems to me
>> adobe is bypassing parts of pscript5
>
> Yes. Adobe is known to do the job of PostScript generation for PostScript printers themselves, not relying on pscript5 Windows driver.
PostScript (PDF is actually a derivative of PostScript I believe). There is
no way to tell Acrobat not to do this unless you somehow write a driver for
your printer that lies to windows and pretends its not a PostScript printer.
Maxim S. Shatskih
Binarized PostScript I think.
Nate Clark
Thanks to both of you Maxim and Jonathan,
I kind of suspected Adobe is doing most of the work in preparing the
document for print, it's them after all that should best understand the
language (and I believe they wrote pscript5 for MS). And this probably would
result in bypassing pscript5.
I wish they also wouldn't bypass it in other areas like I'm suspecting :(
The reason to trap txtOut is that it provides the destination coordinates of
the text, the rectangle where it should appear - that can be very handy.
BTW - I do appreciate your answers - but I made a goof - I mistakenly hit
the "Did this post answer the question" button thinking it was to reply (now
you know, my most likely problem is advanced age and reduced eyesight)
SO - to all - and with due appreciation to Maxim and Jonathon - this is not
really answered - still need to get Adobe to honor the print using server's
driver setting.
As an aside - I have found that Foxit successfully WORKS here.
Thanks again,
Nate Clark
"Maxim S. Shatskih" wrote:
> .
>
Maxim S. Shatskih
> the text, the rectangle where it should appear - that can be very handy.
Then probably your printer driver should not be pscript5-based.
Looks like Adobe will still print using usual Windows GDI if the printer is not PostScript.
Tim Roberts
>
>BTW - I do appreciate your answers ...
>SO - to all - and with due appreciation to Maxim and Jonathon - this is not
>really answered - still need to get Adobe to honor the print using server's
>driver setting.
It IS answered. It can't be done. Acrobat is doing what it wants to do,
and you can't stop it. End of story.
What is it that you re hoping to gain by deferring rendering to the server?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Nate Clark
signature from a signature pad connected to that computer and embeds that
signature in the pdf. Allowing someone to get a document signed by simply
printing it to someone's computer.
It CAN be done - I have proposed that adobe seems to be bypassing the normal
mechanism, but I cannot prove it, and I will not give up until I either prove
this to be the case or I find out what it is i'm not doing to handle adobe's
print jobs.
As I mentioned in my OP, if it means I have to write a print provider, print
processor, or port monitor, I will do so.
"Tim Roberts" wrote:
> .
>
Maxim S. Shatskih
> signature
At what level are you filtering? if you're at WriteJob level - then the data formats there can be PostScript itself or the EMF.
With Reader+pscript5, this will be PostScript itself (no EMF at any level). Not a problem for GhostScript-based app to interpret and render.
Even if you're hooking the GDI calls between GDI and the driver, you must have a layer somewhere who translates these calls to a PDF file. With PostScript passthrough, things are even simpler.
Nate Clark
Hi Maxim
I implement IPrintOEMPS2 and in WritePrinter I intercept the ps stream on
it's way to the printer. It is definetly ps and yes, ghostscript has no
problem with it.
Also, in EnableDriver - I supply hooks for:
DrvStartDocument
DrvStartPage
DrvTextOut
DrvEndDocument
All of these work into my process correctly (except DrvTextOut doesn't get
called when Adobe prints, though everything else does)
"WriteJob" has an interesting name in that it seems at a higher level than
"WritePrinter" and maybe points toward my solution. However, a quick search
in the DDK help doesn't uncover it !? Did you mean WritePrinter ?
Thanks,
"Maxim S. Shatskih" wrote:
> .
>
Maxim S. Shatskih
Probably.
The name of the function called by the driver to output the bytes to the print processor/spoolsv.exe
Nate Clark
Thanks again for all the help Maxim,
I noticed an interesting thing today - first, I have a lot of logging in my
driver to see what's going on.
My premise that Adobe doesn't print on the server is based on the fact that
this log on the server is empty, i.e., it's never even instantiated there.
However, today I had a view of the server's print queue open and sure
enough, the print job appears there momentarily and then disappears - gets
redirected back to the client ! Without even attempting to open the local
driver (the log is still empty).
Anyway - this may be a clue to what's going on - I need to investigate why
for some reason a server might kick a job back to the client. I had a
fleeting thought that what if this "render job on client" setting works in
reverse !
Anyway, no need to reply - if and when I solve this, and if this thread's
still around - I'll post my solution. But for now, I need to step back and
think of another way to debug this.
(I'm not giving up, I promise !)
Regards and have a great new year !
Nate Clark
"Maxim S. Shatskih" wrote:
> .
>