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. > >
