Re: PDF vs HTML

[Cas Tuyn <Cas.Tuyn@xxxxxxx>]

Dan,

> 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?
....
> PDF is the easiest and most effective way of replicating the typography and
> layout developed in a high-end DTP such as FrameMaker. 

If you say "easiest way of replicating the layout" I can only assume
that you distilled the PS file, and thus try to view the high-end
DTP on a low-end device such as a monitor.

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

I can't, as I do not have the resources not time to test it. I can
tell you the measures I take to improve the readability:
 - window size that does not require scrolling,
 - font size that does not require zooming,
 - appropriate use of colors (to indicate links).
These three points require preprocessing in FM, or postprocessing
in Exchange to accomplish.

> Now, tell me why PDF files can't be split into many small files.

Again through postprocessing in Exchange? Or do you mean by distilling
all the files that make up the book, breaking all the links? It IS 
possible but not desirable (mostly).

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

My original system used FrameReader, which was for free. When they
killed that, I had to pay many FrameViewer licenses, reason nr. 1.
The memory footprint of the FM/PDF/HTML files was reason nr. 2. The
future of FrameViewer (see what happened to FrameRetrieval tools)
was reason nr. 3. The fact that all links and menu's were hand-made
(just like you do with Exchange) was reason nr. 4. The fact that you
cannot do conditional text/files to accomplish configuration dependency
was reason nr. 5 (My perl script queries the database with the user's
configuration, and then generates the TOC for the manual that suits
their configuration ... like a glove).

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

I used FV for 5 years, and plan to use HTML 4 with PERL for another 
4 years, and then swith to XML, AFTER it has stabilized, and is 
widely supported. Old-fashioned is proven track record to me!

> 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."

I don't want to agree or disagree. My users tell me they like the 
online stuff over the paper manuals, and I work for them.

Simple.

Cas

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