Hi Nathan:
You're on the right track
1) Prepare the header information. This can be either a document or a
graphic.
2) In your templates, place the header information into the header, as
"Link to File" and leave "Save with document" enabled.
Now, whenever a document created from those templates is opened, Word will
check the file date on the header source file. If it's more recent than the
copy in the document, Word will update the document.
It sounds so simple
Regrettably, it isn't. There's a raft of
considerations.
The first is "What kind of header file." If you CAN construct your header
as a Word document using Word's (or PowerPoint's) drawing tools, do that.
You will save yourself so much trial and error... However, DON'T put
anything in the HEADER of the source document. You can't nest a header
within a header in the resulting documents
If you can't do it in Word, here are some thoughts:
On Windows, it's simple, because Word's graphics import is very solid. On
Windows, you use EMF format for the header: end of problem. When that
document goes to a Mac, Mac Word will internally convert the file to PICT
and it will simply "work".
On the Mac, EMF is not available. If you produce it and try to use it, for
some reason the result is a fuzzy bitmap. PICT works well on the Mac, but
can have issues on Windows (the Windows system administrator needs to ensure
that they have the correct filters installed, which means installing
QuickTime, which many don't). EPS works well if you have an all-PostScript
printer environment, but the documents can look bad on screen and won't
print at all on non-PostScript printers (most non-laser colour printers
these days have very poor PostScript abilities).
High-res bitmaps work very well and are safe across platform. But the
resolution needs to be at least 600 dpi to make text print well, and this
can result in a giant file size overhead: remember your header graphic can
be replicated multiple times throughout a document. PNG is the format of
choice: it is fairly tightly compressed, but it holds its resolution and can
handle 24-bit (RGB) colour. JPEG is not good for text, because it
sacrifices resolution to preserve subtle colour and shading, and unless
you're careful, it can contain 32-bit or 48-bit colour that Office
Applications won't print. GIF is not a good choice: it holds its resolution
but is limited to 256 colours, which makes shading look awful.
You need to prepare the header using a professional graphics application.
If you do, make sure you set up for RGB colour, and test your result
carefully in both Mac and Windows Word. Be careful of the "bounding box",
when you export make sure you remove that or your graphic will be a coloured
postage stamp swimming in a sea of white.
Now, here's the sad bit. The source graphics file needs to be installed on
a network server that everyone can see and will remain connected to. If you
rely on users to reconnect to the server your graphics will never update,
because they simply won't do it
Way back beyond the dawn of time (15 years ago...) doing documentation on
computers was difficult and technically complex. Everyone knew that, and
users who could do it had a high level of knowledge of the inner workings of
the mechanism. You could do things such as external graphics, linked
pictures, vector illustration and floating graphics. Every user would
immediately recognise these artefacts in a document, and either know what to
do with them, or ask someone who did.
Now we have had 15 years of "Making things easy", "It just works", and
"Where do you want to go today." As a 55-year-old industry veteran, I sit
surrounded by managers and staff half my age that are stupendously,
abysmally ignorant of what goes on in their documents. They don't know,
they don't have time to look, and they could care less...
In the average corporate workplace, what we have been discussing above is
simply impracticable. To be reliable, it requires users to observe some
very simple rules for document management. They're not going to do it. So
rolling out such a solution in the corporation is simply counter-productive.
In six weeks, you will be in document corruption hell. In 12 weeks, you
will be unemployed
The real answer to this is Microsoft Office 12 (it will be Office 2007 on
the PC, we don't know what they're going to call the Mac version). But we
do know that there IS going to be one
Obviously, we're under some tight non-disclosure agreements that mean we
can't tell you any more than Microsoft has released publicly about it.
However, Microsoft has released half a library full of information -- just
reading it would be a full time task. So let me summarise it a bit...
1) The internal file structure of all Office documents will be Zipped
(compressed) XML.
2) Documents will be "assembled" from predefined 'components'.
The implications of this are vast. XML is simply HTML on steroids. Another
way of saying that is "XML is what SGML 'should' have been."
Simplistically, internally a document is simply a website. That means that
the internal file format "expects" components to be all over the network, or
all over the world. So what we're asking for here: a dynamic address block,
is simply the way the thing is designed to work. Better: we get
"inheritance": move a document to a different workgroup or division and the
headers can update to the local information, if you set them up that way; or
not, if you prevent it.
XML is both "human readable" and "machine readable". This has vast
implications as well. The machine (e.g. Word...) can validate the internal
code in the document. If it's not right, it can either fix it, or force the
user to do so (and tell them how...). Better: For those such as you and I,
if we don't like what we see in a document, we can simply open the thing up
in TextEdit and change it. With a certain amount of stress and bad
language, granted. But with just TextEdit you and I can change not only the
way a document works, we can change the way Word itself works.
This will lead to massive changes across the industry. Expect a slow
start-up: there's a fairly steep learning curve involved here. Corporations
are not going to go rushing into this. But over the next five years or so,
ALL of our current technical problems with Word documents will go away.
Stuff will "just work". Users will rapidly and easily achieve what they
were trying to do. And the information will be machine-accessible in a
safe, robust, open-standard format.
Yeah, OK, our next problems are going to be in the "Policy" and "Process"
arena
Users will easily be able to create really lurid
ransom-note-style documents. I expect to achieve very High Entertainment
Value from the "creative discussions" that will break out across the average
corporation before the staff eventually learn that "just because you "can",
does not mean you "should"".
The big benefits are that whatever they do, the data is safe. It's hard to
break and easy to repair. Whatever they do, we can get the data back.
They don't make numbers big enough to describe the accrued value of
information in corporations across the world. Civilisation as we know it
would not survive if we lost it all. And there isn't enough real-estate
above water to store it all if it were printed on paper. And if it were
printed on paper, we couldn't use find what we wanted: it would effectively
be lost.
Now, we have a solution. I'm quite excited
Cheers
My company has updated its logo and changed some contact information in the
past few years. A lot of our documents reflect the old logo and old
information. Currently, we're updating each document manually.
Moving forward, is there a way to have new documents refer to a template
that updates whenever we change the template? I've tried Insert -> File... as
a link as well as Insert -> Object... link to file. Neither did what I was
hoping they'd do.
--
Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.
John McGhie <
[email protected]>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410
