RE: Imported Graphics (was copied graphics become grey boxes)- Reply

[Paul Schulte <paul.k.schulte@xxxxxxxxxxxxx>]

Lots of snippage:

>Some of these documents we produce in FrameMaker at Medtronic are FDA
>regulated (as well as the European/Canadian/Australian/Japanese
>equivalents). They are under engineering control, which is a further
>regulated process. At any time (the US law uses a phrase, "...in
>perpetuity..."), the archives of these documents must be re-produced
either
>electronically or via microform.
************************************************************
Why not archive as PDF? That meets the legal requirement
*******************************************************************

We do. I led that war and won it years ago.

More snippage:

It's difficult for me to see how importing graphics by copy helps to meet
the
configuration management requirements you describe. In fact, that approach
confounds proper configuration control.

In the type of environment you describe, all graphics, whatever their
source
(including graphics created with Frame's drawing tools), should be subject
to individual configuration management and version control. If you import
graphics by copy, you lose the graphic's configuration audit trail,
because,
once it's copied into the Frame document, it loses its separate identity.
When you import graphics by reference, FrameMaker provides you with the
name
and location of the imported graphic file, allowing you to verify its
provenance.

A proper configuration management system would assure that the
subdirector(ies) containing the graphics for a particular document set
always contain the applicable versions of those graphics. In this way, you
are assured that, when you open any Frame document in which the graphics
are
imported by reference, it will always contain the correct versions of all
graphics.

And besides all that, what happens when an imported-by-copy graphic gets
inadvertently deleted (or turns into a gray box)? You must go back to some
archived version of the same Frame document (which also has its graphics
imported by copy) to recover the deleted graphic. But since neither the old
graphic nor the deleted graphic has a configuration audit trail, how can
you
ever be certain the old graphic is the same as the one that got deleted? 

end snippage

I too am a supporter of SGML. However, I doubt I can win this war.

At the moment, the audit trail we need is to the entire revision of the
document, not its individual components. If we change one component, we rev
the entire document.

Does that help explain why SGML and "proper configuration management" are
not used? Our current configuration management practices satisfy our
regulatory requirements.

This method of working has served me well for the entire time I've been a
Unix user of FrameMaker. (Over five years.) My rework percentage has been
infinitesimally small for this issue. I can't even remember the last time
I've had to fix a document for it.

And if we are so wrong, how come our results have so favorable and stable
for such a long time period? (This workflow also parallels the way our
thousands of users use Microsoft Word and WordPerfect.)

I do recognize the superiority of the other approach. I just argue that
when something works, it doesn't need to be a major priority. (Yes, I too
would like to see Adobe fix this one. That list of fixes is endless.)

Paul

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