flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: TableElements as FlowLeafElement
Date Wed, 11 Jun 2014 17:24:18 GMT
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 <aharui@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.lists@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.lists@gmail.com> wrote:
>> 
>>> 
>>> On Jun 10, 2014, at 11:10 PM, Alex Harui <aharui@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.
>>> 
>>> 
>> 
> 


Mime
View raw message