Subject: AutoNum and Fields (was Re: Lists)
From: Paul Rohr (paul@abisource.com)
Date: Wed Jan 19 2000 - 13:17:16 CST
OK folks,
I'd like to pull together a few different people's expertise here to see if
we can figure out a coherent way to get list and header numbering specified
properly.
I woke up this morning with the insight that the recent discussion Justin
and I have been having about Fields being containers may also address Luke's
questions below about lists.
However, I don't know enough about how RTF and Word store lists to be sure.
If my guess is right, we may be very close. If not, oh well. It was worth
a shot. Here goes.
At 08:47 PM 12/15/99 +0200, Luke Jordan wrote:
>1. The actual insertion of the list item label into the document. Is there a
>way I can insert text so it a) isn't written to the document on save and
b) is
>flagged as non-user-editable?
As soon as we get fields switched over to be containers, then this may be
exactly what you need. According to the latest proposed design, any field
will have two components:
arguments field type, plus other info used to calculate contents
contents latest version of the actual text to be displayed
The design model is that field contents:
- get calculated once at insertion time,
- may not be editable, and
- may optionally get recalculated later on (depending on the field type).
In other words, any paragraph which is a list item could conceivably begin
with a field which corresponded to the list item label. (I haven't thought
through the implications for cursor motion and doc positions, though.)
In your case, if you wanted all list item fields to be recalculated every
time the document gets loaded (and I'm not sure you really do), then this
still fits the proposed design.
Note that this is just a suggestion which might be worth investigating,
especially if it corresponds at all to how the Word and RTF file formats
handle the problem. Among other things, it's certainly quite different from
the approach Jeff mentioned. I haven't really thought through the merits of
either one, besides the fact that this just feels simpler to me.
>I can see that the document text is stored in
>the piece table's pt_VarSet, but why does that have two buffers?
This cool feature of Jeff's design is actually unrelated to the issue at
hand. IIRC, one buffer contains the original document contents as loaded
from disk (which is thus immutable), and the second buffer contains all
changes made via editing during the current session (which is used for
infinite undo).
Among other things, this means that later on we can do more work underneath
these APIs to page the contents of the static pt_VarSet from disk if needed
in low-memory situations.
As I said, unrelated but very cool. :-)
>2. Nested lists. Beyond the UI issues, there are some large structural
>difficulties - e.g., if we have this list (alpha characters mine):
>a) 1.1
>b) 1.2.1
>c) 1.2.1.1
>d) 1.2.1.2.1.1
>e) 2.
>What is the previous item of e), is it a), d) or a virtual list item -
"1." and
>beyond that, what is the value of d), is it "1.2.1.2.1.1", just "1." or
"1.1"?
[ I know I'm pretty much preaching to the choir here, but it's been a long
time since I've had an opportunity to do my reverse-engineering-is-good
rant. Thanks for humoring me. ]
I haven't spent enough time reverse engineering here to specify what our
behavior should be. However, two big cues would be:
- how much information gets stored in the RTF and Word formats
- how Word actually behaves when you mess with it
Like any reverse engineering job, the hardest task is to:
- think about perverse situations,
- throw them at the existing implementation, and
- see what it does.
Working in a vacuum, we could probably come up with plausible solutions to
each such "screw case" and convince ourselves that they were good answers.
Yet without a bunch of user testing, there's no way to be sure that our
original guesses were right.
The end goal here is to produce a product that Just Works the way our target
user (the oft-mentioned church secretary) expects. Since those expectations
have already been heavily conditioned by other existing word processors, we
need to thoroughly understand how they work.
We need that level of understanding to be sure that any differences we
choose to introduce in our implementation are really improvements, and not
just gratuitously annoying.
>How do we track its position in each successive level, so finding the
>"1.2.1.2.1.1" to prefix before the "1." - an obvious solution would be a
linked
>list of values, but this seems overkill.
I'm pretty sure that most word processor style systems maintain an
orthogonal property (we'd probably call it heading-level) which would be a
*huge* cue here.
In fact, I think Word actually maintains a few parallel hierarchies of such
levels, but I don't know when or how this is useful.
>With a solution to prob. 1, I should have flat lists Just Working very
quickly,
>but as you can see, 2 will take probably take some time.
Cool! If this approach sounds workable to the RTF and Word experts, I think
we're well on our way.
Thanks,
Paul
This archive was generated by hypermail 2b25 : Wed Jan 19 2000 - 13:11:56 CST