Adobe refuses to "server-side" render

Thanks in advance for everyone's help.

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

> 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.

I think they use some "PostScript passthrough" call to the driver.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Maxim S. Shatskih wrote:
>> 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.
Acrobat doesn't generate PostScript, what it does is to convert PDF into
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.

> PostScript (PDF is actually a derivative of PostScript I believe).

Binarized PostScript I think.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

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:

> > 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.
>
> I think they use some "PostScript passthrough" call to the driver.
>
> --
> Maxim S. Shatskih
> Windows DDK MVP
>
> http://www.storagecraft.com
>
> .
>

> 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.

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.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Nate Clark <> wrote:
>
>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,
Providenza & Boekelheide, Inc.

The driver launches an application to bring up the pdf document and obtain a
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:

> Nate Clark <> wrote:
> >
> >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,
> Providenza & Boekelheide, Inc.
> .
>

> The driver launches an application to bring up the pdf document and obtain a
> 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.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

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:

> > The driver launches an application to bring up the pdf document and obtain a
> > 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.
>
> --
> Maxim S. Shatskih
> Windows DDK MVP
>
> http://www.storagecraft.com
>
> .
>