My real concern is the fact that findLeaf() is used in so many places. It makes the assumption that you can find a leaf by index anywhere in a text flow. That assumption falls apart with tables. I make a clear separation between tables and their contents. As far as the text flow is concerned, the table has a single index (and can only be selected as a whole when selected with surrounding text).
So, unless I go through every place findLeaf() is used in TLF and make special cases for tables, the only way I can see of handling it is by making a table a leaf. Even if I fix all the findLeaf() calls in the framework, I’d still be causing client code to fall apart when it comes to tables. Although tables have cell children, they are not index tracked within the text flow as other children are. I could override the text property to return all text contents of all cells in the table. That actually makes kind of sense. On Jun 9, 2014, at 6:59 AM, Alex Harui <aha...@adobe.com> wrote: > Hmm. The doc says that FlowLeafElement doesn't have any children. But > Tables can certainly contain other tables, right? And aren't the > headers/rows/cells considered children? > > FlowLeafElement also has a text property. Are you going to be overriding > that? > > Is it just too hard to make a TableElement extend FlowElement and in other > ways be treated as an InlineGraphicElement? > > -Alex > > On 6/8/14 12:46 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Please see this issue. I¹m sure there are plenty of related bugs. >> >> https://github.com/Harbs/TLF-Table-Work/issues/28 >> >> I¹m thinking of changing the base-class of TableElement to change it to a >> leaf element rather than a group element. I don¹t see any reason off-hand >> not to do that, but I very likely might be missing something. >> >> Reason why I think it makes sense: >> >> Basically, I¹m treating a table as an inline object. The contents of a >> table are laid out in a grid, but largely independent from the main text >> composition. It¹s really not much more than a really fancy inline object >> (or one that can span across multiple containers). >> >> If anyone can think of a good reason why it¹s a bad idea, I¹d really like >> to hearŠ >> >> Harbs >
