Looking for Distiller Windows Registry setting to set pdf output filename

[Matthia...@adobeforums.com]

I'm trying to print to PDF from Excel and Word using Acrobat Distiller. I know I can use the Excel.Application.PrintOut(...) parameters to determine the output filename, but for some reason this doesn't work. The created PDF file is not readable. If I do not determine the output filename, it is automatically saved to the Windows desktop and in this case it is readable.

I'm using Acrobat 5.05 and it looks like a bug in the Distiller printer driver to me. So I'm trying to find a way to set a new default output directory. I thought there must be a registry setting for this.

this is what I do so far:

Call SetStringValue("HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\5.0", "AskForPdfFileName" , "00")
Call SetStringValue("HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\5.0", "AskToReplacePdfFile" , "00")
Call SetStringValue("HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\5.0", "ViewInteractiveOutput", "00")
Call SetStringValue("HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\5.0", "ViewPrintOutput" , "00")
Call SetStringValue("HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\5.0", "JobOptions" , "Print")

Set stats.XlsAppl = CreateObject("Excel.Application")
Call stats.XlsAppl.Workbooks.Open(xls_filename)

Set stats.XlsWBook = stats.XlsAppl.Workbooks(1)
Set stats.XlsSheet = stats.XlsWBook.Worksheets(1)

stats.XlsAppl.ActivePrinter = printername ' e.g. "Acrobat Destiller on NE01:"

Call stats.XlsWBook.PrintOut(,,,False,,True,,pdf_filename)

The above code creates a corrupted PDF file which is also hugh in size compared to the original file (e.g. 17KB Excel to 178KB PDF). The output is however located in the correct output directory with the given filename.

If I use the following line instead:

Call stats.XlsWBook.PrintOut()

The pdf file is created on the Windows desktop with the same name as the printed Excel file but with a .pdf extention. This pdf file is perfectly readable.

Environment Info:

Windows 2K or XP with different service packs
512MB to 1GB RAM
Intel Pentium 3 and 4
Acrobat 5.05
Xerox Document Centre (printer)

The problem does not seem to be environment related, as the effect is the same on several PCs with different configurations.

[Ian_B...@adobeforums.com]

I think the PDF turns up on the desk top because of the settings of the PDF Port on the machine you're working on. Try changing the PDF port path to one you prefer.
Cheers
Ian

[Matthia...@adobeforums.com]

You're perfectly right, but how do change the setting. It is not possible from the Printer Properties dialog (there is nothing to configure says the dialog) and in any case, I need to programmatically change the setting. Thanks anyway.

[Aandi_...@adobeforums.com]

>I'm trying to print to PDF from Excel and Word using Acrobat Distiller. I know I can use the Excel.Application.PrintOut(...) parameters to determine the output filename, but for some reason this doesn't work. The created PDF file is not readable.

It's working as designed, but you are missing a step. This makes a
PostScript file, NOT a PDF file.

You then use Distiller, via the Distiller API, to convert the
PostScript to PDF. Details in the Acrobat SDK.

I really advise strongly against what you are doing - programming
Acrobat by investigation and discovery. It is more fun, but if you
want something to support, stick to ONLY what you find in the SDK.

Aandi Inston

[Ian_B...@adobeforums.com]

I go with Aandi on this. What you're doing can be made to work on a given machine, but is not a transportable solution. Use only those commands available from the SDK.

Regarding changing the path for the PDF port, it can be done from Start>Printers. Select the Acrobat Distiller Printer and use File>Properties. Select the ports tab and create a new PDF port with a new path. Connect the Acrobat Distiller printer to the nex PDF Port. Delete the old one if you want to.
Cheers
Ian

[Matthia...@adobeforums.com]

I do not want to use the API, but ultimately I will have to.

However, I do not agree that it works as designed. The Excel method .Printout(no parameters) or .Printout(to defined filename) should both work the same way in that Distiller completes the task of printing AND converting. The fact that Acrobat Distiller printer driver stops half way through the process looks like a bug to me.

[Matthia...@adobeforums.com]

If Distiller would recognise the output filename, there would be no need to use any registry settings. I'm going this way in an attempt to work arround an obvious feature limitation (I would call it a bug).

[Aandi_...@adobeforums.com]

>I do not want to use the API, but ultimately I will have to.

Why on earth not? APIs are put there for programmers to use.

>
>However, I do not agree that it works as designed.

It works the way ACROBAT was designed.

It is not a bug in Acrobat because it is doing exactly what Adobe
intended.

Aandi Inston

[Aandi_...@adobeforums.com]

