Subject: Re: fields again
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Apr 05 2000 - 00:17:59 CDT
On Tue, 4 Apr 2000, Justin Bradford wrote:
I read through your email. I'm particularly interested in the new "group"
object.
>
> So all we really need is an object which contains the meta-span
> information (the attributes of the field) and for the spans in this
> sub-block to know they're in a sub-block.
>
> This is what Keith did, by adding a m_pField attribute to the fmt/Run
> classes. He also extended the contructor methods to set this explicitly,
> but I think we can take the same idea, coupled with a few modifications
> and minor extensions and make something pretty versatile and less
> obtrusive (which is my main concern with Keith's first draft).
>
> In the piecetable, there is a new fragment type: group, which has
> a generic "end" fragment to correspond to a normal "open" fragment.
>
> A new class in the formatter (Group) is added. Blocks will now contain a
> list of Groups contained in the block.
> Additionally, a new simple Run subclass is made. These have widths of zero
> and are basically group delimiters. These should also be useful in making
> the selection tweaking logic less complex.
Yes! This would be great. I spent last night looking over Luke's List
patch in detail. It is pretty badly broken for the lack of formating
information inside fields. It does not appear possible to set font sizes
within fields as it currently stands. Having a group that encompasses both
a field and the surrounding text would solve this problem nicely. The
group could encompass just the field and we could set the font attributes
(font type, size, boldness etc) to the field that way or from the text
itself.
As it presently stands the field code ignores the font attributes of the
surrounding text. I have not delved into the piece table code yet to see
if it can be made to accept different font attributes. But this would be
messy compared to this scheme.
>
> And, of course, the Run classes in the formatter get a m_pGroup attribute.
>
> Now, you don't have to explicitly tell a run it's in a group. It can tell
> from it's neighboring run's. Insert/deletes/splits of runs can determine
> this automatically, and are capable of identifying the group they're in.
>
> Now, when it comes to drawing, the specific display properties of this run
> can be extracted from the group. So, the gray background you see when the
> insertion point is on a field is dictated via the group object. We can
> make the specific color an attribute of the <f> tag in the xml now. And,
> we can have the group provide other certain coordinated behaviors. For
> instace, the group could hide itself (return 0 for widths and don't draw).
> Perhaps we can work in a click handler, for implementation of URLs.
>
I really like this idea. Will you code it? It is too deep for me but I
don't think it is worth fixing Luke's Lists (TM) without this.
> Also, notice that any span or object can go in these. This includes
> text, images, and other future objects. So a field could generate
> something besides text. I'm not sure that's useful, but at least it would
> be doable with the this new structure.
I wonder if it could be used for tables too? They could be collection of
calculated element sizes. We set the horizontal spacing via a gui and the
text in formatted using our standard formatter with a box whose vertical
size is calculated from the text size. The formatter puts the text within
the calculated box size. We can set font attributes for each text
box elegantly via a group which can span one or more text boxes.
Cheers
Martin
This archive was generated by hypermail 2b25 : Wed Apr 05 2000 - 00:18:10 CDT