Re: Frame won't run file compare

["Thomas Michanek" <thomas.michanek@xxxxxxxxx>]

*** The original message appeared on the FrameUsers mailing list.
*** This reply is copied only to the framers@omsys.com mailing list.
*** If this message is useful, consider sending it to FrameUsers.

From: <Madonna_Baird@raytheon.com>
> On two different machines with Windows 2000, Frame 5.5.6 won't compare
> documents.  The program either announces a fatal error and shuts down, or
> it acts as though it is running a compare and, if left alone, will run for
> hours, doing nothing.

Unfortunately, Compare Documents is one of FrameMaker's more unstable
features. There are known bugs with this operation that makes certain
document impossible to compare and will always lead to a crash.
If you compare very long and complex documents, or if the documents
are very different, the operation may also take a very long time.
In this case, you could try hitting Esc while the hour-glass is showing.

Try comparing two simple documents without graphics, tables, equations
and conditional text, just to make sure the operation works at all.
Then try saving your documents to MIF, re-opening and re-saving them
as binary FM files, and then compare the re-saved files. If that doesn't
work, make copies of a document that crash FM, delete half the contents
and compare again. If it works OK, try with the other half. Continue
like this until you have found what part that causes the crash, and
try to see what "special" contents that may be the trigger.
Finally try to avoid using that type of contents in your files, or
redesign it, or avoid comparing documents with such contents.

Below, I'll quote a description from a former Adobe employee (from 1999).


- - - - - - - - - - - - - - - - - - - - - -
Thomas Michanek, FrameMaker/UNIX/MIF expert
mailto:Thomas.Michanek@telia.com   (Sweden)
http://go.to/framers/
- - - - - - - - - - - - - - - - - - - - - -
Join the low-volume "Free Framers" mailing list: send an email
to majordomo@omsys.com with "subscribe framers" in the body

===========================================================================

Some comments and recommendations for using the Document Comparison feature.

[...] Any problem with a document can cause the
compare code to crash. The code crawls through the data structures of the
two documents, using a variety of interfaces. If anything is wrong in a
document, the compare code can find it, causing a crash or an assert.
The document might work fine in general, with the other code paths
protected enough from the document's irregularities. The compare code is
not as protected in some ways, due to it's direct access to interal
structures, and its slightly different usage of them. Historically, many
document compare bugs were actually problems in other parts of FrameMaker
that the comparison code managed to trigger.

You can try saving as MIF and reopening, since that can clear up mysterious
problems in files. More ideas to try below.

Third, most folks find it works just fine. In other words, try it, it's
easy, and see if it works for you. Takes some effort to learn how to
interpret the results.

[...] The algorithm is recursive,
which can indeed cause a long delay when there are many matches of
identical elements. The biggest culprits here are tables with lots of empty
cells, and lots of empty lines (which cause lots of identical paragraphs).

Lots of identical elements make a comparison algorithm's work load huge.

Large documents can compare very slowly.  They can cause unreasonable
delays, comparing all the paragraphs in one document against all the
paragraphs in the other, and finding the "best path" through the resulting
comparison data. Lots of memory helps. If you are comparing structured
documents (FM+SGML), you need even more memory. Due to internal issues,
structured documents are stripped of structure before comparing. That means
you need memory enough to hold copies of the documents (perhaps both)
being stripped of structure. Then you need memory for the comparison code
to work, which can get really greedy, depending on what is matching what,
and how many elements there are (mosty paragraphs). Upping your memory can
really help comparing.

Low memory conditions are one of the most difficult issues to deal with
programmatically. FrameMaker does pretty well in general in low memory
situations, but it might decide to assert (put up the Assert Alert, and
exit immediately with MIF saving) instead of continue.

Document elements that most confuse the comparison code:
Tables (especially with lots of empty or identical cell contents. That is,
sparse data)
Text Insets
Lots of empty paragraphs
Lots of identical data
Huge documents (mostly a memory and time issue)

The "lots of empty paragraphs" item happens when importing big lists, like
address lists. There is often an empty line separating each item. Each of
these lines looks the same, so the algorithm has to consider all the
options of what is and is not a match. Makes the workload much bigger, and
the opportunity to choose wrong greater. With every fourth line or so
matching perfectly, the code gets overburdened.

If you are having trouble comparing tables, you can:
1. select the table(s)
2. convert to text
3. compare
4. don't save the convert to text changes to the originals (be careful
here, since you will have a bunch of files open, with the Summary and
Composite, and the Composite looking a lot like your originals).

In other words, compare the tables as text, not as tables. A pain, but
might be a viable work around for you. You could also use a third party
text compare utility. Other comparison utilities have settings with various
thresholds that can give better results.

Comparison algorithms can only do so much for you. What often looks to be
an easy comparison can be extremely complicated in practice. Interpreting
the results is often harder than anticipated, regardless of the tools used.
Ask any programmer using source code control. The "compare and merge" step
of checking in new code is always a pain and difficult. The comparison and
merge tools can only do so much, and sometimes make bad decisions on your
behalf. Just saying that revision comparison is often dificult and more
manual than desired.

Finally, if you have text insets that span paragraphs, this can confuse the
code.


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