>(I would call it a bug).

You can call it what you like, of course. I'll call it a grawl, to
avoid arguments about words which have particular meanings.

Here is some more background on the Distiller printer driver.

When you print to a printer driver to print, a two stage process takes
place.
1. The driver creates a file in printer language, that the printer
understands.
2. The file is sent to a "port", typically something that talks to the
printer down a cable.

The end result, you get the printout. If you choose "print to file",
only step 1 takes place.

The "port" need not have a printer attached. For instance there are
fax ports, where the file goes off to a fax instead. If you print to
file, no fax gets sent.

Now, Adobe used to have PDFWriter, a printer driver which made PDF all
in step 1. It typically used a port of LPT1, but nothing ended up
there.

Distiller works differently. It uses the tried and tested PostScript
printer driver to make a PostScript file in stage 1. In stage 2, a
"PDF port" takes the PostScript file and makes a PDF. So you can see
that if you print to file, you bypass stage 2, and get no PDF.

This could probably be changed to work as you wish, rather than as it
was designed, but as it would break the code for all of the people
who've correctly used the SDK, it would hardly be a popular move.

Aandi Inston

[Matthia...@adobeforums.com]

Aandi, I'm quite long in the business of developing software. We're talking about almost 3 decades. One of the things I have learned over the years when developing software for other people is that they are usually not developers and they do not understand technicalities. They will just tell you if a feature is not working as one without background knowledge would expect. Things that are inconsistent will not be accepted.

As I do not yet know much about how Acrobat Distiller works, I took the "privileged" stand of an end-user saying that this is not logic.

After your explanation of course I can judge that this is probably not a Distiller problem as such, but a problem how the Windows maker thought of defining the printer driver interface.

Anyway, after you mentioned that the file is still a PostScript file, I simply used the Distiller COM objects to complete the task, no registry settings required.

So after all the discussion I thank you anyway as you lead me to the solution.

Thanks again.

[Aandi_...@adobeforums.com]

> I simply used the Distiller COM objects to complete the task, no registry settings required.

So you are using the Distiller API... now, what was your objection to
doing so, several messages ago?

Aandi Inston

[Matthia...@adobeforums.com]

Are we talking about the same thing?

The API (Application Programming Interface) is usally a set of functions stored in a DLL which you need to declare in your code that provide an interface to another application. Taking a VB example the code looks like...

Declare Function GetProfileString& Lib "kernel32" Alias "GetProfileStringA" (Byval lpAppName As String, Byval lpKeyName As String, Byval lpDefault As String, Byval lpReturnedString As String, Byval nSize As Long)

COM (Common Object Model) in the contrary refers to object classes that are registered as Windows Classes. You program with COM objects fairly different as we are talking about object oriented programming here. Again a VB example...

' no declaration required as the information about the object model
' is available in the registry and the object class definition.
Set distobj = createobject("PdfDistiller.PdfDistiller")

OK, you could probably simplify it in saying the API is a simpler interface type then COM, but serves the same purpose. So
if you where referring in your previous postings to the Destiller COM objects then I was misunderstanding you. For me API programming is just something completely different as opposed to COM programming.

Don't get me wrong, I don't want to split hairs. When you where referring to the Distiller API I just had the Windows API in mind and I try to avoid the Windows API if I can.

[Aandi_...@adobeforums.com]

>The API (Application Programming Interface) is usally a set of functions stored in a DLL which you need to declare in your code that provide an interface to another application. Taking a VB example the code looks like...

Some background...

An API is an Application Programming Interface, yes.

It might be a DLL, a COM or OLE interface, a series of Macros to use,
a library, a documented command line, XML formatted data streams over
a network socket, a rule for using the registry - anything for
communicating from your program to a facility. The Acrobat SDK
documents many APIs in Acrobat, which use the above and some other
methods.

Similarly, whatever you use to talk to Windows is an API. The "Windows
API" you mention is part of the facility. And indeed, Microsoft refer
to this historically as the "Windows API", mainly because at one time
it was the only API for Windows (before COM, before OLE, and when you
could learn it all from just one book...)

The Distiller API offers the chance to control Distiller by OLE, by
command line, and some other methods.

Some say that the important thing about an API is that it is
documented. This view is supported by
http://looselycoupled.com/glossary/API . I would argue that anything
just discovered - rather than read in an official document - might not
be an API but an accident, and my company's policy is to forbid any
"discovery" of APIs. We can't afford the consequences.

Aandi Inston

[Matthia...@adobeforums.com]

OK, point taken. You never stop learning :-) Excuse my missunderstanding.