TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
[...]
> more pages in length. Many who have responded on this thread seem to
> believe some sort of clear distinction can be made between
> what "should" only be printed and what "should" only be read on-line. That
> defies common sense.
> Who decides what should or shouldn't be printed, the website designer
> or the reader? The reader, of course. Now, a website where
That's a good point -- a user will always have the option of choosing to
print any part of the website, so you can't say "Oh, they won't print out
this bit" -- hence all of the problems where bits of text fall off the edge
of the printed page because no-one thought to test the printability. This is
not the fault of HTML, _per se_, but of the use of frames, etc., to control
the layout.
My take is that it is not a case of when *printing* is important, but when
*layout* is important that PDF comes into its own -- a point you also make.
> Sean MacRae's response to my post is typical of many:
I'm glad *someone* agrees with me...
[...]
> +++++++++++++++++++++++++++++++++++++++
> >HTML was not intended to provide control over the format.
[...]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
> This attitude above which argues that form is not important
[...]
> Of course, content is more important than form, but format
> and layout are still important, and HTML makes it difficult, as he points
out, to
> achieve a design that has superior readability.
[...]
> PDF, on the other hand, produces an
> exact replica of a well-designed on-line document originated
> in a high-end DTP.
Only if the original was, indeed, well designed. I don't argue that form is
not important, just stated the fact that HTML originally left much of layout
and typography to the browser -- and recognised that many of the original
Web browsers, such as Lynx, were character-display based, text-only browsers
with zero control over layout. Whether that is better than PDF depends
entirely on the requirements of you and your readers.
Good layout and typography are essential, and involve far more craft than
most people understand. I think most Tech-Whirlers would agree with this
(but feel free to argue for bad typography and design, if you will).
This is related to another discussion in here on single-sourcing; the HTML
philosophy (inherited, albeit poorly, from SGML) of tag the context and
leave the format to a separate renderer supports this. Simple HTMl tagging
allows the same text to be viewed in a browser, or listened to by a visually
impaired user (including navigation).
You trade control (over layout) over flexibility. You may regain some
control by using style sheets, but figure layout usually suffers.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >PDF was not designed for online use. It provided an
[...]
> Clearly the person who made the statement above has no
> knowledge of the history of PDF. From its inception, PDF and Acrobat were
designed for on-line
> delivery and viewing.
It was I, and I prefer to say I have *some* knowledge of its history.
My contention was that early Acrobat was aimed at on-screen viewing, but not
Web-based viewing (which is what I now assume on-line to be; maybe we have a
terminology issue, here).
> As Acrobat has evolved, more and more on-line viewing features (e.g.,
continuous
> scrolling options, zooming in on a selected portion of a page, digital
> signatures, on-line form fill-out and submittal, embedded fonts, big-time
> security and copyright protection features, hypertexted thumbnails and
bookmarks, structured
> documents).
As you say, as Acrobat has evolved to add some of these features. I was
talking about its origins.
In particular, Acrobat was not a structured format in the early days; it was
purely a visual format. With HTML, you knew when something is a first-level
heading because it told you by tagging it -- <H1></H1>. In early Acrobat,
you just knew something was big and bold with a lot of space, and you worked
out the context yourself.
If you're only gonna read something, visual may be better. If you're gonna
reuse it, or allow the user to reformat it, the tagging may be better.
Neither is superior, both have strengths. This was my original point. And
anyway, Adobe have added more structure to their format, but as I have not
used this, I am not qualified to comment.
> What is the difference between designing an on-line document
> in a high-end DTP (e.g., FrameMaker) and outputting it to PDF vs
outputting it to HTML
Ah. If you are designing specifically to view on-screen, you will avoid the
problems associated with viewing a page format on-screen, raised elsewhere
in the 'list. Your printed pages may have odd-looking aspect ratios. I think
the other issues of breaking Web navigation and impacting usability have
been done to death elsewhere.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
