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: http://www.abisource.com/mailinglists/abiword-dev/00/September/0310.html 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. Paul
