Re: PDF vs HTML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 11:04 AM 3/17/00 -0800, Thomas Neuburger wrote:
>Fascinating, Dan. Just some follow-up questions:
>
>You say, "a further secondary reduction in comprehension
>(figures range from 5% to a whopping 40% depending on the study)
>occurs when the text is formatted in the flush-left, single-space-
>between-paragraphs (with generic fonts and font sizes) style
>that is almost unavoidable in HTML- and WinHelp-type documents".
>
>And also, "The secondary comprehension reduction, and a small
>portion of the primary reduction, disappear when the text is
>formatted according to the conventional rules of typography
>for printed material...".
>
>I'm interested in what specifically causes the reduction -- Is it
>flush-left-ness (i.e., the remedy is centered alignment, or right
>alignment), lack of spacing between paragraphs, lack of consistent
>page size, lack of headers and footers, and so on?
=========================================================
You may be able to get more information about the studies that verified the
reading and comprehension problems of HTML, winhelp, et al, as compared to
PDF derived from well-designed FrameMaker files intended for printed book
production
by contacting Josh Norton at the email address below

Josh Norton <browe@one.net
+++++++++++++++++++++++++++++++++++++++++++++++++++++
You asked what specifically causes the secondary reduction. Certainly the
range of the secondary reduction (5% to 40%) that I cited above probably
came from testing HTML documents with a wide range of horror quotients.
Certainly, the use of a sidehead column containing thesis sentences and
other cues, with amplifying text in the normal text column has been shown
over and over again to provide optimum readability. The sidehead column
serves as a scannning column, allowing the user to rapidly locate the
particular information he/she is seeking. Running header/footers provide
additional cues. That kind of layout is difficult, if not impossible to
achieve in HTML.

Then of course there's the whole issue of selecting a font that is easy to
read on-screen. By embedding fonts in the PDF, the chosen font is never
replaced with some default font, as is the case with HTML or winhelp if the
font is unavailable on the user's platform.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>In other words, given a world in which HTML could be "corrected",
>what would those corrections be, specifically? Do your sources
>provide this information as well?
================================================================
Doubtful that it does. Why go through all that "correction" hassle with HTML
when PDF seamlessly replicates the orignal document's formatting with no
hassle at all. Remember that HTML is a highly limited subset of SGML. Even
in a full SGML implementation, achieving printed-book-quality formatting
from raw SGML is a super hassle that typically requires an engine such as
FrameMaker+SGML (far too costly for use as a browser) or XyVision (a
6-figure formatting engine).

     ====================
     | 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.   **