On Sun, 24 Sep 2000, Paul Rohr wrote:

<snip>
> 
>   - PTX_Field
>   - PTX_FieldEnd (or PFT_StruxEnd, if feasible)
>   - the associated pf_Frag_Strux subclasses
> 
>   - a collection of ff_Field objects hanging off blocks
>   - logic so runs can find their associated fields (cf: squiggle)

I'm not sure we need strux's. My main concern is my lack of knowledge of
how a new strux would map to the layout classes. Would we need a
fl_FieldLayout class like a fl_BlockLayout? That sounds like a horrendous
amount of work.

Especially since Keith's field as a fragment seems to work fine.

> 
> In addition, the existing field-as-atomic-object hacks can all be removed 
> from both the piece table and the formatter. 
> 

I like the inline fields. See my other post.

> Note that unlike the other existing strux types, fields aren't necessarily 
> adjacent, so there will need to be some additional logic to skip over 
> matching End objects when looking for the containing PTX_Field:
> 
>   pt_PieceTable::_getStruxOfTypeFromPosition()
> 
> It might be a little easier to see how the mappings work if we compare how a 
> simple document gets represented in each of the three areas:
> 
>   markup        attr?   pt frag types               formatter
>   ------        -----   -------------               ---------
>   <section>     opt     PFT_Strux, PTX_Section      fl_SectionLayout
>   <p>           opt     PFT_Strux, PTX_Block        fl_BlockLayout
>   ...           no      PFT_Text                    fp_TextRun
>   <field>       yes     PFT_Strux, PTX_Field        ff_Field
>     ...         no      PFT_Text                    fp_TextRun
>     <c>...</c>  yes     PFT_Text                    fp_TextRun
>     ...         no      PFT_Text                    fp_TextRun
>   </field>      no      PFT_Strux, PTX_FieldEnd     (implied)
>   ...           no      PFT_Text                    fp_TextRun
>   </p>          no      (implied)                   (implied)
>   </section>    no      (implied)                   (implied)
> 
> Note that since we're implementing fields as strux, we can use all of the 
> usual tricks with StruxFmtHandle and StruxDocHandle to exchange information 
> (for a given field) back and forth between the formatter and the piece
> table.  
> 
> Is this making sense so far?
> 

I'm concerned that this is too much work for no enough reward. If we can
build a TOC within a Block I don't see that we need a Field strux. Other
more complex uses of fields can be implemented via scripting.

Martin
 




Reply via email to