Not disagreeing, Richard, but I suffered through months of this on a
contract job where the files were shared among several writers. And it's
recurred occasionally in other 7.x environments. Ain't saying it couldn't
have been resolved, but it occurred far too often to be hapinstance.
Cheers,
Art
Art Campbell
art.campbell at gmail.com
"... In my opinion, there's nothing in this world beats a '52 Vincent and a
redheaded girl." -- Richard Thompson
No disclaimers apply.
DoD 358
On Tue, Jun 15, 2010 at 4:07 PM, Combs, Richard
<richard.combs at polycom.com>wrote:
> Art Campbell wrote:
>
> > The last FM 7.x projects I worked on were perennially losing cross-refs,
> > just in day-to-day book building operations.
> >
> > Not to mention changes in chapters themselves.
> >
> > If it could be truly automated, maybe... but sitting down to a list of
> > hundreds of unresolved cross-refs isn't a great way to start your day.
>
> Barring operator error, FM xrefs are pretty nearly bullet-proof.
>
> I'm not sure what you mean by "day-to-day book building operations," but
> there are basically only two ways that an FM xref becomes unresolved:
>
> 1) FM can't open the destination file (because it's been moved, deleted,
> renamed, or can't be opened silently due to missing fonts, etc.) to find the
> marker that the xref points to.
>
> 2) FM can't find the marker itself (because it's been deleted, the marker
> text that identifies it was changed, or it's tagged with a condition that's
> currently hidden).
>
> If one of these things was happening routinely to hundreds of xrefs, there
> was something seriously wrong with the process/workflow being used, probably
> because the person who created it didn't understand how FM xrefs work.
>
>
> Richard G. Combs
> Senior Technical Writer
> Polycom, Inc.
> richardDOTcombs AT polycomDOTcom
> 303-223-5111
> ------
> rgcombs AT gmailDOTcom
> 303-903-6372
> ------
>
>
>
>
>
>
>
