The Facts (WAS: Distiller Trivia (WAS RE: Frame 6 files only distilling in Black and White - help!))

[Dov Isaacs <isaacs@xxxxxxxxx>]

For the record:

(1) The installers for Acrobat 5.0.5 do indeed install a Distiller printer
instance built from the correct PPD. Install the Distiller, you get the latest
PostScript driver, the PPD, printer instance, and all the plumbing setup
automatically to do direct-to-PDF-port printing. This is true on both
Windows and the Macintosh.

(2) With Acrobat 5.0.5, the driver plugins that provide the full plumbing
for the special printer instances only really work with the Acrobat Distiller PPD,
although conceivably, one could do some registry hacking etc. to get around that.

(3) The next major release of FrameMaker in fact is going to do just what you
suggest. It will only work with the official Acrobat Distiller printer instance,
whether on Windows or Macintosh. I am actually in the process of testing this
for Adobe's FrameMaker development group and its looking very good! 
This already occurs with PageMaker 7.

(4) For better or worse, Acrobat does allow the user to screw themselves over
as much as they want. For historical purposes, the Distiller does allow users
to use "watched folders" to distill or "open" any arbitrary PostScript file.
Historically, i.e., prior to the days of the GUI-based OS, and still with some
applications, PostScript was pretty output in a fairly device-independent manner
by applications. We need to continue to support such applications and specialized
workflows via a generalized ability to distill arbitrary (and hopefully not
capricious) PostScript files. The user is free of course, not to use either of
these features. In fact, the only time I explicitly open a file with the Distiller
is when I need to debug a PostScript file, typically from some errant application
or driver. For production work, I always use the direct approaches of the
automatic printer instance associated with the Distiller PPD. 

(5) Richard comments on what "Acrobat" should do. However, Acrobat is not in
control of the workflow to initiate creation of the PDF file. The metaphor in
use, for better or worse, is that the user either "saves", "exports", or
"prints" to create PDF from the application program. It is those processes that
invoke Acrobat, not vice versa. On the other hand, we are trying to incorporate
features such as the new "save as PDF" in the next FrameMaker as well as in
PageMaker 7, Export PDF in InDesign, PDFMaker in Microsoft Office, and other 
features in future versions of Acrobat to dummy-proof the process of PDF
creation as much as possible. Surprisingly enough, if you read the postings
on this list and others, it is amazing what type of contortions some end-users
will go through to create PostScript and subsequently distill same via some 
magical voodoo based upon oral tradition, urban legends, myths, and "bubbameissers" 
passed on by fellow end-users.

        - Dov


At 3/20/2002 03:48 PM, Richard Combs wrote:
>Adam Korman [mailto:Adam@cooper.com] wrote: 
><snip> If you use device-dependent input
>> (Postscript made with your printer driver), you will get device-dependent
>> output. The instructions from Adobe are clear and unequivocal: to create
>> device-independent PDFs, use the Distiller driver. There is nothing to be
>> gained by using your printer driver.
>> 
>> Of course, that begs the question -- if this is the case, why allow it at
>> all? I'm guessing that it's just an implementation hack rather than of any
>> real benefit to users.
>
>Amen! Instead of Dov and others endlessly repeating the same instructions for how to install Acrobat and create PDFs, Acrobat should (without any prompting of or decisions by the user): 
>
>(1) Install a Distiller printer instance built from the correct PPD. It shouldn't even be _possible_ to create a Distiller printer instance with anything else. 
>
>(2) Use that printer instance whenever (and however) you choose PDF output. (This would fix the problematic "Save as PDF" function in FM.)
>
>When you want to create a PDF, the only thing you should _have_ to decide is the file name. 
>
>Why should you have to be taught the right way to do it when the software can simply do it the right way for you? There's nothing to be gained by giving people a choice they should never use, is there? 
>
>Richard


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **