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.
Subject:Re: Re : HTML as document source From:Shmuel Ben-Artzi <sba -at- NETMEDIA -dot- NET -dot- IL> Date:Tue, 23 Jul 1996 20:12:42 +0200
The following observations reflect only my own experience which, though the
product of considerable on-line and book-based study, is not yet as
extensive as I hope it to become.
>1/ My observation, as a neophyte, is that many Web pages give
>very nice results when printed.
>2/ Not being an HTML expert, I'd like to know if there are not many
>unused (or seldom used) HTML functionalities that could help give
>a "satisfactory" paper rendition (I'm thinking of tags that do not
>affect screen display but only paper printing).
Yes, some web pages do look good when printed (on a laser or a good-quality
color jet). The problem, though, as you noted in item 2, arises when the
"page" on the screen runs more than one paper page. As yet, I know of no
HTML tags that will affect paper printing only. If there were, then there
would have to be ways to handle all of the contingencies that would arise
from the various printer configurations, drivers, page definition languages,
etc. I don't expect this to be included in the HTML standard in the near future.
So if you try to use the on-line version as a platform for a printed
version, you're stuck with uncertain page breaks, to cite just one major
problem. Printout of the links (frivolous in a paper document) is another,
as is the handling of various multimedia objects. To compromise the on-line
version just to guarantee a better printed version would be totally
One partial compromise might lay in the use of "digital paper" on-line
documents. In *some* applications, these work very nicely using, for
instance, Adobe Acrobat.
>3/ Are there HTML editors that enable *simultaneous* monitoring
>of an HTML document on the Web and on paper ?
Some editors, like the latest versions of Hotdog (which I use) allow you to
view what your code will look like on screen as you're writing it. As to a
simultaneous view of what a printed page will look like, no, I know of none
that will do this.
>4/ As regards the "information process", my conviction is that
>online information should now be considered as the unique
>reference information, the hardcopy being just a side-product.
>We all know the drawbacks of paper, which freezes the information
>in an ever-changing world. Then, if some users want a hardcopy,
>let them get it, but let them know as well that it becomes
>"suspect" as soon as it's printed.
I agree in principle, but I would add one qualifier. I believe that this
will become *almost totally* true within the next five years. Right now? I'm
not sure. There are still a lot of compatibility and standards battles to be
fought. We're gaining ground daily, but we've still got some distance to go.
Also, the Internet, despite its exponential growth, is not yet the
ubiquitous entity that it should soon become. Paper still has its place.
Data Sytems Manager, Ulpan Akiva
sba -at- netmedia -dot- net -dot- il
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-