RE: Headers and footers in HTML documents - Or a lesson in banging your head against the wall

Subject: RE: Headers and footers in HTML documents - Or a lesson in banging your head against the wall
From: "Puffer, Paula \(Paula\)" <Paula -dot- Puffer -at- ElPaso -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 24 May 2006 10:57:23 -0500

<<Sympathies. On the plus side, at least you have an interesting problem

to solve and will look like a genius once you solve it... <gdr> >>
Nothing like adding super-genius to the resume ;) That is one thing that
I like about this project. It definitely challenges me and I've been
able to get lost in my work for the first time in a long time.
Essentially, my job is standardizing manual and form formats for 5
pipeline groups that have been acquired by El Paso. And for the forms,
there's the additional requirement of figuring out where we have
redundancies. Then there's the whole web/sharepoint side of things.
There are only three of us full time in the Data Management group for
Pipelines - me and my bosses- and we have an intern who just started.
<<< Blech. The whole purpose of HTML is to allow the layout to be
Where fixed layout is important, that's why you use PDF. Different
solutions for different problems! Trying to make HTML into PDF makes
little or no sense.>>>
Exactly! At this point, I'm not exactly sure what the reasoning is
behind making the HTML and the PDF look the same. I don't think it's a
regulatory thing. My impression is that the whole goal is to make both
documents look the same. They want the manuals to be printed from the
PDF, but they want to make the HTML version look the same. They also
want this process as fairly automated as possible which is why I'm
looking at more robust tools.
<<<If the class IDs are a problem, consider creating a macro of some
to strip them out or replace them with more appropriate tags.>>>
The class ids aren't really a problem. Most often, the problems I see
lie in the original word document and need to be fixed there, which
means being able to regenerate files quickly in some cases.
<<< <<I'd like to see the process be something like make corrections in
Word and generate PDFs and HTML using Framemaker, ePublisher Pro, or
some equivalent program. At this point the PDF is not an issue with
them, it's the HTML. Anyone know of any programs that will convert word
docs exactly as they appear into HTML?>>
The PDF shouldn't be an issue, and you shouldn't need to move to Frame.
(Frame is clearly more powerful, but if the current system uses Word,
stick with what you've got until you have a compelling reason to
change.) Simply purchase a copy of Acrobat, and print to PDF. Problem
solved for PDF.>>>
The PDFs aren't the issue at all and we've already gotten Acrobat for
this project since some of the manuals have Excel files and those don't
work with Click to Convert and I've discovered that Twins File Merger
doesn't always handle landscape vs. portrait layouts well either. I know
that Frame can handle Excel Documents as well.
<<<HTML can't be made to precisely mimic a Word document because HTML
documents are resizeable in browser windows, so it makes no sense to
have documents that don't wrap if users resize the window. Moreover, it
makes no sense to generate a separate HTML file for each page in the
Word document. Sheer nonsense! Each topic should become its own HTML
page, or perhaps a group of linked pages.>>>
Again, I'm not arguing with you on this at all. You are preaching to the
choir :)

<<< <<I'm working on persuading my bosses that really in the HTML
the Header information is not needed because they want any printing
that happens to come from the PDF and not the HTML and that HTML is
about making the information accessible and not the presentation.>>

Headers are easy: they become the title information for each HTML file
(i.e., the name that appears at the top of the browser window when you
open the file). The rest of the header information is meaningless
because there are no page numbers in HTML... or there shouldn't be.>>>
Bingo! At this point, I'm seriously considering some sort of meeting
with my bosses to really discuss the header issues. Click to Convert is
really an anomaly in how it handles document information.
This email and any files transmitted with it from the ElPaso
Corporation are confidential and intended solely for the
use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!.

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: Headers and footers in HTML documents - Or a lesson in banging your head against the wall
Next by Author: RE: TOP THAT: Antique Email
Previous by Thread: RE: Headers and footers in HTML documents - Or a lesson in banging yourhead against the wall
Next by Thread: Re: Headers and footers in HTML documents - Or a lesson in banging your head against the wall

What this post helpful? Share it with friends and colleagues:

Sponsored Ads