Word of Law No. 34 – Collaboration on Collaboration 5 – Comparison with CompareRite

[Originally appeared 2000.]

We continue the series on collaboration, written by Bob Blacksberg in collaboration with Sherry Kappel of Microsystems. In Word of Law No. 33, we looked at the capabilities and shortfalls of the document tracking and comparison functions of Word 97 and 2000. The limits of these built-in functions to meet the demands of precise and complete document comparison required for legal practice, together with the unintended evidence of the drafting process that can remain in an electronic version of a document after track changes has been used, left Microsoft advising law firms to look to third party solutions for document comparison.

As usual, we trust that the focus here on the needs of legal practice informs the users of Microsoft Word in other organizations, especially when documents need to be written and edited with the care and precision used for drafting legal documents.

This week’s column considers CompareRite, the historical leader among third party comparison tools. For several years, this product has been owned by Lexis Nexis Group.

CompareRite works outside of the Word application, reading the original and revised files, then creating a third document, reporting the changes found between the two. Similar to the Compare Documents function built in to Word, the resulting report is an editable document. Where Word’s Compare Documents function applies Word 97 and Word 2000’s track changes feature to mark changes, the results of CompareRite document uses character insertions (“[” or “]”, for example) and character attributes – strike-through, bolding, double underlines – to denote inserted, deleted or moved text.

CompareRite supports a greater variety of methods of reporting the comparison than the built-in function in Word, such as changing the boundary characters and formats for inserted characters, using placeholders instead of strikeout text for deletions and applying special markings for moved text (instead of Word’s pattern of showing the text deleted in its original location and inserted in its new). The selection of options can be stored by users.

Of the collaboration functions relating to document comparison described in issue 35, CompareRite supports only Comparison, not Tracking or Incorporation. That is, it can only produce the document reporting changes, but not create a record within the document of who made the changes and when, as the Track Changes feature does in Word, or automate the process of incorporating changes into a revised document, as the Accept or Reject Changes feature does in Word.

This limitation of CompareRite has its benefits, since it assures the integrity of the original and revised documents, including protecting the clean revised document from the evidence of the drafting process that can be left behind when Track Changes are used.

One cannot speak about CompareRite without realizing first that law firms have long integrated use of the tool into their daily work, bringing one legal secretary to conclude that her “attorneys have forgotten how to practice law without it!” In fact, when the product was paired in its early years with WordPerfect 5.1, the two applications worked almost in harmony, creating a level ofstability and performance difficult to match in with any other word processing application.

It is not nostalgia which made CompareRite the legal industry’s de facto choice, but rather its “pinpoint” comparison algorithms. Historically, comparison products have underachieved when – dare we say it? – compared to CompareRite’s routines for precisely detecting complex moves and changes. It is, in fact, this precision and accuracy which continues to justify that an organization ferret out solutions and workarounds to CompareRite’s common fits and starts – a situation which exists whether it is comparing two Word documents or (even) two WordPerfect documents.

This situation has evolved over the course of the last decade, as CompareRite continued to revise its proprietary binary file converters to meet each new word processing application’s enhancements and binary file format revisions. This legacy has challenged the application, reaching a critical stage with the release of Word 97:

Prior to that release of Word 97, CompareRite rendered the comparison of Word 6/95 documents by reading the applications’ binary file format, and writing a binary Word result. With the release of Word 97, however, when the significantly revised binary file format specification was not made available for nearly a year from Microsoft, Lexis was forced to take an alternative plan of action. Microsoft provided the vendor with an RTF file converter which would run stand-alone – without invoking Microsoft Word itself.

It turns out this filter was several revisions behind the released converter internal to Word. If you have not completely suppressed these events from memory, the RTF converter which was internal to Microsoft Word suffered more than its share of flux during that period of time. Because of these issues, as well as CompareRite’s inability to compare the content of tables, CompareRite and Word 97 had much difficulty operating together.

These difficulties have promoted, however painfully, an awareness of the importance of common formatting practices and consistent and intelligent procedures for conversion of documents from WordPerfect to Word. This, coupled with the recent release of CompareRite’s Version 7, Patch 9A, have eased the burden’s of the use of CompareRite to some degree. Patch 9a, whose design and stability benefits are only experienced fully, however, using Word 2000, can run Word to generate its RTF files, improving its accuracy and stability.

Still there are common issues which compromise the success of using CompareRite with Microsoft Word. These include:

  • Non-uniform tables. CompareRite doesn’t handle tables at all. If they must be compared, turning troublesome tables into text makes the most sense in many of these situations.
  • Poor or corrupt field code construction (e.g., unpaired field codes, or improperly delimited field code text).
  • Inconsistent formatting between the original and revised documents, primarily in the realm of numbering.
  • Corrupt or poorly converted documents.

It is hard to write about using CompareRite without restating the need for good version control practices. That, however, merits its own column. In the next column, we will continue the story with the document comparison capabilities of Adobe Acrobat and WorkShare’s DeltaView.

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.