The problem is that a paragraph needs a terminator. So, it has to have a SpanElement in addition to the TableElement. Adding the span for the terminator caused all sorts of issues which sent me down the rabbit hole today.
There’s two ways I can see to go: 1) Instead of nesting a table inside a paragraph, I can subclass ParagraphElement like you suggested earlier. I’m not completely sure how I’d resolve the terminator issue even if I subclass ParagraphElement. 2) I can change ParagraphElement so it can contain more than one TextBlock. Tables do not need TextBlocks because the text composition takes place inside the cells. On Jun 11, 2014, at 6:41 PM, Alex Harui <aha...@adobe.com> wrote: > In HTML, I thought Table defaults to a block element, effectively ending > the paragraph. > > If that's true, then: > <p> some text <table>(table content)</table> more text </p> > > Should be re-factored as: > <p> some text </p><table>(table content)</table><p> more text </p> > > And then table would have its own TextBlock? > > -Alex > > On 6/11/14 8:25 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> FYI: >> >> I’ve been having a really difficult time resolving content with >> TextBlocks. I can’t seem to work within TextBlocks and keep the tables >> outside a composed TextLine. Making the width really wide just messes >> things up. >> >> I tried keeping the table outside the TextBlock, but that causes all >> kinds of issues related to selections and the like. >> >> After struggling with this all day, I’m rethinking the TextBlock <-> >> Paragraph one-to-one ratio. Yes. TextBlocks generally correspond to a >> single paragraph, but when a table would break a paragraph into two, the >> text above the table, and the text below the table are in effect two >> separate TextBlocks. So, I’m thinking of changing >> ParagraphElement.getTextBlock() to return a Vector.<TextBlock> instead of >> TextBlock. It would track a separate TextBlock for each section of text >> within the paragraph. >> >> It’s a bit messy, but I’m not sure what else to do at this point... >> >> On Jun 10, 2014, at 11:46 PM, Harbs <harbs.li...@gmail.com> wrote: >> >>> >>> On Jun 10, 2014, at 11:10 PM, Alex Harui <aha...@adobe.com> wrote: >>> >>>> >>>>>> Just wondering, did you consider a plan where you tell TLF that the >>>>>> table >>>>>> is another container? Or maybe each cell is another container in >>>>>> row-major order? Would that eliminate some or all of these issues? >>>>> >>>>> Not sure I understand what you¹re asking. The way I¹m currently >>>>> handling >>>>> cells, is by creating containers for each one. Tables are composed >>>>> using >>>>> TextFlowTableBlocks for each visual section of the table. >>>> Right now it seems like you have to create a tree of TextFlows. IIUC, >>>> one >>>> TextFlow cannot represent a document with tables and cells in it. This >>>> also seems to create challenges around selection and also the wrapping >>>> of >>>> tables in paragraphs. >>> >>> The table is composed as part of the text flow similar to composition >>> of ParagraphElements or SpanElements. Composing the table causes >>> sub-composition of the nested content. But each section is composed >>> similar to how lines are composed. The composition supports tables >>> spanning multiple containers in the main textflow. >>> >>>> IIRC, TLF already supports composing a single TextFlow into multiple >>>> containers, but I believe it only knows how to fill up a container >>>> before >>>> moving to the next container. I was wondering if a table/cell element >>>> could have just caused a jump to the next container. >>> >>> Yes. Composition walks through the containers and only looks at the >>> next container once the current container is filled. We do not want to >>> jump to the next container for tables, because the container bounds is >>> really outside the scope of composition. We want the table to be >>> composed within the bounds of current container if it will fit. That’s >>> why I am composing table content into TextFlowTableBlocks which subclass >>> TextFlowLine. This allows the table content to be composed as regular >>> lines would. it should even allow for vertical text justification and >>> the like. The section of table would all be treated as a single line. >>> Any cell content in the table that does NOT fit, is pushed to the next >>> container of the parent textflow and composed in a new >>> TextFlowTableBlock. >>> >>> >> >
