At 03:33 PM 3/12/00 +0000, Keith Stribley wrote:
>I've started work on implementing
>fields by getting an pf_Frag_Object to create fp_Frag_Text objects to
>represent the text which then converts to fp_TextRuns, fp_TabRuns etc. The
>advantage of this is that all the text formatting stuff is handled already
>by the text runs without having to rewrite it specifically for fields. It
>just requires a modification to allow runs to be linked to fields and to
>stop the user modifiying them and colour them grey in this case. As the more
>fields get implemented the ability to insert Tabs etc as part of the
>formatting would be very usefull, eg. for Lists. Table Of Contents will have
>to use the full range of runs to represent their contents.
Very nice. The last time I hunted down Jeff to rough out an idea of how to
shoehorn fields into the piece table, this is essentially what we were
thinking too. The fact that you've independently come to the same
conclusion is a real confidence-booster.
>In this scenario fp_FieldRuns would disappear (or maybe just be used for
>displaying the arguments to fields when chosen by the user).
Yep. Of course, I'm not sure whether displaying field arguments inline like
this is a useful UI feature (or just a persistent bug), but I'm willing to
be convinced.
Still, it'll be nice to have the ability to do this somehow if we want. So
long as the arguments are read-only, then the fieldrun solution would
suffice. However, if we want to make them editable (which I think Word
does), then they might wind up as an alternate set of frags as well.
>At the moment, my modifications are in the early stages and not ready for a
>patch yet. However, they are representing formatting with <field><c>
></c></field> when exported. Only a minor modification was needed to the
>exporter since it already knows how to handle fp_Frag_Text objects'
>formatting. When a px_CR_Object is found <field> is inserted. The test is
>then inserted as if it was user text. As soon as a Change Object is found
>without a pointer to the Field object a </field> is inserted.
This sounds like a good workaround for now. However, since we have other
objects which aren't fields, feel free to introduce some discrete piece
table classes for this.
>At the moment
>the user can individually format parts of the field, but it is lost at
>update. I agree this is undesirable, but could be got around in the same way
>as you describe for output. It could just be extracted from the fp_Frag_Text
>before the next update.
Agreed. Losing formatting on user-driven updates for the following two
reasons may be acceptable:
- resetting the field value (via a manual update)
- changing the field (via hand-editing, if allowed)
Losing formatting during automatic updates isn't. However, I can't think of
a cleaner way to deal with it, either.
>My main objection to this is that it is very restricting to have a field
>represented by a single run object. As I understand it text wrapping is done
>by splitting two fp_TextRuns. Any field with more than one word eg: a
>reference to a document title or comment, will need the ability to wrap. It
>would therefore be simpler to allow reuse of all the wrapping code by
>representing the contents of fields with fp_TestRuns just modifiend to
>prevent editing.
Yep. Even if we want to allow partial editing of field contents, probably
the only changes allowed will be deletions or formatting. I'm (mostly) with
Justin on this one -- inserting arbitrary content (such as other fields)
doesn't make sense to me, either.
>May be I've completly misunderstood the code, but no one
>ever got back to me either way on it.
This sounds like you're *totally* on the right track. Sorry for not getting
back to you personally, but it sounds like you've already figured out more
than I would have been able to tell you.
Paul
