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.
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
flexible.
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
sort
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
documents
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.
Paula
******************************************************************
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
sender.
******************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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!. http://www.webworks.com/techwr-l
