fields -- ASSERT(headers and footers are a special case)

Subject: fields -- ASSERT(headers and footers are a special case)
From: Paul Rohr (
Date: Tue Sep 26 2000 - 21:19:53 CDT

The temptation to avoid doing too much with change records stems from the
idea that field values fluctuate "too much", and that the burden of keeping
around all that undo information is too high.

However, as mentioned previously, a little reverse engineering shows that:

  - most fields in a document don't update that often,
  - when they do, those updates are undoable, and
  - a bunch of updates often get batched into a single undo step.

(When I'm talking about frequency, remember that I'm comparing this to
"normal" editing via typing and formatting -- each of which goes through the
undo mechanism.)

It's not hard to see how this works in the main body of the document:

However, it's worth pointing out that headers and footers are a special case
-- especially when it comes to page numbers. These special sections of a
document repeat on numerous pages, essentially repeating copies of the same
content on each appropriate page.

This makes fields in headers and footers seem more volatile, but it's not as
big a problem as it appears, for the following reasons:

1. Any edit applies to all pages
Again, go play with the competition. By design, it usually doesn't matter
which page you edit a header on -- all similar pages in that section should
look the same. (Where similar can get complicated via concepts like "first
page special" or "even/odd pages").

Bottom line -- the piece table is only going to store one copy of the
content for a particular header or footer. Any per-page variations (such as
the page number) will need to happen in the view.

2. Destructive edits get tromped at print time anyhow
Yes, if we allow arbitrary editing of field contents, the user can mangle
the page number on all pages simultaneously, but as soon as they try to
print, we'll automatically update the contents of that field.


This archive was generated by hypermail 2b25 : Tue Sep 26 2000 - 21:30:52 CDT