Re: Adobe's PDF

kevin@scic.intel.com (Kevin Altis)
Message-id: <9307191809.AA12993@rs042.scic.intel.com>
Date: Mon, 19 Jul 1993 11:07:45 -0800
To: cailliau@cernnext.cern.ch, kehoe@fortuity.sf.ca.us (Daniel Miles Kehoe)
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: Re: Adobe's PDF
Cc: www-talk@nxoc01.cern.ch
Status: RO
At  6:12 PM 7/16/93 -0700, Daniel Miles Kehoe wrote:
>I cannot attend the WWW conclave, but wish to affirm the priorities  
>suggested by Robert Cailliau -- most particularly, his recognition of  
>the importance of easier authorship of HTML documents.
>
>Cailliau also mentions incorporating into browsers the ability to  
>display
>
>>  a few wisely chosen formats (for graphics)
>
>including Adobe's new PDF format.

PDF viewers have to be able to render PostScript! Rendering is slow even in
Adobe's browser...

>PDF files are much more compact than PostScript files.

Depends on what kind of information is in the PostScript file versus the
PDF file. PDF files wouldn't normally contain font information because the
Arobat viewer relies on Multiple Master font rendering (another thing you
need), yes LZW compression can be used on text and there are lots of
options for compressing images using "lossy" techniques. To make a fair
comparison, run a .ps file through the distiller and see what you get. Keep
in mind that PDF and the Acrobat technology right now is oriented towards
screen viewing, so resolutions higher than 72-100 dpi are usually a waste.

>Adobe offers commercial products that will generate a PDF file from  
>any Mac or Windows application and from any PS file generated on any  
>other platform.

There will be a Unix version as well. The output from the PDFWriter is
fine, but if you output from a desktop publishing application or your
document contains embedded PostScript, etc. you have to use the Distiller,
just like for .ps files; this is a slow process and the licensing on the
Distiller is much higher than the basic Acrobat viewer/PDFWriter.

>It appears the format of PDF link annotations could be extended to  
>accomodate URLs, if browsers were available to read them.
>
>PDF hyperlinks are rectangles on a page (that is, they are not  
>anchored in text and can be placed over nontextual matter).
>
>Adobe has stated that the PDF format is extensible and indicated a  
>willingness to work with third-party developers (unfortunately,  
>Adobe's organization is such that commercial developers gain easier  
>access).
>
>I'd be happy to hear from anyone who's interested in working with  
>Adobe. Perhaps we can develop interest in WWW at Adobe.

While PDF has promise, it has a completely different focus than the Web
right now, specifically presentation instead of structured documents. The
Web will have worldwide multi-user editing and annotation of HTML documents
across multiple platforms well before Adobe even knows if Acrobat is a
flop. Adobe definitely has to take the ball here. While they might change
Acrobat's market focus in the future to work with networked hypertext such
as the Web, it won't happen anytime soon and it would be a waste of energy
right now to pursue PDF as part of the Web.

We can however benefit from some of the interface elements used in Adobe's
viewer, which have been used in viewers before, so the ideas are well
tested. One, graphical browsers should be able to generate "thumbnails" of
a user settable "page" size as a navigation aid within a document;
eventually this iconic view can be extended to give a 2-D or 3-D overview
of a document and its links to other documents. Two, outline views of
document(s) and their links should be available. This would also simplify
identifying annotations and threads of annotations related to a particular
point or link within a document. A browser could even follow links within a
document, caching potential destinations and showing those as part of the
hierarchy. The "outline" view might be a separate window (floating on the
Mac or Windows), or appear as a dynaic menu or split pane on the browser
window. Three, the ability to copy information from a document, either in a
HTML and/or formatted form (including font and style information) should be
supported when possible, especially on the Mac and Windows platforms where
the "clipboard" is standardized across applications.

ka