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