This seems to be working well. Next problem:
https://github.com/Harbs/TLF-Table-Work/issues/29 TLF assumes in quite a few places that all leaves belong to a paragraph. If tables can be siblings of paragraphs (as it stands now), this will not work. I’m thinking of requiring tables to be children of paragraphs. I cannot think of any obvious problems with this. Anything obvious that I’m missing? Harbs On Jun 10, 2014, at 1:15 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 6/9/14 1:09 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Here¹s a wacky idea: >> >> I can leave tables as group elements for managing table cell elements and >> formatting inheritance purposes. >> I can introduce a TableLeafElement class whose sole purpose is describing >> the contents of the table and satisfying getLeaf() calls. I¹d override >> getLeaf() for TableElement to return TableLeafElement. > Worth a try. >> >> On Jun 9, 2014, at 10:59 PM, Harbs <harbs.li...@gmail.com> wrote: >> >>> Bah! >>> >>> I¹ve been relying on replaceChildren(), findChild(), etc.for >>> TableCellElements. >>> >>> None of that will work if I change TableElement to a leafŠ >>> >>> I could really use multiple inheritance. >>> >>> Why was TLF designed that elements are either leaf elements of group >>> elements? Couldn¹t elements conceivably be both / either? > > Even in Flash, the tree consists of containers (Sprite and Shapes) and > leaf nodes (Graphics, Bitmaps). I think it can get messy or slow if there > are lots of leaves and each one still needs to be checked for children. >
