[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: PDF vs HTML

I would like, for a change, to make a couple of serious remarks on this.
They are but glosses to the general argument and don't pick up on the
general thrust of the arguments in this thread.

1) There is absolutely no doubt in my mind that the pdf format is far
better as a system than rag-tag HTML. The design of the format is superior,
the capabilties awesome and ease of generation second-to-none.

2) However, I must use HTML to deliver my documents within the Telstra
Corporate Intranet because:

   a) the corporate standard browser has remained stunted at IE v.3 due
      to the (outsourced to IBM) IT department. This stupid decision
      means that Acrobat 4 installed as an integrated application
      (Active X) with IE is not possible and, therefore, links between
      one pdf to another won't work over the intranet.

   b) If one does have a more advanced browser, such as IE 4/5, there
      is still no guaruntee that Acrobat has been installed properly
      as a browser-integrated application (not as a "helper"), a
      prerequisite for pdf-pdf links to work over an intranet.

   c) and even if Acrobat has been installed properly as per case b),
      the Evil Mr Gates as ensured that IE 5 in NT 4 SP 4 WILL follow
      a pdf-pdf link, but IT WON'T OPEN AT ANYOTHER PAGE EXCEPT THE FIRST.

   d) The particular site I'm working on today changes its content
      according to an arbitrary "access level" for users --
      i.e. privaledged users are able to see more material than the
      hoi poloi. This is really only possible using HTML, and webserver
      capabilities (in this case, Apache with php). It's just not
      possible with pdf given a), b) and c) -- think about it.

3) For that reason, I provide BOTH pdf & HTML. Pdf, because I adore the
format and because it allows people to get decent hard copies and to
zoom into complex diagrams. In HTML these really have to be provided
at high resolutions which don't readily fit into the browser window. There
are several kludges to overcome this, such as the www clasic solution
of providing a thumbnail which links into a higher resolution version
of the same diagram, but this has always struck me as being like
the street busker who plays the Big Tune from Beethoven's 9th on
the kazoo, while the whole symphony is being played round the corner
with full orchestra & chorus.

What really depresses me as that HTML is usually the winner, but for all
the wrong reasons, not from the point of view of readability or
user comprehension.

Ain't life a beach?


