[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "'Cas Tuyn'" <Cas.Tuyn@xxxxxxx>, SMoore@xxxxxxx, FrameSGML@xxxxxxxxxxx, framers@xxxxxxxxx, danemory@xxxxxxxxxxxx
Subject: RE: PDF vs HTML
From: Mike Tatro <tatro@xxxxxxx>
Date: Wed, 22 Mar 2000 08:13:24 -0800
Sender: owner-framers@xxxxxxxxx
Careful Cas. Those sorts of opinions don't seem very welcome here. I chose not to respond to Dan's post because what *can* one really say to someone who posits a "<fill_in_the_blank> uber alles" argument (i.e., paper manuals are ALWAYS superior to online help). I continue to be a part of the list because hardcopy manuals produced with FM are a fact of life for me. I'd be hard-pressed to think of a more knowledgeable group of folks on that particular topic. Dan is obviously one of the most knowledgeable guys I've ever encountered and I respect his opinions for what they are - his opinions. God knows, I have plenty of my own. What I do think some folks miss about HTML is that the behavior Dan most criticizes is actually a feature. The fact that each person can potentially define a different default screen font is a feature, not a limitation. The underlying philosophy is that I (the user) know better what my default screen font should be than some author in an ivory tower. What about those nearly blind (who may need a large font) or running very small displays (who may need a small font)? Should they be tied to someone else's idea of the "best" screen font? HTML also scales in many other ways (e.g., tables automatically size to the display, text auto flows around graphics), all of which are intended to display differently on different systems. However, to leverage this behavior, one *must* consider those things when authoring. Of course embracing this new paradigm means yielding absolute control over the page layout in order to *better* serve one's readers. Many "old school" writer/publishers are loathe to do this. Hence, the bad feelings about HTML in general and the specific criticism that it never looks the way they intended it to. I do agree with Dan wholeheartedly that "shovelware" is the last refuge of a hack. Warmest Regards, Michael L. Tatro Documentation Manager V-Systems, Inc. tatro@vsi.com > -----Original Message----- > From: Cas Tuyn [mailto:Cas.Tuyn@asml.nl] > Sent: Wednesday, March 22, 2000 1:53 AM > To: SMoore@iti.com; FrameSGML@onelist.com; framers@omsys.com; > danemory@primenet.com > Subject: Re: PDF vs HTML > > > Hi, > > 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. > > 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. > > 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. > > 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). > 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. > > 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. > > > Kind regards, > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Cas Tuyn cas.tuyn@asml.nl > Publications department tel: > (+31) 40 2303723 > ASM Lithography fax: > (+31) 40 2303883 > De Run 1110 mail: P.O. Box 324 > 5503 LA Veldhoven 5500 AH Veldhoven > The Netherlands The Netherlands > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > > > > > ** To unsubscribe, send a message to majordomo@omsys.com ** > ** with "unsubscribe framers" (no quotes) in the body. ** > ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **