PDF XChange Forum

The environment is W2003 Terminal Server with Windows 7 RDP clients.

When the PDF-XChange Printer 2012 is installed on the server, our application can select and print to it from any client connection. However when the PDF-XChange Printer 2012 driver is NOT installed on the server, but IS installed on the client, then we can select it (e.g. "PDF-XChange Printer 2012 (from JACK-PC) in session 1") and generate a PDF, but it acts as if unlicensed (prints the demo watermark), and also seems to ignore all the efforts to set properties.

Is this normal?

Note that with the V3 API, RDP sessions could use either a server-installed PDF-XChange 3.0 printer or client-installed copy with seemingly identical results. I can envision this causing problems or at least confusion when we start upgrading end-user sites.

Thanks,
Jack

Do you use SDK to create a printer or use End-user printer?

I'm using the SDK, as in the CExAPI example. (By "...installed on the server" I meant the SDK/API version of the printer installation.)

Hi Musabio,

I've passed this back to Ivan, and he will come back with further details as soon as he gets back in the office (it's quite early in the morning where he is).

Regards,
Stefan

I'm starting to worry about Ivan. Did he ever make it back?
Jack

Hi Jack,

Apologies for the delay all of the Developers are currently focusing on the Editor SDK documentation, so it can be a little tricky to get time with that at the moment. Unfortunately, this is causing more of slow down than we'd like, but we should return to normality with the next release.

I'll pass this along today, once he's in, and will do what I can to get some kind of a response today.

Sorry for the delay - as Will says we are quite busy right now with preparing release of our Editor's SDK.

In regards of your issue. It seems you are using SDK in an incorrect way. You saying:

but IS installed on the client, then we can select it (e.g. "PDF-XChange Printer 2012 (from JACK-PC) in session 1") and generate a PDF, but it acts as if unlicensed (prints the demo watermark), and also seems to ignore all the efforts to set properties.

But unlike V3 SDK, V4 and V5 driver's SDK creates a new printer and you can control settings of that printer, not existing end-user printer.
So, it seems that your application had created new printer, but choose existing end-user printer to print the job. In that case your settings will be ignored as these settings have been applied for created SDK printer.
In case when printer is installed on the server, you have no watermarks as the end-user printer had valid serial key, I suppose.

Thanks for the follow-up. I wasn't clear either in what I said or what I was thinking. What I meant was that from the user's perspective, they select the original end-user printer (e.g. in a printer selection dialog box), and then the application recognizes it as the PDF-XChange printer and creates the new printer via the API. This is what I meant when I referred to selecting the client-installed printer.

So to start over, stripping things down to the basic problem, my question is whether one must install the v5 driver/API on the server (and not the client) if one wants to use the capability within RDP. I'm guessing that the answer is yes. (Unlike in the v3 driver, where the RDP session could use the client's PDF-XChange 3 driver just like any other client-installed printer driver.)

I repeated my test with another RDP server which had no trace of PDF-XChange on it, and now the (client-side) PDF-XChange Printer 2012 does not show up at all in the server printer list, so the user doesn't even have a way to select it (at least via the Windows printer selection dialog). I'm not sure why it showed up in my previous test, but perhaps it had something to do with some part of the SDK also having been installed on the server.

I guess I'm ok with the requirement of installing the driver/API on the server, but just wanted to be sure that was necessary and correct before spelling it out in our upgrade instructions to users.

Thanks again,
Jack

Sorry Jack - this seems to have been over looked - can you advise if this is still an issue for you ?