Dan Emory wrote:
> 
> At 10:52 AM 3/22/00 +0100, Cas Tuyn wrote:
> >----------------Snip--------------------
> >My EUR 0.02 regarding Dan's mail (clipped slightly):
> >
> >> What Utter Nonsense!
> >> 1. Experimental results have established that .....
> >> 2. Experimental results show that .....
> >> 3. ..... people understand more when the
> >> screen looks like a well-designed printed book.
> >> 4. Real-world experience ..... Most people who browse through
> >> long HTML documents adopt the print-before-reading habit
> >
> >IF
> >   you see online publishing as onscreen viewing of information
> >   layed out such that it requires an A4 monitor with a 600 dpi
> >   resolution,
> >AND
> >   you do not have that monitor,
> >THEN
> >   everything Dan said makes perfect sense.
> ====================================================================
> Exactly what is it that I stated in my original post that would make you
> conclude that I suggested there was a preference for any particular page size?
> In other words, my statement that comprehension and retention improves
> radically when the on-screen information "looks like a printed book" doesn't
> mean that the on-screen page has the same dimensions as its printed
> counterpart. It's the typography and layout that counts, not the page size.
> PDF is the easiest and most effective way of replicating the typography and
> layout developed in a high-end DTP such as FrameMaker.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> >OTOH, when you take the limitations of your reader and his/her
> >screen and environment into consideration when you design the
> >new layout, HTML may approach the readability of the paper
> >publication.
> ============================================================
> Prove it.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >In industry/business environments with 800x600 screen laptops
> >and paperless environments the typical multicolumn, side-headed
> >A4 PDF (with print resolution graphics) is a scrolling exercise,
> >and a memory/diskspace hog too. Furthermore, when you change a
> >few words in a PDF file, the whole file needs to be replaced,
> >while HTML is normally split in many small files, so you only
> >have to ship a small file.
> ===========================================================
> Now, tell me why PDF files can't be split into many small files.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >Some realworld experience: since 1994 I used FrameViewer to
> >publish our 3000 FM files and 5000 illustrations, arranged in
> >small files per Frame's documentation recommendations (see
> >Chapter 18, Planning online systems).
> ============================================================
> So, when you switched to HTML, you lost all the robustness of FrameMaker
> (popup links, matrix links, message links, better typography and layout, etc.).
> Do you still think you made the right decision? Please explain why you
> didn't stick with FrameViewer.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >Last year I had the choice between PDF and HTML. I chose to
> >create the navigation in PERL, which accesses a plaintext
> >database with all files, and when you click on a link, you
> >get a WWP prepared HTML file.
> ===========================================================
> Old-fashioned. The same thing could be done much better using XML.
> XML provides attributes and the Reference Description Framework (RDF) that
> allow the user to query an XML database for the particular information
> he/she needs, and then have the "hits" delivered, fully formatted, on-the-fly.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >To avoid an output format battle, BOTH formats may produce
> >acceptable results, when designed with the end user in mind.
> >I thought HTML was a bit underexposed in this particular thread,
> >but I use it as well in addition to HTML, when people want to
> >print the documentation remotely.
> ================================================================
> The fact remains that all of us have had extensive experience with reading
> complex information on-line, and every single one of us knows there is an
> enormous drop-off in comprehension and retention compared to reading the
> same information in printed form. It shouldn't be a surprise to anyone that
> this drop-off has been confirmed by many scientific studies.
> 
> Like airplanes, space shuttles, and computers, on-line documentation must be
> designed to survive in a worst-case environment. For on-line documents, this
> is the worst-case combination of screen size, resolution, display quality,
> and font availability on user platforms. So, we're talking a laptop with 800
> x 600 resolution.
> 
> Given this worst-case environment, the "paperless environment" you mention
> above is a pipedream, at least for now. The worst thing that's happened with
> the advent of on-line documentation is that the bean counters jumped in and
> said: "The paperless office is here! If we deliver our documentation
> on-line, we no longer have to deliver those expensive and hard-to-maintain
> printed books."
> 
> Those in the documentation business who let this happen now have to live
> with the knowledge that they didn't stand up to the bean counters when it
> counted, thus they don't like to hear anyone remind them of their
> dereliction by bringing up the dirty little secret that printed books are
> vastly superior.
>      ====================
>      | Nullius in Verba |
>      ====================
> Dan Emory, Dan Emory & Associates
> FrameMaker/FrameMaker+SGML Document Design & Database Publishing
> Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
> 10044 Adams Ave. #208, Huntington Beach, CA 92646
> ---Subscribe to the "Free Framers" list by sending a message to
>    majordomo@omsys.com with "subscribe framers" (no quotes) in the body.
> 
> ** To unsubscribe, send a message to majordomo@omsys.com **
> ** with "unsubscribe framers" (no quotes) in the body.   **

-- 
             _   _        Michael Richards
            ( \ / )       Email:  michaelr@ind.tansu.com.au
           __\ Y /,-')    Tel: +61 2 9206 3524
          (__     .-'     Locked Bag 6581 Sydney 1100
             |   (        Fax: +61 2 9281 1301
             [___]        Intelligent Network Platforms,
             |oo |        Telstra Corporation, Australia
           ,' \  |
          <___/  |
             |   |
             |   |     HAVE YOU SEEN THIS CHICKEN???
             |   |
             |   |
         _,-/_._  \,_
   _.-"^`  //   \    `^"-.,__
   \     ,//     \          /
    `\,-":;       ;  \-.,_/'
         ||       |   ;
         ||       ;   |
         :\      /    ;
           \`----'    /
            `._____.-'
              | | |
            __| | |__
           /    |    \
           `""""`""""`

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