Re: TLF Tables

[Harbs <ha...@gmail.com>]

This is really difficult, because I'm not sure what is supposed to work in the current implementation. I'm trying to reverse engineer how tables work when they don't really work. Trying to sift out what I don't understand from what simply doesn't work from what is poorly implemented is a huge pain.

I'm going to ramble a bit. I hope that things will become clearer to me as I ramble on… ;-)

If someone who understands how text flow in TLF is supposed to work would either confirm or correct me, I'd appreciate it.

Here's how I understand the way TLF works with parcels:

Each composition has a ParcelList which contains one or more parcels. Each ContainerController has one or more parcels in the ParcelList. Generally, there is one parcel per column. (If a ContainerController has more than one column, the composition of each column is done separately as a separate parcel.)

For normal text frames, this is all pretty straight-forward.

With tables things get a bit more muddled. Each table cell is in effect a separate composition area. If every composition area gets its own parcel, I guess this would mean that every cell in the table would get its own parcel. If I'm reading the code correctly, it's supposed to be doing this. I think another way to look at it, would be to look at each column of each table within a specific Container as a separate composition area (parcel) and position the text within that. I'm not sure this makes any sense, though. The more I'm looking at how parcels work (i.e. vj, etc.), the less this makes sense.

So, basically, every cell in the table would be a separate parcel, and these parcels need to be organized into rows and columns. Keeping track of the columns and the placement of the rows has some level of complexity. Adding header and footer rows to the mix should make it more interesting.

Here's what I'm not (yet) totally clear on (or even if it works right):
1) The logic of placing the table parcels relative to the container parcels. The way I see it, the table parcels should be arranged within the bounds of the column parcels of the containing container(s).
2) How the calculations of the parcel placement goes. This is especially true for tables that might span more than one parent parcel.
3) The placement of the table parcels relative to the container parcels they are contained within. (Should there be a separate ParcelList for table parcels, or should it be part of the main ParcelList?)
4) What I'm not clear on… ;-)

On Nov 28, 2013, at 3:20 PM, Harbs wrote:

> I'm back on this, and starting to make some (slow) progress.
> 
> I've started a Google Docs document to try to make some order out of the chaos that is the current state of TLF Tables. This is just a place where I'm jotting down my findings as I go and my thoughts on direction as I work on this. I made the document publicly editable and would love input. If there's anyone out there that has answers to the questions I'm posing, it would be very helpful!
> 
> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj0zDmSog/edit?usp=sharing
> 
> Harb
> 
> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
> 
>> My first tests are not very encouraging…
>> 
>> Trying to compose the table results in this function returning null:
>> 		static tlf_internal function beginFactoryCompose():SimpleCompose
>> 		{
>> 			var rslt:SimpleCompose = _factoryComposer;
>> 			_factoryComposer = peekFactoryCompose();
>> 			_savedFactoryComposer = null;
>> 			return rslt;
>> 		}
>> 
>> Looks like I need to the composition process...
>> FWIW, it made no difference whether I added the rows to a TableBodyElement or to the table directly.
>> 
>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>> 
>>> Hi Harbs,
>>> 
>>> I see code for Tables, but I'm not sure it is "officially" there.  Or even
>>> complete, or even working at a prototype-level.
>>> 
>>> So good luck with it.  I might be able to ask folks who used to work on it
>>> a few questions, but I'm pretty sure their memories of it are pretty dim
>>> by now.
>>> 
>>> -Alex
>>> 
>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> I knew I was going to spend some real time on this one day, and that time
>>>> is coming really soonŠ
>>>> 
>>>> Before I dig in too deeply, what's the status on TLF Table support? I
>>>> know it's officially there, but I don't see any documentation on it --
>>>> not even the basics on how it's supposed to be used.
>>>> 
>>>> I fully expect to find bugs once I start really digging into it, but some
>>>> documentation (any) would be nice to get me started.
>>>> 
>>>> Looking at the source code, I see the following classes:
>>>> 
>>>> TableElement
>>>> TableBodyElement
>>>> TableColElement
>>>> TableRowElement
>>>> TableColGroupElement
>>>> TableDataCellElement
>>>> TableFormattedElement
>>>> 
>>>> I understand the structure like this:
>>>> 
>>>> * A TableElement is the top level element for any table
>>>> * All elements in a table inherit from TableFormattedElement
>>>> * The bottom level of a table which needs to contain one or more
>>>> ParagraphElements in a TableDataCellElement
>>>> * TableDataCellElements must reside within a TableRowElement
>>>> 
>>>> After this things get a bit fuzzier.
>>>> 
>>>> What is TableBodyElement used for?
>>>> How is TableColGroupElement and TableColElement used? (I assume they are
>>>> used for formatting table columns, but the details are not very clear to
>>>> me.)
>>>> What about header and footer rows? Is that supported yet?
>>>> Header and footer columns?
>>>> Is breaking tables across containers supported yet?
>>>> 
>>>> I have not started studying how to specify table formatting either. I'm
>>>> hoping that's obviousŠ
>>>> 
>>>> I'll try to add some documentation to the source code as things become
>>>> clearer to meŠ
>>>> 
>>>> Harbs
>>> 
>> 
> 

Re: TLF Tables

[Harbs <ha...@gmail.com>]

Thanks. That should be helpful. I think I'll revisit conflicts once things are more-or-less working…

On Dec 6, 2013, at 2:35 AM, jude wrote:

> I would reference the W3C spec for a few reasons. One you almost starting
> from scratch because it's not yet functioning and two, the author of what
> has been done may have been referencing it in which case you'd find out
> soon enough.
> 
> I've found a lot of valuable information when I was looking up
> accessibility support in HTML. They have a section on border conflict
> resolution here,
> http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution.
> 
> As far as DTP support goes, I would think that a product like InDesign
> would require more fidelity. Since the HTML spec for a Table tag is mainly
> for viewing multidimensional data it may lack the considerations that a
> Flex application may require. But would you be using TLF tables for
> editing? It may be something like the Label and RichEditableText components
> where you have one that is for display and another that supports more
> advanced features. Like Alex said, it's more what your goals are.
> 
> 
> On Thu, Dec 5, 2013 at 12:47 PM, Harbs <ha...@gmail.com> wrote:
> 
>> 
>> On Dec 5, 2013, at 7:28 PM, Alex Harui wrote:
>> 
>>> 
>>> 
>>> On 12/5/13 12:11 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> Okay. To sum up:
>>> I'm not sure I picked up on whatever point you were trying to make with
>>> the HTML table examples.
>> 
>> There were two points.
>> 
>> One was the existence of column groups for setting column styling. I'm not
>> sure I see any advantage to that over setting the columns directly
>> 
>> The second one was table head, table footer and table body elements. The
>> advantage of those would be being able to set all the body cell properties
>> in the table body element. Of course, the same thing could be accomplished
>> by setting the table properties and overriding them for header/footer rows.
>> 
>>>> I need some take-aways from this.
>>>> 
>>>> 1) Do we care to style TLF tables after HTML so the above markup will
>>>> render? If yes, we probably want table body, table header and table
>>>> footer elements, as well as column groups.
>>> Would be nice, but for now, just make the code do what you want it to do.
>>> I kind of doubt anyone has used TLF tables so I'm not sure anyone will
>>> notice if you change existing behavior.
>> 
>> I really doubt they were used because they don't work… ;-)
>> 
>> I'm thinking of leaving out these elements and if we want to support the
>> markup, we could just parse the markup and apply the styling. (or add the
>> elements later on)
>> 
>>>> 
>>>> 4) I'm not sure how to handle border settings. What do I do if cell #1
>>>> has a 3 pixel border on the right, and cell #2 (to the right of that)
>> has
>>>> a 1 pixel border on the left? Do I draw a 3px line (higher number)? A
>> 1px
>>>> line (lower number)? A 2px line (the average)? or a 2px line ((higher/2)
>>>> + (lower/2)? (I'm not sure there's any difference between the last two
>>>> options.)
>>> I could definitely be wrong, but I thought that either you draw both or
>>> the CSS folks might have some rules on this specified somewhere, like
>>> their rules around margin handling.  I think in HTML, there may be a
>>> default margin between cells that would allow both borders to show with
>>> some space between them.  Flex doesn't support margins and means that
>>> these things can draw on top of each other, but maybe that's still the
>>> right thing to do.
>> 
>> I think HTML and DTP application take very different approaches here.
>> Word, for example draws the wider of the two lines. Vertical lines are
>> split between the two cells, while horizontal lines have the top of the
>> line aligned with the top of the cell. OpenOffice has a mixed approach
>> where the top and bottom lines take the wider stroke. Vertical strokes
>> follow the left cell. Although, I'm not sure how it works internally. It
>> could all be a UI thing… As usual, I like InDesign's behavior. Line weight
>> is always split between cells. Again, I'm not sure how conflicting
>> weights/colors are handled internally.
>> 
>> None of the aforementioned apps have gaps between cells. I have no need
>> for them. Should I care?
>> 
>> One way I can handle things would be for each cell to have their own
>> borders. So, if cell #1 has a 1pt border and cell #2 has a 1pt border.
>> Assuming there's no gap between them, a 2pt border will be drawn between
>> the cells. If there's a 1pt gap, there would be a double line between them.
>> As I'm writing this, I think this does make the most sense. It should offer
>> the highest level of flexibility, and we don't need to deal with conflicts.
>> 
>>> -Alex
>>> 
>> 
>> 

Re: TLF Tables

[jude <fl...@gmail.com>]

I would reference the W3C spec for a few reasons. One you almost starting
from scratch because it's not yet functioning and two, the author of what
has been done may have been referencing it in which case you'd find out
soon enough.

I've found a lot of valuable information when I was looking up
accessibility support in HTML. They have a section on border conflict
resolution here,
http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution.

As far as DTP support goes, I would think that a product like InDesign
would require more fidelity. Since the HTML spec for a Table tag is mainly
for viewing multidimensional data it may lack the considerations that a
Flex application may require. But would you be using TLF tables for
editing? It may be something like the Label and RichEditableText components
where you have one that is for display and another that supports more
advanced features. Like Alex said, it's more what your goals are.


On Thu, Dec 5, 2013 at 12:47 PM, Harbs <ha...@gmail.com> wrote:

>
> On Dec 5, 2013, at 7:28 PM, Alex Harui wrote:
>
> >
> >
> > On 12/5/13 12:11 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> Okay. To sum up:
> > I'm not sure I picked up on whatever point you were trying to make with
> > the HTML table examples.
>
> There were two points.
>
> One was the existence of column groups for setting column styling. I'm not
> sure I see any advantage to that over setting the columns directly
>
> The second one was table head, table footer and table body elements. The
> advantage of those would be being able to set all the body cell properties
> in the table body element. Of course, the same thing could be accomplished
> by setting the table properties and overriding them for header/footer rows.
>
> >> I need some take-aways from this.
> >>
> >> 1) Do we care to style TLF tables after HTML so the above markup will
> >> render? If yes, we probably want table body, table header and table
> >> footer elements, as well as column groups.
> > Would be nice, but for now, just make the code do what you want it to do.
> > I kind of doubt anyone has used TLF tables so I'm not sure anyone will
> > notice if you change existing behavior.
>
> I really doubt they were used because they don't work… ;-)
>
> I'm thinking of leaving out these elements and if we want to support the
> markup, we could just parse the markup and apply the styling. (or add the
> elements later on)
>
> >>
> >> 4) I'm not sure how to handle border settings. What do I do if cell #1
> >> has a 3 pixel border on the right, and cell #2 (to the right of that)
> has
> >> a 1 pixel border on the left? Do I draw a 3px line (higher number)? A
> 1px
> >> line (lower number)? A 2px line (the average)? or a 2px line ((higher/2)
> >> + (lower/2)? (I'm not sure there's any difference between the last two
> >> options.)
> > I could definitely be wrong, but I thought that either you draw both or
> > the CSS folks might have some rules on this specified somewhere, like
> > their rules around margin handling.  I think in HTML, there may be a
> > default margin between cells that would allow both borders to show with
> > some space between them.  Flex doesn't support margins and means that
> > these things can draw on top of each other, but maybe that's still the
> > right thing to do.
>
> I think HTML and DTP application take very different approaches here.
> Word, for example draws the wider of the two lines. Vertical lines are
> split between the two cells, while horizontal lines have the top of the
> line aligned with the top of the cell. OpenOffice has a mixed approach
> where the top and bottom lines take the wider stroke. Vertical strokes
> follow the left cell. Although, I'm not sure how it works internally. It
> could all be a UI thing… As usual, I like InDesign's behavior. Line weight
> is always split between cells. Again, I'm not sure how conflicting
> weights/colors are handled internally.
>
> None of the aforementioned apps have gaps between cells. I have no need
> for them. Should I care?
>
> One way I can handle things would be for each cell to have their own
> borders. So, if cell #1 has a 1pt border and cell #2 has a 1pt border.
> Assuming there's no gap between them, a 2pt border will be drawn between
> the cells. If there's a 1pt gap, there would be a double line between them.
> As I'm writing this, I think this does make the most sense. It should offer
> the highest level of flexibility, and we don't need to deal with conflicts.
>
> > -Alex
> >
>
>

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

OK, good luck ;-)

On 12/5/13 10:47 AM, "Harbs" <ha...@gmail.com> wrote:

>
>On Dec 5, 2013, at 7:28 PM, Alex Harui wrote:
>
>> 
>> 
>> On 12/5/13 12:11 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> Okay. To sum up:
>> I'm not sure I picked up on whatever point you were trying to make with
>> the HTML table examples.
>
>There were two points.
>
>One was the existence of column groups for setting column styling. I'm
>not sure I see any advantage to that over setting the columns directly
>
>The second one was table head, table footer and table body elements. The
>advantage of those would be being able to set all the body cell
>properties in the table body element. Of course, the same thing could be
>accomplished by setting the table properties and overriding them for
>header/footer rows.
>
>>> I need some take-aways from this.
>>> 
>>> 1) Do we care to style TLF tables after HTML so the above markup will
>>> render? If yes, we probably want table body, table header and table
>>> footer elements, as well as column groups.
>> Would be nice, but for now, just make the code do what you want it to
>>do.
>> I kind of doubt anyone has used TLF tables so I'm not sure anyone will
>> notice if you change existing behavior.
>
>I really doubt they were used because they don't workŠ ;-)
>
>I'm thinking of leaving out these elements and if we want to support the
>markup, we could just parse the markup and apply the styling. (or add the
>elements later on)
>
>>> 
>>> 4) I'm not sure how to handle border settings. What do I do if cell #1
>>> has a 3 pixel border on the right, and cell #2 (to the right of that)
>>>has
>>> a 1 pixel border on the left? Do I draw a 3px line (higher number)? A
>>>1px
>>> line (lower number)? A 2px line (the average)? or a 2px line
>>>((higher/2)
>>> + (lower/2)? (I'm not sure there's any difference between the last two
>>> options.)
>> I could definitely be wrong, but I thought that either you draw both or
>> the CSS folks might have some rules on this specified somewhere, like
>> their rules around margin handling.  I think in HTML, there may be a
>> default margin between cells that would allow both borders to show with
>> some space between them.  Flex doesn't support margins and means that
>> these things can draw on top of each other, but maybe that's still the
>> right thing to do.
>
>I think HTML and DTP application take very different approaches here.
>Word, for example draws the wider of the two lines. Vertical lines are
>split between the two cells, while horizontal lines have the top of the
>line aligned with the top of the cell. OpenOffice has a mixed approach
>where the top and bottom lines take the wider stroke. Vertical strokes
>follow the left cell. Although, I'm not sure how it works internally. It
>could all be a UI thingŠ As usual, I like InDesign's behavior. Line
>weight is always split between cells. Again, I'm not sure how conflicting
>weights/colors are handled internally.
>
>None of the aforementioned apps have gaps between cells. I have no need
>for them. Should I care?
>
>One way I can handle things would be for each cell to have their own
>borders. So, if cell #1 has a 1pt border and cell #2 has a 1pt border.
>Assuming there's no gap between them, a 2pt border will be drawn between
>the cells. If there's a 1pt gap, there would be a double line between
>them. As I'm writing this, I think this does make the most sense. It
>should offer the highest level of flexibility, and we don't need to deal
>with conflicts.
>
>> -Alex
>> 
>

Re: TLF Tables

[Harbs <ha...@gmail.com>]

On Dec 5, 2013, at 7:28 PM, Alex Harui wrote:

> 
> 
> On 12/5/13 12:11 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Okay. To sum up:
> I'm not sure I picked up on whatever point you were trying to make with
> the HTML table examples.

There were two points.

One was the existence of column groups for setting column styling. I'm not sure I see any advantage to that over setting the columns directly

The second one was table head, table footer and table body elements. The advantage of those would be being able to set all the body cell properties in the table body element. Of course, the same thing could be accomplished by setting the table properties and overriding them for header/footer rows.

>> I need some take-aways from this.
>> 
>> 1) Do we care to style TLF tables after HTML so the above markup will
>> render? If yes, we probably want table body, table header and table
>> footer elements, as well as column groups.
> Would be nice, but for now, just make the code do what you want it to do.
> I kind of doubt anyone has used TLF tables so I'm not sure anyone will
> notice if you change existing behavior.

I really doubt they were used because they don't work… ;-)

I'm thinking of leaving out these elements and if we want to support the markup, we could just parse the markup and apply the styling. (or add the elements later on)

>> 
>> 4) I'm not sure how to handle border settings. What do I do if cell #1
>> has a 3 pixel border on the right, and cell #2 (to the right of that) has
>> a 1 pixel border on the left? Do I draw a 3px line (higher number)? A 1px
>> line (lower number)? A 2px line (the average)? or a 2px line ((higher/2)
>> + (lower/2)? (I'm not sure there's any difference between the last two
>> options.)
> I could definitely be wrong, but I thought that either you draw both or
> the CSS folks might have some rules on this specified somewhere, like
> their rules around margin handling.  I think in HTML, there may be a
> default margin between cells that would allow both borders to show with
> some space between them.  Flex doesn't support margins and means that
> these things can draw on top of each other, but maybe that's still the
> right thing to do.

I think HTML and DTP application take very different approaches here. Word, for example draws the wider of the two lines. Vertical lines are split between the two cells, while horizontal lines have the top of the line aligned with the top of the cell. OpenOffice has a mixed approach where the top and bottom lines take the wider stroke. Vertical strokes follow the left cell. Although, I'm not sure how it works internally. It could all be a UI thing… As usual, I like InDesign's behavior. Line weight is always split between cells. Again, I'm not sure how conflicting weights/colors are handled internally.

None of the aforementioned apps have gaps between cells. I have no need for them. Should I care?

One way I can handle things would be for each cell to have their own borders. So, if cell #1 has a 1pt border and cell #2 has a 1pt border. Assuming there's no gap between them, a 2pt border will be drawn between the cells. If there's a 1pt gap, there would be a double line between them. As I'm writing this, I think this does make the most sense. It should offer the highest level of flexibility, and we don't need to deal with conflicts.

> -Alex
> 

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

On 12/5/13 12:11 AM, "Harbs" <ha...@gmail.com> wrote:

>Okay. To sum up:
I'm not sure I picked up on whatever point you were trying to make with
the HTML table examples.


>I need some take-aways from this.
>
>1) Do we care to style TLF tables after HTML so the above markup will
>render? If yes, we probably want table body, table header and table
>footer elements, as well as column groups.
Would be nice, but for now, just make the code do what you want it to do.
I kind of doubt anyone has used TLF tables so I'm not sure anyone will
notice if you change existing behavior.
>
>4) I'm not sure how to handle border settings. What do I do if cell #1
>has a 3 pixel border on the right, and cell #2 (to the right of that) has
>a 1 pixel border on the left? Do I draw a 3px line (higher number)? A 1px
>line (lower number)? A 2px line (the average)? or a 2px line ((higher/2)
>+ (lower/2)? (I'm not sure there's any difference between the last two
>options.)
I could definitely be wrong, but I thought that either you draw both or
the CSS folks might have some rules on this specified somewhere, like
their rules around margin handling.  I think in HTML, there may be a
default margin between cells that would allow both borders to show with
some space between them.  Flex doesn't support margins and means that
these things can draw on top of each other, but maybe that's still the
right thing to do.

-Alex

Re: TLF Tables

[Harbs <ha...@gmail.com>]

Okay. To sum up:

In HTML, the following is valid:

<table border="1">
  <colgroup>
    <col span="2" style="background-color:red">
    <col style="background-color:yellow">
  </colgroup>
  <tr>
    <th>ISBN</th>
    <th>Title</th>
    <th>Price</th>
  </tr>
  <tr>
    <td>3476896</td>
    <td>My first HTML</td>
    <td>$53</td>
  </tr>
  <tr>
    <td>5869207</td>
    <td>My first CSS</td>
    <td>$49</td>
  </tr>
</table>

As is this:
<table border="1">
  <thead>
    <tr>
      <th>Month</th>
      <th>Savings</th>
    </tr>
  </thead>
  <tfoot>
    <tr>
      <td>Sum</td>
      <td>$180</td>
    </tr>
  </tfoot>
  <tbody>
    <tr>
      <td>January</td>
      <td>$100</td>
    </tr>
    <tr>
      <td>February</td>
      <td>$80</td>
    </tr>
  </tbody>
</table>

As well as rowspan and colspan.

I don't think cell splits are supported, but they are in DTP applications.

I need some take-aways from this.

1) Do we care to style TLF tables after HTML so the above markup will render? If yes, we probably want table body, table header and table footer elements, as well as column groups.
2) Since I don't see any real reason not to make cells children of rows, and that's the way it's done in HTML, I'm going that direction.
3) As far as cell backgrounds go, that's more-or-less straightforward. (Cell settings override row, column and table.) I'm not sure how to handle rows vs. columns though. I'm thinking that row settings should override column settings.
4) I'm not sure how to handle border settings. What do I do if cell #1 has a 3 pixel border on the right, and cell #2 (to the right of that) has a 1 pixel border on the left? Do I draw a 3px line (higher number)? A 1px line (lower number)? A 2px line (the average)? or a 2px line ((higher/2) + (lower/2)? (I'm not sure there's any difference between the last two options.)

On Dec 5, 2013, at 1:43 AM, Alex Harui wrote:

> 
> 
> On 12/4/13 2:28 PM, "Harbs" <ha...@gmail.com> wrote:
> 
>> It does seem that the table elements were styled after html tables.
>> That's where the column groups and table body elements come in:
>> http://www.w3schools.com/tags/tag_colgroup.asp
>> http://www.w3schools.com/tags/tag_tbody.asp
>> 
>> I think too much effort was made to style TLF after htmlŠ
> Maybe, but we heard lots of attempts to make TLF do HTML, so I'm not
> surprised that the code reflects some of that.
> 
> FWIW, back in the MX DataGrid days, I thought of trying to rowspan by
> changing the z-order of the rows and cells so that a cell that spanned a
> row was "above" everything else.
> 
> -Alex
> 
>> 
>> On Dec 5, 2013, at 12:20 AM, Harbs wrote:
>> 
>>> 
>>> On Dec 4, 2013, at 7:29 PM, Alex Harui wrote:
>>> 
>>>> 
>>>> 
>>>> On 12/4/13 6:40 AM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>>> I didn't explain myself very well here.
>>>>> 
>>>>> My point is that TLF elements inherit from their parents and we'd get
>>>>> that inheritance from the rows for free if cells are children of rows.
>>>> Yup, so if you set background color on the row it should cover the
>>>> margins
>>>> and padding between cells of that row, right?
>>> 
>>> Makes sense to me. Although, html table seem to not work like that. The
>>> background color is only for the cell area.
>>> 
>>>> I don't know how it is done in the browser.  If you specify a row with
>>>> a
>>>> blue background and the next row has red background but a cell in the
>>>> blue
>>>> row has rowSpan=2 does the blue in that cell cover the red?
>>> 
>>> Good question. I just tried and the red is replaced with blue.
>>>> 
>>>>> 
>>>>> On Dec 4, 2013, at 4:38 PM, Harbs wrote:
>>>>> 
>>>>>> If anything table/row/cell gives more flexibility.
>>>>> 
>>>> 
>>> 
>> 
> 

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

On 12/4/13 2:28 PM, "Harbs" <ha...@gmail.com> wrote:

>It does seem that the table elements were styled after html tables.
>That's where the column groups and table body elements come in:
>http://www.w3schools.com/tags/tag_colgroup.asp
>http://www.w3schools.com/tags/tag_tbody.asp
>
>I think too much effort was made to style TLF after htmlŠ
Maybe, but we heard lots of attempts to make TLF do HTML, so I'm not
surprised that the code reflects some of that.

FWIW, back in the MX DataGrid days, I thought of trying to rowspan by
changing the z-order of the rows and cells so that a cell that spanned a
row was "above" everything else.

-Alex

>
>On Dec 5, 2013, at 12:20 AM, Harbs wrote:
>
>> 
>> On Dec 4, 2013, at 7:29 PM, Alex Harui wrote:
>> 
>>> 
>>> 
>>> On 12/4/13 6:40 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> I didn't explain myself very well here.
>>>> 
>>>> My point is that TLF elements inherit from their parents and we'd get
>>>> that inheritance from the rows for free if cells are children of rows.
>>> Yup, so if you set background color on the row it should cover the
>>>margins
>>> and padding between cells of that row, right?
>> 
>> Makes sense to me. Although, html table seem to not work like that. The
>>background color is only for the cell area.
>> 
>>> I don't know how it is done in the browser.  If you specify a row with
>>>a
>>> blue background and the next row has red background but a cell in the
>>>blue
>>> row has rowSpan=2 does the blue in that cell cover the red?
>> 
>> Good question. I just tried and the red is replaced with blue.
>>> 
>>>> 
>>>> On Dec 4, 2013, at 4:38 PM, Harbs wrote:
>>>> 
>>>>> If anything table/row/cell gives more flexibility.
>>>> 
>>> 
>> 
>

Re: TLF Tables

[Harbs <ha...@gmail.com>]

It does seem that the table elements were styled after html tables. That's where the column groups and table body elements come in:
http://www.w3schools.com/tags/tag_colgroup.asp
http://www.w3schools.com/tags/tag_tbody.asp

I think too much effort was made to style TLF after html…

On Dec 5, 2013, at 12:20 AM, Harbs wrote:

> 
> On Dec 4, 2013, at 7:29 PM, Alex Harui wrote:
> 
>> 
>> 
>> On 12/4/13 6:40 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> I didn't explain myself very well here.
>>> 
>>> My point is that TLF elements inherit from their parents and we'd get
>>> that inheritance from the rows for free if cells are children of rows.
>> Yup, so if you set background color on the row it should cover the margins
>> and padding between cells of that row, right?
> 
> Makes sense to me. Although, html table seem to not work like that. The background color is only for the cell area.
> 
>> I don't know how it is done in the browser.  If you specify a row with a
>> blue background and the next row has red background but a cell in the blue
>> row has rowSpan=2 does the blue in that cell cover the red?
> 
> Good question. I just tried and the red is replaced with blue.
>> 
>>> 
>>> On Dec 4, 2013, at 4:38 PM, Harbs wrote:
>>> 
>>>> If anything table/row/cell gives more flexibility.
>>> 
>> 
> 

Re: TLF Tables

[Harbs <ha...@gmail.com>]

On Dec 4, 2013, at 7:29 PM, Alex Harui wrote:

> 
> 
> On 12/4/13 6:40 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I didn't explain myself very well here.
>> 
>> My point is that TLF elements inherit from their parents and we'd get
>> that inheritance from the rows for free if cells are children of rows.
> Yup, so if you set background color on the row it should cover the margins
> and padding between cells of that row, right?

Makes sense to me. Although, html table seem to not work like that. The background color is only for the cell area.

> I don't know how it is done in the browser.  If you specify a row with a
> blue background and the next row has red background but a cell in the blue
> row has rowSpan=2 does the blue in that cell cover the red?

Good question. I just tried and the red is replaced with blue.
> 
>> 
>> On Dec 4, 2013, at 4:38 PM, Harbs wrote:
>> 
>>> If anything table/row/cell gives more flexibility.
>> 
> 

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

On 12/4/13 6:40 AM, "Harbs" <ha...@gmail.com> wrote:

>I didn't explain myself very well here.
>
>My point is that TLF elements inherit from their parents and we'd get
>that inheritance from the rows for free if cells are children of rows.
Yup, so if you set background color on the row it should cover the margins
and padding between cells of that row, right?

I don't know how it is done in the browser.  If you specify a row with a
blue background and the next row has red background but a cell in the blue
row has rowSpan=2 does the blue in that cell cover the red?

>
>On Dec 4, 2013, at 4:38 PM, Harbs wrote:
>
>> If anything table/row/cell gives more flexibility.
>

Re: TLF Tables

[Harbs <ha...@gmail.com>]

I didn't explain myself very well here.

My point is that TLF elements inherit from their parents and we'd get that inheritance from the rows for free if cells are children of rows.

On Dec 4, 2013, at 4:38 PM, Harbs wrote:

> If anything table/row/cell gives more flexibility.

Re: TLF Tables

[Harbs <ha...@gmail.com>]

Whether rows/columns exist or not is a bit of an esoteric question.

I don't see table/cell helping with formatting. If anything table/row/cell gives more flexibility. There's no reason why you can't set the the cell border on the cell level using either system. If there's three levels, you could set properties (including cell borders) on any one of the levels. (Of course there's the question of how to set column properties, but we could fake that..)

You do bring up a question though:

How many border settings should there be? For example, if border width is set on the table level, there are six distinct border types: top, bottom, left, right, inside vertical, inside horizontal. I guess it should work like this:

Tables have top, bottom, left, right, inside vertical, inside horizontal
Columns have: top, bottom, left, right, inside horizontal
Rows have: top, bottom, left, right, inside vertical
Cells have: top, bottom, left, right

Cell setting trump column and row settings. Columns and rows trump table settings.
But here's the questions I have:

What about row and column? Which one wins?
How to handle border conflict between cell boundaries?

On Dec 4, 2013, at 3:32 PM, Avi Kessner wrote:

> I would vote for table/cells
> I think it more accurately describes a table.
> This way you could also more easily set the borders of cells like excell
> does.
> IMO rows and columns don't actually exist,  they are just a coordinate
> system to locate a cell.
> On Dec 4, 2013 2:42 PM, "Harbs" <ha...@gmail.com> wrote:
> 
>> There's one more issue I'm struggling with:
>> 
>> The way the elements were implemented is that rows are nested inside
>> tables and cells are inside rows. Table columns are not directly connected
>> to cells -- they are really just there to compute the position.
>> 
>> This makes sense in the way that the tables would normally be composed
>> (i.e. row by row).
>> 
>> The only issue I can see with this, would be joined cells. If cells are
>> joined horizontally, it would not be to complicated since the row would be
>> composed across.
>> 
>> Vertically joined cells would be much more complicated. Once cells are
>> joined vertically, a single cell would actually reside inside two different
>> rows. This does not jive very well with the concept of cells belonging to a
>> specific row. A better fit might be to make cells children of the table and
>> to have cells contain row and column info.
>> 
>> It might be possible to compose joined cells even if they are children of
>> rows and use placeholder objects to indicate the joined cell location
>> within the row -- or maybe skip that area.
>> 
>> I think I'm leaning towards sticking with tables/rows/cells rather than
>> tables/cells because I think it's neater for the classic tables, but I'm
>> not completely set on it.
>> 
>> I'd like to hear if anyone has input on the subject…
>> 
>> On Dec 2, 2013, at 9:08 PM, Alex Harui wrote:
>> 
>>> OK, good luck.
>>> 
>>> On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> The way it was implemented is like this:
>>>> 
>>>> 1) Tables and table columns have fixed widths. (I might add a default
>>>> width if none was set to prevent runtime errors. What's a reasonable
>>>> number?)
>>>> 2) Table cell parcels are created with a maximum height of 8000. I'm not
>>>> sure why they picked that number, but it's probably high enough that
>> it's
>>>> fine. After the cell is composed, the height of the parcel is adjusted.
>>>> 
>>>> This simplifies the calculations tremendously because tables can be
>>>> safely composed on a row-by-row basis. I think both of these limitations
>>>> are reasonable ones and it's pretty consistent with how tables work in
>>>> DTP apps. The only thing I'm probably going to change is to add the
>>>> option of a fixed height to the cell parcel where the contents would
>> just
>>>> become overset if it does not fit.
>>>> 
>>>> One thing I'm planning on changing is related to table widths.
>> Currently,
>>>> the width of a table is constrained by the with of the containing
>> parcel.
>>>> I think it's reasonable that tables can extend beyond the bounds of the
>>>> parent parcel. This is the way InDesign works and I think it's necessary
>>>> for tables that flow across multiple containers since the width of the
>>>> containers are not necessarily constant.
>>>> 
>>>> Another limitation that I think is reasonable is no nested tables.
>>>> InDesign for example allows unlimited levels of nesting tables inside
>>>> table cells. This adds a lot of complexity to the composition, and it
>>>> seems to me that this is an edge case. Does TLF currently support nested
>>>> text containers? (i.e. text containers as inline graphics)
>>>> 
>>>> I think I'm also going to not allow cells to split across containers as
>>>> this also adds complexity (and I personally have no need for this
>>>> support).
>>>> 
>>>> Harbs
>>>> 
>>>> On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
>>>> 
>>>>> Just a random thought here, but what if you set the parcels at the end
>>>>> of
>>>>> table creation?   Something like, populateParcels() which gets called
>>>>> after
>>>>> all cell sizes and positions are known, and then get placed into those
>>>>> rectangles?
>>>>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>> 
>>>>>> Harbs,
>>>>>> 
>>>>>> I haven't looked at the Table code at all.  I don't remember exactly
>>>>>> how
>>>>>> Parcels work for the standard case, either.
>>>>>> 
>>>>>> IMO, HTML Tables are really hard.  In some cases, I think you have to
>>>>>> compose cells multiple times in order to decide the cell widths and
>> row
>>>>>> heights.  If your use case can constrain the problem space it might be
>>>>>> easier to get something to work.
>>>>>> 
>>>>>> FWIW, I agree that it doesn't make sense for the main container's
>>>>>> ParcelList to know about parcels in the table.
>>>>>> 
>>>>>> Good luck,
>>>>>> -Alex
>>>>>> 
>>>>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
>>>>>> 
>>>>>>> Some more rambling:
>>>>>>> 
>>>>>>> The more I'm working through this, the more I'm convinced that the
>>>>>>> current implementation is fundamentally broken. The cell Parcels
>>>>>>> really
>>>>>>> can't be in the same ParcelList as the Containers. I'm pretty sure
>>>>>>> that
>>>>>>> not only multi-container text threads are broken, but multi-column
>>>>>>> containers are broken as well.
>>>>>>> 
>>>>>>> It seems to me that there needs to be a separate ParcelList for table
>>>>>>> cells that are separate from the container parcel list. Table parcels
>>>>>>> don't exactly fit into the concept of container parcels either
>> because
>>>>>>> they should be nested inside other parcels (which normal parcels are
>>>>>>> not). I think I should subclass Parcel as TableCellParcel which would
>>>>>>> have a parcel as a "parent". I'm also going to have to either modify
>>>>>>> ParcelList to track the cell parcels or subclass it for dealing with
>>>>>>> cell
>>>>>>> parcels.
>>>>>>> 
>>>>>>> Harbs
>>>>>>> 
>>>>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
>>>>>>> 
>>>>>>>> This is really difficult, because I'm not sure what is supposed to
>>>>>>>> work
>>>>>>>> in the current implementation. I'm trying to reverse engineer how
>>>>>>>> tables
>>>>>>>> work when they don't really work. Trying to sift out what I don't
>>>>>>>> understand from what simply doesn't work from what is poorly
>>>>>>>> implemented
>>>>>>>> is a huge pain.
>>>>>>>> 
>>>>>>>> I'm going to ramble a bit. I hope that things will become clearer to
>>>>>>>> me
>>>>>>>> as I ramble on... ;-)
>>>>>>>> 
>>>>>>>> If someone who understands how text flow in TLF is supposed to work
>>>>>>>> would either confirm or correct me, I'd appreciate it.
>>>>>>>> 
>>>>>>>> Here's how I understand the way TLF works with parcels:
>>>>>>>> 
>>>>>>>> Each composition has a ParcelList which contains one or more
>> parcels.
>>>>>>>> Each ContainerController has one or more parcels in the ParcelList.
>>>>>>>> Generally, there is one parcel per column. (If a ContainerController
>>>>>>>> has
>>>>>>>> more than one column, the composition of each column is done
>>>>>>>> separately
>>>>>>>> as a separate parcel.)
>>>>>>>> 
>>>>>>>> For normal text frames, this is all pretty straight-forward.
>>>>>>>> 
>>>>>>>> With tables things get a bit more muddled. Each table cell is in
>>>>>>>> effect
>>>>>>>> a separate composition area. If every composition area gets its own
>>>>>>>> parcel, I guess this would mean that every cell in the table would
>>>>>>>> get
>>>>>>>> its own parcel. If I'm reading the code correctly, it's supposed to
>>>>>>>> be
>>>>>>>> doing this. I think another way to look at it, would be to look at
>>>>>>>> each
>>>>>>>> column of each table within a specific Container as a separate
>>>>>>>> composition area (parcel) and position the text within that. I'm not
>>>>>>>> sure this makes any sense, though. The more I'm looking at how
>>>>>>>> parcels
>>>>>>>> work (i.e. vj, etc.), the less this makes sense.
>>>>>>>> 
>>>>>>>> So, basically, every cell in the table would be a separate parcel,
>>>>>>>> and
>>>>>>>> these parcels need to be organized into rows and columns. Keeping
>>>>>>>> track
>>>>>>>> of the columns and the placement of the rows has some level of
>>>>>>>> complexity. Adding header and footer rows to the mix should make it
>>>>>>>> more
>>>>>>>> interesting.
>>>>>>>> 
>>>>>>>> Here's what I'm not (yet) totally clear on (or even if it works
>>>>>>>> right):
>>>>>>>> 1) The logic of placing the table parcels relative to the container
>>>>>>>> parcels. The way I see it, the table parcels should be arranged
>>>>>>>> within
>>>>>>>> the bounds of the column parcels of the containing container(s).
>>>>>>>> 2) How the calculations of the parcel placement goes. This is
>>>>>>>> especially true for tables that might span more than one parent
>>>>>>>> parcel.
>>>>>>>> 3) The placement of the table parcels relative to the container
>>>>>>>> parcels
>>>>>>>> they are contained within. (Should there be a separate ParcelList
>> for
>>>>>>>> table parcels, or should it be part of the main ParcelList?)
>>>>>>>> 4) What I'm not clear on... ;-)
>>>>>>>> 
>>>>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>>>>>>>> 
>>>>>>>>> I'm back on this, and starting to make some (slow) progress.
>>>>>>>>> 
>>>>>>>>> I've started a Google Docs document to try to make some order out
>> of
>>>>>>>>> the chaos that is the current state of TLF Tables. This is just a
>>>>>>>>> place
>>>>>>>>> where I'm jotting down my findings as I go and my thoughts on
>>>>>>>>> direction
>>>>>>>>> as I work on this. I made the document publicly editable and would
>>>>>>>>> love
>>>>>>>>> input. If there's anyone out there that has answers to the
>> questions
>>>>>>>>> I'm posing, it would be very helpful!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>>>> 
>> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
>>>>>>>>> 0zDmSog/edit?usp=sharing
>>>>>>>>> 
>>>>>>>>> Harb
>>>>>>>>> 
>>>>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>>>>>>>>> 
>>>>>>>>>> My first tests are not very encouraging...
>>>>>>>>>> 
>>>>>>>>>> Trying to compose the table results in this function returning
>>>>>>>>>> null:
>>>>>>>>>>         static tlf_internal function
>>>>>> beginFactoryCompose():SimpleCompose
>>>>>>>>>>         {
>>>>>>>>>>                 var rslt:SimpleCompose = _factoryComposer;
>>>>>>>>>>                 _factoryComposer = peekFactoryCompose();
>>>>>>>>>>                 _savedFactoryComposer = null;
>>>>>>>>>>                 return rslt;
>>>>>>>>>>         }
>>>>>>>>>> 
>>>>>>>>>> Looks like I need to the composition process...
>>>>>>>>>> FWIW, it made no difference whether I added the rows to a
>>>>>>>>>> TableBodyElement or to the table directly.
>>>>>>>>>> 
>>>>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Harbs,
>>>>>>>>>>> 
>>>>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
>>>>>>>>>>> Or even
>>>>>>>>>>> complete, or even working at a prototype-level.
>>>>>>>>>>> 
>>>>>>>>>>> So good luck with it.  I might be able to ask folks who used to
>>>>>>>>>>> work
>>>>>>>>>>> on it
>>>>>>>>>>> a few questions, but I'm pretty sure their memories of it are
>>>>>>>>>>> pretty
>>>>>>>>>>> dim
>>>>>>>>>>> by now.
>>>>>>>>>>> 
>>>>>>>>>>> -Alex
>>>>>>>>>>> 
>>>>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I knew I was going to spend some real time on this one day, and
>>>>>>>>>>>> that time
>>>>>>>>>>>> is coming really soonŠ
>>>>>>>>>>>> 
>>>>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table
>>>>>>>>>>>> support?
>>>>>>>>>>>> I
>>>>>>>>>>>> know it's officially there, but I don't see any documentation on
>>>>>>>>>>>> it
>>>>>>>>>>>> --
>>>>>>>>>>>> not even the basics on how it's supposed to be used.
>>>>>>>>>>>> 
>>>>>>>>>>>> I fully expect to find bugs once I start really digging into it,
>>>>>>>>>>>> but some
>>>>>>>>>>>> documentation (any) would be nice to get me started.
>>>>>>>>>>>> 
>>>>>>>>>>>> Looking at the source code, I see the following classes:
>>>>>>>>>>>> 
>>>>>>>>>>>> TableElement
>>>>>>>>>>>> TableBodyElement
>>>>>>>>>>>> TableColElement
>>>>>>>>>>>> TableRowElement
>>>>>>>>>>>> TableColGroupElement
>>>>>>>>>>>> TableDataCellElement
>>>>>>>>>>>> TableFormattedElement
>>>>>>>>>>>> 
>>>>>>>>>>>> I understand the structure like this:
>>>>>>>>>>>> 
>>>>>>>>>>>> * A TableElement is the top level element for any table
>>>>>>>>>>>> * All elements in a table inherit from TableFormattedElement
>>>>>>>>>>>> * The bottom level of a table which needs to contain one or more
>>>>>>>>>>>> ParagraphElements in a TableDataCellElement
>>>>>>>>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>>>>>>>>> 
>>>>>>>>>>>> After this things get a bit fuzzier.
>>>>>>>>>>>> 
>>>>>>>>>>>> What is TableBodyElement used for?
>>>>>>>>>>>> How is TableColGroupElement and TableColElement used? (I assume
>>>>>>>>>>>> they are
>>>>>>>>>>>> used for formatting table columns, but the details are not very
>>>>>>>>>>>> clear to
>>>>>>>>>>>> me.)
>>>>>>>>>>>> What about header and footer rows? Is that supported yet?
>>>>>>>>>>>> Header and footer columns?
>>>>>>>>>>>> Is breaking tables across containers supported yet?
>>>>>>>>>>>> 
>>>>>>>>>>>> I have not started studying how to specify table formatting
>>>>>>>>>>>> either.
>>>>>>>>>>>> I'm
>>>>>>>>>>>> hoping that's obviousŠ
>>>>>>>>>>>> 
>>>>>>>>>>>> I'll try to add some documentation to the source code as things
>>>>>>>>>>>> become
>>>>>>>>>>>> clearer to meŠ
>>>>>>>>>>>> 
>>>>>>>>>>>> Harbs
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
>> 

RE: TLF Tables

[Maurice Amsellem <ma...@systar.com>]

On the other hand,  HTML has row-level styling / compositing.  
So it might be easier to work internally with rows/cells rather than cells directly.

IMO, not supporting vertically joined cells is acceptable.  

Maurice

-----Message d'origine-----
De : Avi Kessner [mailto:akessner@gmail.com] 
Envoyé : mercredi 4 décembre 2013 14:33
À : dev@flex.apache.org
Objet : Re: TLF Tables

I would vote for table/cells
I think it more accurately describes a table.
This way you could also more easily set the borders of cells like excell does.
IMO rows and columns don't actually exist,  they are just a coordinate system to locate a cell.
On Dec 4, 2013 2:42 PM, "Harbs" <ha...@gmail.com> wrote:

> There's one more issue I'm struggling with:
>
> The way the elements were implemented is that rows are nested inside 
> tables and cells are inside rows. Table columns are not directly 
> connected to cells -- they are really just there to compute the position.
>
> This makes sense in the way that the tables would normally be composed 
> (i.e. row by row).
>
> The only issue I can see with this, would be joined cells. If cells 
> are joined horizontally, it would not be to complicated since the row 
> would be composed across.
>
> Vertically joined cells would be much more complicated. Once cells are 
> joined vertically, a single cell would actually reside inside two 
> different rows. This does not jive very well with the concept of cells 
> belonging to a specific row. A better fit might be to make cells 
> children of the table and to have cells contain row and column info.
>
> It might be possible to compose joined cells even if they are children 
> of rows and use placeholder objects to indicate the joined cell 
> location within the row -- or maybe skip that area.
>
> I think I'm leaning towards sticking with tables/rows/cells rather 
> than tables/cells because I think it's neater for the classic tables, 
> but I'm not completely set on it.
>
> I'd like to hear if anyone has input on the subject…
>
> On Dec 2, 2013, at 9:08 PM, Alex Harui wrote:
>
> > OK, good luck.
> >
> > On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> The way it was implemented is like this:
> >>
> >> 1) Tables and table columns have fixed widths. (I might add a 
> >> default width if none was set to prevent runtime errors. What's a 
> >> reasonable
> >> number?)
> >> 2) Table cell parcels are created with a maximum height of 8000. 
> >> I'm not sure why they picked that number, but it's probably high 
> >> enough that
> it's
> >> fine. After the cell is composed, the height of the parcel is adjusted.
> >>
> >> This simplifies the calculations tremendously because tables can be 
> >> safely composed on a row-by-row basis. I think both of these 
> >> limitations are reasonable ones and it's pretty consistent with how 
> >> tables work in DTP apps. The only thing I'm probably going to 
> >> change is to add the option of a fixed height to the cell parcel 
> >> where the contents would
> just
> >> become overset if it does not fit.
> >>
> >> One thing I'm planning on changing is related to table widths.
> Currently,
> >> the width of a table is constrained by the with of the containing
> parcel.
> >> I think it's reasonable that tables can extend beyond the bounds of 
> >> the parent parcel. This is the way InDesign works and I think it's 
> >> necessary for tables that flow across multiple containers since the 
> >> width of the containers are not necessarily constant.
> >>
> >> Another limitation that I think is reasonable is no nested tables.
> >> InDesign for example allows unlimited levels of nesting tables 
> >> inside table cells. This adds a lot of complexity to the 
> >> composition, and it seems to me that this is an edge case. Does TLF 
> >> currently support nested text containers? (i.e. text containers as 
> >> inline graphics)
> >>
> >> I think I'm also going to not allow cells to split across 
> >> containers as this also adds complexity (and I personally have no 
> >> need for this support).
> >>
> >> Harbs
> >>
> >> On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
> >>
> >>> Just a random thought here, but what if you set the parcels at the 
> >>> end of
> >>> table creation?   Something like, populateParcels() which gets called
> >>> after
> >>> all cell sizes and positions are known, and then get placed into 
> >>> those rectangles?
> >>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>
> >>>> Harbs,
> >>>>
> >>>> I haven't looked at the Table code at all.  I don't remember 
> >>>> exactly how Parcels work for the standard case, either.
> >>>>
> >>>> IMO, HTML Tables are really hard.  In some cases, I think you 
> >>>> have to compose cells multiple times in order to decide the cell 
> >>>> widths and
> row
> >>>> heights.  If your use case can constrain the problem space it 
> >>>> might be easier to get something to work.
> >>>>
> >>>> FWIW, I agree that it doesn't make sense for the main container's 
> >>>> ParcelList to know about parcels in the table.
> >>>>
> >>>> Good luck,
> >>>> -Alex
> >>>>
> >>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
> >>>>
> >>>>> Some more rambling:
> >>>>>
> >>>>> The more I'm working through this, the more I'm convinced that 
> >>>>> the current implementation is fundamentally broken. The cell 
> >>>>> Parcels really can't be in the same ParcelList as the 
> >>>>> Containers. I'm pretty sure that not only multi-container text 
> >>>>> threads are broken, but multi-column containers are broken as 
> >>>>> well.
> >>>>>
> >>>>> It seems to me that there needs to be a separate ParcelList for 
> >>>>> table cells that are separate from the container parcel list. 
> >>>>> Table parcels don't exactly fit into the concept of container 
> >>>>> parcels either
> because
> >>>>> they should be nested inside other parcels (which normal parcels 
> >>>>> are not). I think I should subclass Parcel as TableCellParcel 
> >>>>> which would have a parcel as a "parent". I'm also going to have 
> >>>>> to either modify ParcelList to track the cell parcels or 
> >>>>> subclass it for dealing with cell parcels.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
> >>>>>
> >>>>>> This is really difficult, because I'm not sure what is supposed 
> >>>>>> to work in the current implementation. I'm trying to reverse 
> >>>>>> engineer how tables work when they don't really work. Trying to 
> >>>>>> sift out what I don't understand from what simply doesn't work 
> >>>>>> from what is poorly implemented is a huge pain.
> >>>>>>
> >>>>>> I'm going to ramble a bit. I hope that things will become 
> >>>>>> clearer to me as I ramble on... ;-)
> >>>>>>
> >>>>>> If someone who understands how text flow in TLF is supposed to 
> >>>>>> work would either confirm or correct me, I'd appreciate it.
> >>>>>>
> >>>>>> Here's how I understand the way TLF works with parcels:
> >>>>>>
> >>>>>> Each composition has a ParcelList which contains one or more
> parcels.
> >>>>>> Each ContainerController has one or more parcels in the ParcelList.
> >>>>>> Generally, there is one parcel per column. (If a 
> >>>>>> ContainerController has more than one column, the composition 
> >>>>>> of each column is done separately as a separate parcel.)
> >>>>>>
> >>>>>> For normal text frames, this is all pretty straight-forward.
> >>>>>>
> >>>>>> With tables things get a bit more muddled. Each table cell is 
> >>>>>> in effect a separate composition area. If every composition 
> >>>>>> area gets its own parcel, I guess this would mean that every 
> >>>>>> cell in the table would get its own parcel. If I'm reading the 
> >>>>>> code correctly, it's supposed to be doing this. I think another 
> >>>>>> way to look at it, would be to look at each column of each 
> >>>>>> table within a specific Container as a separate composition 
> >>>>>> area (parcel) and position the text within that. I'm not sure 
> >>>>>> this makes any sense, though. The more I'm looking at how 
> >>>>>> parcels work (i.e. vj, etc.), the less this makes sense.
> >>>>>>
> >>>>>> So, basically, every cell in the table would be a separate 
> >>>>>> parcel, and these parcels need to be organized into rows and 
> >>>>>> columns. Keeping track of the columns and the placement of the 
> >>>>>> rows has some level of complexity. Adding header and footer 
> >>>>>> rows to the mix should make it more interesting.
> >>>>>>
> >>>>>> Here's what I'm not (yet) totally clear on (or even if it works
> >>>>>> right):
> >>>>>> 1) The logic of placing the table parcels relative to the 
> >>>>>> container parcels. The way I see it, the table parcels should 
> >>>>>> be arranged within the bounds of the column parcels of the 
> >>>>>> containing container(s).
> >>>>>> 2) How the calculations of the parcel placement goes. This is 
> >>>>>> especially true for tables that might span more than one parent 
> >>>>>> parcel.
> >>>>>> 3) The placement of the table parcels relative to the container 
> >>>>>> parcels they are contained within. (Should there be a separate 
> >>>>>> ParcelList
> for
> >>>>>> table parcels, or should it be part of the main ParcelList?)
> >>>>>> 4) What I'm not clear on... ;-)
> >>>>>>
> >>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
> >>>>>>
> >>>>>>> I'm back on this, and starting to make some (slow) progress.
> >>>>>>>
> >>>>>>> I've started a Google Docs document to try to make some order 
> >>>>>>> out
> of
> >>>>>>> the chaos that is the current state of TLF Tables. This is 
> >>>>>>> just a place where I'm jotting down my findings as I go and my 
> >>>>>>> thoughts on direction as I work on this. I made the document 
> >>>>>>> publicly editable and would love input. If there's anyone out 
> >>>>>>> there that has answers to the
> questions
> >>>>>>> I'm posing, it would be very helpful!
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQ
> oj
> >>>>>>> 0zDmSog/edit?usp=sharing
> >>>>>>>
> >>>>>>> Harb
> >>>>>>>
> >>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
> >>>>>>>
> >>>>>>>> My first tests are not very encouraging...
> >>>>>>>>
> >>>>>>>> Trying to compose the table results in this function 
> >>>>>>>> returning
> >>>>>>>> null:
> >>>>>>>>          static tlf_internal function
> >>>> beginFactoryCompose():SimpleCompose
> >>>>>>>>          {
> >>>>>>>>                  var rslt:SimpleCompose = _factoryComposer;
> >>>>>>>>                  _factoryComposer = peekFactoryCompose();
> >>>>>>>>                  _savedFactoryComposer = null;
> >>>>>>>>                  return rslt;
> >>>>>>>>          }
> >>>>>>>>
> >>>>>>>> Looks like I need to the composition process...
> >>>>>>>> FWIW, it made no difference whether I added the rows to a 
> >>>>>>>> TableBodyElement or to the table directly.
> >>>>>>>>
> >>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
> >>>>>>>>
> >>>>>>>>> Hi Harbs,
> >>>>>>>>>
> >>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
> >>>>>>>>> Or even
> >>>>>>>>> complete, or even working at a prototype-level.
> >>>>>>>>>
> >>>>>>>>> So good luck with it.  I might be able to ask folks who used 
> >>>>>>>>> to work on it a few questions, but I'm pretty sure their 
> >>>>>>>>> memories of it are pretty dim by now.
> >>>>>>>>>
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> I knew I was going to spend some real time on this one day, 
> >>>>>>>>>> and that time is coming really soonŠ
> >>>>>>>>>>
> >>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table 
> >>>>>>>>>> support?
> >>>>>>>>>> I
> >>>>>>>>>> know it's officially there, but I don't see any 
> >>>>>>>>>> documentation on it
> >>>>>>>>>> --
> >>>>>>>>>> not even the basics on how it's supposed to be used.
> >>>>>>>>>>
> >>>>>>>>>> I fully expect to find bugs once I start really digging 
> >>>>>>>>>> into it, but some documentation (any) would be nice to get 
> >>>>>>>>>> me started.
> >>>>>>>>>>
> >>>>>>>>>> Looking at the source code, I see the following classes:
> >>>>>>>>>>
> >>>>>>>>>> TableElement
> >>>>>>>>>> TableBodyElement
> >>>>>>>>>> TableColElement
> >>>>>>>>>> TableRowElement
> >>>>>>>>>> TableColGroupElement
> >>>>>>>>>> TableDataCellElement
> >>>>>>>>>> TableFormattedElement
> >>>>>>>>>>
> >>>>>>>>>> I understand the structure like this:
> >>>>>>>>>>
> >>>>>>>>>> * A TableElement is the top level element for any table
> >>>>>>>>>> * All elements in a table inherit from 
> >>>>>>>>>> TableFormattedElement
> >>>>>>>>>> * The bottom level of a table which needs to contain one or 
> >>>>>>>>>> more ParagraphElements in a TableDataCellElement
> >>>>>>>>>> * TableDataCellElements must reside within a 
> >>>>>>>>>> TableRowElement
> >>>>>>>>>>
> >>>>>>>>>> After this things get a bit fuzzier.
> >>>>>>>>>>
> >>>>>>>>>> What is TableBodyElement used for?
> >>>>>>>>>> How is TableColGroupElement and TableColElement used? (I 
> >>>>>>>>>> assume they are used for formatting table columns, but the 
> >>>>>>>>>> details are not very clear to
> >>>>>>>>>> me.)
> >>>>>>>>>> What about header and footer rows? Is that supported yet?
> >>>>>>>>>> Header and footer columns?
> >>>>>>>>>> Is breaking tables across containers supported yet?
> >>>>>>>>>>
> >>>>>>>>>> I have not started studying how to specify table formatting 
> >>>>>>>>>> either.
> >>>>>>>>>> I'm
> >>>>>>>>>> hoping that's obviousŠ
> >>>>>>>>>>
> >>>>>>>>>> I'll try to add some documentation to the source code as 
> >>>>>>>>>> things become clearer to meŠ
> >>>>>>>>>>
> >>>>>>>>>> Harbs
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>

RE: TLF Tables

[Maurice Amsellem <ma...@systar.com>]

Joined cells also exist in HTML ( colspan and rowspan).
Can you check how it is implemented in open-source HTML renderers ?
Maybe that would help...

Maurice 

-----Message d'origine-----
De : Avi Kessner [mailto:akessner@gmail.com] 
Envoyé : mercredi 4 décembre 2013 14:33
À : dev@flex.apache.org
Objet : Re: TLF Tables

I would vote for table/cells
I think it more accurately describes a table.
This way you could also more easily set the borders of cells like excell does.
IMO rows and columns don't actually exist,  they are just a coordinate system to locate a cell.
On Dec 4, 2013 2:42 PM, "Harbs" <ha...@gmail.com> wrote:

> There's one more issue I'm struggling with:
>
> The way the elements were implemented is that rows are nested inside 
> tables and cells are inside rows. Table columns are not directly 
> connected to cells -- they are really just there to compute the position.
>
> This makes sense in the way that the tables would normally be composed 
> (i.e. row by row).
>
> The only issue I can see with this, would be joined cells. If cells 
> are joined horizontally, it would not be to complicated since the row 
> would be composed across.
>
> Vertically joined cells would be much more complicated. Once cells are 
> joined vertically, a single cell would actually reside inside two 
> different rows. This does not jive very well with the concept of cells 
> belonging to a specific row. A better fit might be to make cells 
> children of the table and to have cells contain row and column info.
>
> It might be possible to compose joined cells even if they are children 
> of rows and use placeholder objects to indicate the joined cell 
> location within the row -- or maybe skip that area.
>
> I think I'm leaning towards sticking with tables/rows/cells rather 
> than tables/cells because I think it's neater for the classic tables, 
> but I'm not completely set on it.
>
> I'd like to hear if anyone has input on the subject…
>
> On Dec 2, 2013, at 9:08 PM, Alex Harui wrote:
>
> > OK, good luck.
> >
> > On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> The way it was implemented is like this:
> >>
> >> 1) Tables and table columns have fixed widths. (I might add a 
> >> default width if none was set to prevent runtime errors. What's a 
> >> reasonable
> >> number?)
> >> 2) Table cell parcels are created with a maximum height of 8000. 
> >> I'm not sure why they picked that number, but it's probably high 
> >> enough that
> it's
> >> fine. After the cell is composed, the height of the parcel is adjusted.
> >>
> >> This simplifies the calculations tremendously because tables can be 
> >> safely composed on a row-by-row basis. I think both of these 
> >> limitations are reasonable ones and it's pretty consistent with how 
> >> tables work in DTP apps. The only thing I'm probably going to 
> >> change is to add the option of a fixed height to the cell parcel 
> >> where the contents would
> just
> >> become overset if it does not fit.
> >>
> >> One thing I'm planning on changing is related to table widths.
> Currently,
> >> the width of a table is constrained by the with of the containing
> parcel.
> >> I think it's reasonable that tables can extend beyond the bounds of 
> >> the parent parcel. This is the way InDesign works and I think it's 
> >> necessary for tables that flow across multiple containers since the 
> >> width of the containers are not necessarily constant.
> >>
> >> Another limitation that I think is reasonable is no nested tables.
> >> InDesign for example allows unlimited levels of nesting tables 
> >> inside table cells. This adds a lot of complexity to the 
> >> composition, and it seems to me that this is an edge case. Does TLF 
> >> currently support nested text containers? (i.e. text containers as 
> >> inline graphics)
> >>
> >> I think I'm also going to not allow cells to split across 
> >> containers as this also adds complexity (and I personally have no 
> >> need for this support).
> >>
> >> Harbs
> >>
> >> On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
> >>
> >>> Just a random thought here, but what if you set the parcels at the 
> >>> end of
> >>> table creation?   Something like, populateParcels() which gets called
> >>> after
> >>> all cell sizes and positions are known, and then get placed into 
> >>> those rectangles?
> >>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>
> >>>> Harbs,
> >>>>
> >>>> I haven't looked at the Table code at all.  I don't remember 
> >>>> exactly how Parcels work for the standard case, either.
> >>>>
> >>>> IMO, HTML Tables are really hard.  In some cases, I think you 
> >>>> have to compose cells multiple times in order to decide the cell 
> >>>> widths and
> row
> >>>> heights.  If your use case can constrain the problem space it 
> >>>> might be easier to get something to work.
> >>>>
> >>>> FWIW, I agree that it doesn't make sense for the main container's 
> >>>> ParcelList to know about parcels in the table.
> >>>>
> >>>> Good luck,
> >>>> -Alex
> >>>>
> >>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
> >>>>
> >>>>> Some more rambling:
> >>>>>
> >>>>> The more I'm working through this, the more I'm convinced that 
> >>>>> the current implementation is fundamentally broken. The cell 
> >>>>> Parcels really can't be in the same ParcelList as the 
> >>>>> Containers. I'm pretty sure that not only multi-container text 
> >>>>> threads are broken, but multi-column containers are broken as 
> >>>>> well.
> >>>>>
> >>>>> It seems to me that there needs to be a separate ParcelList for 
> >>>>> table cells that are separate from the container parcel list. 
> >>>>> Table parcels don't exactly fit into the concept of container 
> >>>>> parcels either
> because
> >>>>> they should be nested inside other parcels (which normal parcels 
> >>>>> are not). I think I should subclass Parcel as TableCellParcel 
> >>>>> which would have a parcel as a "parent". I'm also going to have 
> >>>>> to either modify ParcelList to track the cell parcels or 
> >>>>> subclass it for dealing with cell parcels.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
> >>>>>
> >>>>>> This is really difficult, because I'm not sure what is supposed 
> >>>>>> to work in the current implementation. I'm trying to reverse 
> >>>>>> engineer how tables work when they don't really work. Trying to 
> >>>>>> sift out what I don't understand from what simply doesn't work 
> >>>>>> from what is poorly implemented is a huge pain.
> >>>>>>
> >>>>>> I'm going to ramble a bit. I hope that things will become 
> >>>>>> clearer to me as I ramble on... ;-)
> >>>>>>
> >>>>>> If someone who understands how text flow in TLF is supposed to 
> >>>>>> work would either confirm or correct me, I'd appreciate it.
> >>>>>>
> >>>>>> Here's how I understand the way TLF works with parcels:
> >>>>>>
> >>>>>> Each composition has a ParcelList which contains one or more
> parcels.
> >>>>>> Each ContainerController has one or more parcels in the ParcelList.
> >>>>>> Generally, there is one parcel per column. (If a 
> >>>>>> ContainerController has more than one column, the composition 
> >>>>>> of each column is done separately as a separate parcel.)
> >>>>>>
> >>>>>> For normal text frames, this is all pretty straight-forward.
> >>>>>>
> >>>>>> With tables things get a bit more muddled. Each table cell is 
> >>>>>> in effect a separate composition area. If every composition 
> >>>>>> area gets its own parcel, I guess this would mean that every 
> >>>>>> cell in the table would get its own parcel. If I'm reading the 
> >>>>>> code correctly, it's supposed to be doing this. I think another 
> >>>>>> way to look at it, would be to look at each column of each 
> >>>>>> table within a specific Container as a separate composition 
> >>>>>> area (parcel) and position the text within that. I'm not sure 
> >>>>>> this makes any sense, though. The more I'm looking at how 
> >>>>>> parcels work (i.e. vj, etc.), the less this makes sense.
> >>>>>>
> >>>>>> So, basically, every cell in the table would be a separate 
> >>>>>> parcel, and these parcels need to be organized into rows and 
> >>>>>> columns. Keeping track of the columns and the placement of the 
> >>>>>> rows has some level of complexity. Adding header and footer 
> >>>>>> rows to the mix should make it more interesting.
> >>>>>>
> >>>>>> Here's what I'm not (yet) totally clear on (or even if it works
> >>>>>> right):
> >>>>>> 1) The logic of placing the table parcels relative to the 
> >>>>>> container parcels. The way I see it, the table parcels should 
> >>>>>> be arranged within the bounds of the column parcels of the 
> >>>>>> containing container(s).
> >>>>>> 2) How the calculations of the parcel placement goes. This is 
> >>>>>> especially true for tables that might span more than one parent 
> >>>>>> parcel.
> >>>>>> 3) The placement of the table parcels relative to the container 
> >>>>>> parcels they are contained within. (Should there be a separate 
> >>>>>> ParcelList
> for
> >>>>>> table parcels, or should it be part of the main ParcelList?)
> >>>>>> 4) What I'm not clear on... ;-)
> >>>>>>
> >>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
> >>>>>>
> >>>>>>> I'm back on this, and starting to make some (slow) progress.
> >>>>>>>
> >>>>>>> I've started a Google Docs document to try to make some order 
> >>>>>>> out
> of
> >>>>>>> the chaos that is the current state of TLF Tables. This is 
> >>>>>>> just a place where I'm jotting down my findings as I go and my 
> >>>>>>> thoughts on direction as I work on this. I made the document 
> >>>>>>> publicly editable and would love input. If there's anyone out 
> >>>>>>> there that has answers to the
> questions
> >>>>>>> I'm posing, it would be very helpful!
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQ
> oj
> >>>>>>> 0zDmSog/edit?usp=sharing
> >>>>>>>
> >>>>>>> Harb
> >>>>>>>
> >>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
> >>>>>>>
> >>>>>>>> My first tests are not very encouraging...
> >>>>>>>>
> >>>>>>>> Trying to compose the table results in this function 
> >>>>>>>> returning
> >>>>>>>> null:
> >>>>>>>>          static tlf_internal function
> >>>> beginFactoryCompose():SimpleCompose
> >>>>>>>>          {
> >>>>>>>>                  var rslt:SimpleCompose = _factoryComposer;
> >>>>>>>>                  _factoryComposer = peekFactoryCompose();
> >>>>>>>>                  _savedFactoryComposer = null;
> >>>>>>>>                  return rslt;
> >>>>>>>>          }
> >>>>>>>>
> >>>>>>>> Looks like I need to the composition process...
> >>>>>>>> FWIW, it made no difference whether I added the rows to a 
> >>>>>>>> TableBodyElement or to the table directly.
> >>>>>>>>
> >>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
> >>>>>>>>
> >>>>>>>>> Hi Harbs,
> >>>>>>>>>
> >>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
> >>>>>>>>> Or even
> >>>>>>>>> complete, or even working at a prototype-level.
> >>>>>>>>>
> >>>>>>>>> So good luck with it.  I might be able to ask folks who used 
> >>>>>>>>> to work on it a few questions, but I'm pretty sure their 
> >>>>>>>>> memories of it are pretty dim by now.
> >>>>>>>>>
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> I knew I was going to spend some real time on this one day, 
> >>>>>>>>>> and that time is coming really soonŠ
> >>>>>>>>>>
> >>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table 
> >>>>>>>>>> support?
> >>>>>>>>>> I
> >>>>>>>>>> know it's officially there, but I don't see any 
> >>>>>>>>>> documentation on it
> >>>>>>>>>> --
> >>>>>>>>>> not even the basics on how it's supposed to be used.
> >>>>>>>>>>
> >>>>>>>>>> I fully expect to find bugs once I start really digging 
> >>>>>>>>>> into it, but some documentation (any) would be nice to get 
> >>>>>>>>>> me started.
> >>>>>>>>>>
> >>>>>>>>>> Looking at the source code, I see the following classes:
> >>>>>>>>>>
> >>>>>>>>>> TableElement
> >>>>>>>>>> TableBodyElement
> >>>>>>>>>> TableColElement
> >>>>>>>>>> TableRowElement
> >>>>>>>>>> TableColGroupElement
> >>>>>>>>>> TableDataCellElement
> >>>>>>>>>> TableFormattedElement
> >>>>>>>>>>
> >>>>>>>>>> I understand the structure like this:
> >>>>>>>>>>
> >>>>>>>>>> * A TableElement is the top level element for any table
> >>>>>>>>>> * All elements in a table inherit from 
> >>>>>>>>>> TableFormattedElement
> >>>>>>>>>> * The bottom level of a table which needs to contain one or 
> >>>>>>>>>> more ParagraphElements in a TableDataCellElement
> >>>>>>>>>> * TableDataCellElements must reside within a 
> >>>>>>>>>> TableRowElement
> >>>>>>>>>>
> >>>>>>>>>> After this things get a bit fuzzier.
> >>>>>>>>>>
> >>>>>>>>>> What is TableBodyElement used for?
> >>>>>>>>>> How is TableColGroupElement and TableColElement used? (I 
> >>>>>>>>>> assume they are used for formatting table columns, but the 
> >>>>>>>>>> details are not very clear to
> >>>>>>>>>> me.)
> >>>>>>>>>> What about header and footer rows? Is that supported yet?
> >>>>>>>>>> Header and footer columns?
> >>>>>>>>>> Is breaking tables across containers supported yet?
> >>>>>>>>>>
> >>>>>>>>>> I have not started studying how to specify table formatting 
> >>>>>>>>>> either.
> >>>>>>>>>> I'm
> >>>>>>>>>> hoping that's obviousŠ
> >>>>>>>>>>
> >>>>>>>>>> I'll try to add some documentation to the source code as 
> >>>>>>>>>> things become clearer to meŠ
> >>>>>>>>>>
> >>>>>>>>>> Harbs
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>

Re: TLF Tables

[Avi Kessner <ak...@gmail.com>]

I would vote for table/cells
I think it more accurately describes a table.
This way you could also more easily set the borders of cells like excell
does.
IMO rows and columns don't actually exist,  they are just a coordinate
system to locate a cell.
On Dec 4, 2013 2:42 PM, "Harbs" <ha...@gmail.com> wrote:

> There's one more issue I'm struggling with:
>
> The way the elements were implemented is that rows are nested inside
> tables and cells are inside rows. Table columns are not directly connected
> to cells -- they are really just there to compute the position.
>
> This makes sense in the way that the tables would normally be composed
> (i.e. row by row).
>
> The only issue I can see with this, would be joined cells. If cells are
> joined horizontally, it would not be to complicated since the row would be
> composed across.
>
> Vertically joined cells would be much more complicated. Once cells are
> joined vertically, a single cell would actually reside inside two different
> rows. This does not jive very well with the concept of cells belonging to a
> specific row. A better fit might be to make cells children of the table and
> to have cells contain row and column info.
>
> It might be possible to compose joined cells even if they are children of
> rows and use placeholder objects to indicate the joined cell location
> within the row -- or maybe skip that area.
>
> I think I'm leaning towards sticking with tables/rows/cells rather than
> tables/cells because I think it's neater for the classic tables, but I'm
> not completely set on it.
>
> I'd like to hear if anyone has input on the subject…
>
> On Dec 2, 2013, at 9:08 PM, Alex Harui wrote:
>
> > OK, good luck.
> >
> > On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> The way it was implemented is like this:
> >>
> >> 1) Tables and table columns have fixed widths. (I might add a default
> >> width if none was set to prevent runtime errors. What's a reasonable
> >> number?)
> >> 2) Table cell parcels are created with a maximum height of 8000. I'm not
> >> sure why they picked that number, but it's probably high enough that
> it's
> >> fine. After the cell is composed, the height of the parcel is adjusted.
> >>
> >> This simplifies the calculations tremendously because tables can be
> >> safely composed on a row-by-row basis. I think both of these limitations
> >> are reasonable ones and it's pretty consistent with how tables work in
> >> DTP apps. The only thing I'm probably going to change is to add the
> >> option of a fixed height to the cell parcel where the contents would
> just
> >> become overset if it does not fit.
> >>
> >> One thing I'm planning on changing is related to table widths.
> Currently,
> >> the width of a table is constrained by the with of the containing
> parcel.
> >> I think it's reasonable that tables can extend beyond the bounds of the
> >> parent parcel. This is the way InDesign works and I think it's necessary
> >> for tables that flow across multiple containers since the width of the
> >> containers are not necessarily constant.
> >>
> >> Another limitation that I think is reasonable is no nested tables.
> >> InDesign for example allows unlimited levels of nesting tables inside
> >> table cells. This adds a lot of complexity to the composition, and it
> >> seems to me that this is an edge case. Does TLF currently support nested
> >> text containers? (i.e. text containers as inline graphics)
> >>
> >> I think I'm also going to not allow cells to split across containers as
> >> this also adds complexity (and I personally have no need for this
> >> support).
> >>
> >> Harbs
> >>
> >> On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
> >>
> >>> Just a random thought here, but what if you set the parcels at the end
> >>> of
> >>> table creation?   Something like, populateParcels() which gets called
> >>> after
> >>> all cell sizes and positions are known, and then get placed into those
> >>> rectangles?
> >>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>
> >>>> Harbs,
> >>>>
> >>>> I haven't looked at the Table code at all.  I don't remember exactly
> >>>> how
> >>>> Parcels work for the standard case, either.
> >>>>
> >>>> IMO, HTML Tables are really hard.  In some cases, I think you have to
> >>>> compose cells multiple times in order to decide the cell widths and
> row
> >>>> heights.  If your use case can constrain the problem space it might be
> >>>> easier to get something to work.
> >>>>
> >>>> FWIW, I agree that it doesn't make sense for the main container's
> >>>> ParcelList to know about parcels in the table.
> >>>>
> >>>> Good luck,
> >>>> -Alex
> >>>>
> >>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
> >>>>
> >>>>> Some more rambling:
> >>>>>
> >>>>> The more I'm working through this, the more I'm convinced that the
> >>>>> current implementation is fundamentally broken. The cell Parcels
> >>>>> really
> >>>>> can't be in the same ParcelList as the Containers. I'm pretty sure
> >>>>> that
> >>>>> not only multi-container text threads are broken, but multi-column
> >>>>> containers are broken as well.
> >>>>>
> >>>>> It seems to me that there needs to be a separate ParcelList for table
> >>>>> cells that are separate from the container parcel list. Table parcels
> >>>>> don't exactly fit into the concept of container parcels either
> because
> >>>>> they should be nested inside other parcels (which normal parcels are
> >>>>> not). I think I should subclass Parcel as TableCellParcel which would
> >>>>> have a parcel as a "parent". I'm also going to have to either modify
> >>>>> ParcelList to track the cell parcels or subclass it for dealing with
> >>>>> cell
> >>>>> parcels.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
> >>>>>
> >>>>>> This is really difficult, because I'm not sure what is supposed to
> >>>>>> work
> >>>>>> in the current implementation. I'm trying to reverse engineer how
> >>>>>> tables
> >>>>>> work when they don't really work. Trying to sift out what I don't
> >>>>>> understand from what simply doesn't work from what is poorly
> >>>>>> implemented
> >>>>>> is a huge pain.
> >>>>>>
> >>>>>> I'm going to ramble a bit. I hope that things will become clearer to
> >>>>>> me
> >>>>>> as I ramble on... ;-)
> >>>>>>
> >>>>>> If someone who understands how text flow in TLF is supposed to work
> >>>>>> would either confirm or correct me, I'd appreciate it.
> >>>>>>
> >>>>>> Here's how I understand the way TLF works with parcels:
> >>>>>>
> >>>>>> Each composition has a ParcelList which contains one or more
> parcels.
> >>>>>> Each ContainerController has one or more parcels in the ParcelList.
> >>>>>> Generally, there is one parcel per column. (If a ContainerController
> >>>>>> has
> >>>>>> more than one column, the composition of each column is done
> >>>>>> separately
> >>>>>> as a separate parcel.)
> >>>>>>
> >>>>>> For normal text frames, this is all pretty straight-forward.
> >>>>>>
> >>>>>> With tables things get a bit more muddled. Each table cell is in
> >>>>>> effect
> >>>>>> a separate composition area. If every composition area gets its own
> >>>>>> parcel, I guess this would mean that every cell in the table would
> >>>>>> get
> >>>>>> its own parcel. If I'm reading the code correctly, it's supposed to
> >>>>>> be
> >>>>>> doing this. I think another way to look at it, would be to look at
> >>>>>> each
> >>>>>> column of each table within a specific Container as a separate
> >>>>>> composition area (parcel) and position the text within that. I'm not
> >>>>>> sure this makes any sense, though. The more I'm looking at how
> >>>>>> parcels
> >>>>>> work (i.e. vj, etc.), the less this makes sense.
> >>>>>>
> >>>>>> So, basically, every cell in the table would be a separate parcel,
> >>>>>> and
> >>>>>> these parcels need to be organized into rows and columns. Keeping
> >>>>>> track
> >>>>>> of the columns and the placement of the rows has some level of
> >>>>>> complexity. Adding header and footer rows to the mix should make it
> >>>>>> more
> >>>>>> interesting.
> >>>>>>
> >>>>>> Here's what I'm not (yet) totally clear on (or even if it works
> >>>>>> right):
> >>>>>> 1) The logic of placing the table parcels relative to the container
> >>>>>> parcels. The way I see it, the table parcels should be arranged
> >>>>>> within
> >>>>>> the bounds of the column parcels of the containing container(s).
> >>>>>> 2) How the calculations of the parcel placement goes. This is
> >>>>>> especially true for tables that might span more than one parent
> >>>>>> parcel.
> >>>>>> 3) The placement of the table parcels relative to the container
> >>>>>> parcels
> >>>>>> they are contained within. (Should there be a separate ParcelList
> for
> >>>>>> table parcels, or should it be part of the main ParcelList?)
> >>>>>> 4) What I'm not clear on... ;-)
> >>>>>>
> >>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
> >>>>>>
> >>>>>>> I'm back on this, and starting to make some (slow) progress.
> >>>>>>>
> >>>>>>> I've started a Google Docs document to try to make some order out
> of
> >>>>>>> the chaos that is the current state of TLF Tables. This is just a
> >>>>>>> place
> >>>>>>> where I'm jotting down my findings as I go and my thoughts on
> >>>>>>> direction
> >>>>>>> as I work on this. I made the document publicly editable and would
> >>>>>>> love
> >>>>>>> input. If there's anyone out there that has answers to the
> questions
> >>>>>>> I'm posing, it would be very helpful!
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
> >>>>>>> 0zDmSog/edit?usp=sharing
> >>>>>>>
> >>>>>>> Harb
> >>>>>>>
> >>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
> >>>>>>>
> >>>>>>>> My first tests are not very encouraging...
> >>>>>>>>
> >>>>>>>> Trying to compose the table results in this function returning
> >>>>>>>> null:
> >>>>>>>>          static tlf_internal function
> >>>> beginFactoryCompose():SimpleCompose
> >>>>>>>>          {
> >>>>>>>>                  var rslt:SimpleCompose = _factoryComposer;
> >>>>>>>>                  _factoryComposer = peekFactoryCompose();
> >>>>>>>>                  _savedFactoryComposer = null;
> >>>>>>>>                  return rslt;
> >>>>>>>>          }
> >>>>>>>>
> >>>>>>>> Looks like I need to the composition process...
> >>>>>>>> FWIW, it made no difference whether I added the rows to a
> >>>>>>>> TableBodyElement or to the table directly.
> >>>>>>>>
> >>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
> >>>>>>>>
> >>>>>>>>> Hi Harbs,
> >>>>>>>>>
> >>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
> >>>>>>>>> Or even
> >>>>>>>>> complete, or even working at a prototype-level.
> >>>>>>>>>
> >>>>>>>>> So good luck with it.  I might be able to ask folks who used to
> >>>>>>>>> work
> >>>>>>>>> on it
> >>>>>>>>> a few questions, but I'm pretty sure their memories of it are
> >>>>>>>>> pretty
> >>>>>>>>> dim
> >>>>>>>>> by now.
> >>>>>>>>>
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> I knew I was going to spend some real time on this one day, and
> >>>>>>>>>> that time
> >>>>>>>>>> is coming really soonŠ
> >>>>>>>>>>
> >>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table
> >>>>>>>>>> support?
> >>>>>>>>>> I
> >>>>>>>>>> know it's officially there, but I don't see any documentation on
> >>>>>>>>>> it
> >>>>>>>>>> --
> >>>>>>>>>> not even the basics on how it's supposed to be used.
> >>>>>>>>>>
> >>>>>>>>>> I fully expect to find bugs once I start really digging into it,
> >>>>>>>>>> but some
> >>>>>>>>>> documentation (any) would be nice to get me started.
> >>>>>>>>>>
> >>>>>>>>>> Looking at the source code, I see the following classes:
> >>>>>>>>>>
> >>>>>>>>>> TableElement
> >>>>>>>>>> TableBodyElement
> >>>>>>>>>> TableColElement
> >>>>>>>>>> TableRowElement
> >>>>>>>>>> TableColGroupElement
> >>>>>>>>>> TableDataCellElement
> >>>>>>>>>> TableFormattedElement
> >>>>>>>>>>
> >>>>>>>>>> I understand the structure like this:
> >>>>>>>>>>
> >>>>>>>>>> * A TableElement is the top level element for any table
> >>>>>>>>>> * All elements in a table inherit from TableFormattedElement
> >>>>>>>>>> * The bottom level of a table which needs to contain one or more
> >>>>>>>>>> ParagraphElements in a TableDataCellElement
> >>>>>>>>>> * TableDataCellElements must reside within a TableRowElement
> >>>>>>>>>>
> >>>>>>>>>> After this things get a bit fuzzier.
> >>>>>>>>>>
> >>>>>>>>>> What is TableBodyElement used for?
> >>>>>>>>>> How is TableColGroupElement and TableColElement used? (I assume
> >>>>>>>>>> they are
> >>>>>>>>>> used for formatting table columns, but the details are not very
> >>>>>>>>>> clear to
> >>>>>>>>>> me.)
> >>>>>>>>>> What about header and footer rows? Is that supported yet?
> >>>>>>>>>> Header and footer columns?
> >>>>>>>>>> Is breaking tables across containers supported yet?
> >>>>>>>>>>
> >>>>>>>>>> I have not started studying how to specify table formatting
> >>>>>>>>>> either.
> >>>>>>>>>> I'm
> >>>>>>>>>> hoping that's obviousŠ
> >>>>>>>>>>
> >>>>>>>>>> I'll try to add some documentation to the source code as things
> >>>>>>>>>> become
> >>>>>>>>>> clearer to meŠ
> >>>>>>>>>>
> >>>>>>>>>> Harbs
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>

Re: TLF Tables

[Harbs <ha...@gmail.com>]

There's one more issue I'm struggling with:

The way the elements were implemented is that rows are nested inside tables and cells are inside rows. Table columns are not directly connected to cells -- they are really just there to compute the position.

This makes sense in the way that the tables would normally be composed (i.e. row by row).

The only issue I can see with this, would be joined cells. If cells are joined horizontally, it would not be to complicated since the row would be composed across.

Vertically joined cells would be much more complicated. Once cells are joined vertically, a single cell would actually reside inside two different rows. This does not jive very well with the concept of cells belonging to a specific row. A better fit might be to make cells children of the table and to have cells contain row and column info.

It might be possible to compose joined cells even if they are children of rows and use placeholder objects to indicate the joined cell location within the row -- or maybe skip that area.

I think I'm leaning towards sticking with tables/rows/cells rather than tables/cells because I think it's neater for the classic tables, but I'm not completely set on it.

I'd like to hear if anyone has input on the subject…

On Dec 2, 2013, at 9:08 PM, Alex Harui wrote:

> OK, good luck.
> 
> On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> The way it was implemented is like this:
>> 
>> 1) Tables and table columns have fixed widths. (I might add a default
>> width if none was set to prevent runtime errors. What's a reasonable
>> number?)
>> 2) Table cell parcels are created with a maximum height of 8000. I'm not
>> sure why they picked that number, but it's probably high enough that it's
>> fine. After the cell is composed, the height of the parcel is adjusted.
>> 
>> This simplifies the calculations tremendously because tables can be
>> safely composed on a row-by-row basis. I think both of these limitations
>> are reasonable ones and it's pretty consistent with how tables work in
>> DTP apps. The only thing I'm probably going to change is to add the
>> option of a fixed height to the cell parcel where the contents would just
>> become overset if it does not fit.
>> 
>> One thing I'm planning on changing is related to table widths. Currently,
>> the width of a table is constrained by the with of the containing parcel.
>> I think it's reasonable that tables can extend beyond the bounds of the
>> parent parcel. This is the way InDesign works and I think it's necessary
>> for tables that flow across multiple containers since the width of the
>> containers are not necessarily constant.
>> 
>> Another limitation that I think is reasonable is no nested tables.
>> InDesign for example allows unlimited levels of nesting tables inside
>> table cells. This adds a lot of complexity to the composition, and it
>> seems to me that this is an edge case. Does TLF currently support nested
>> text containers? (i.e. text containers as inline graphics)
>> 
>> I think I'm also going to not allow cells to split across containers as
>> this also adds complexity (and I personally have no need for this
>> support).
>> 
>> Harbs
>> 
>> On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
>> 
>>> Just a random thought here, but what if you set the parcels at the end
>>> of
>>> table creation?   Something like, populateParcels() which gets called
>>> after
>>> all cell sizes and positions are known, and then get placed into those
>>> rectangles?
>>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>> 
>>>> Harbs,
>>>> 
>>>> I haven't looked at the Table code at all.  I don't remember exactly
>>>> how
>>>> Parcels work for the standard case, either.
>>>> 
>>>> IMO, HTML Tables are really hard.  In some cases, I think you have to
>>>> compose cells multiple times in order to decide the cell widths and row
>>>> heights.  If your use case can constrain the problem space it might be
>>>> easier to get something to work.
>>>> 
>>>> FWIW, I agree that it doesn't make sense for the main container's
>>>> ParcelList to know about parcels in the table.
>>>> 
>>>> Good luck,
>>>> -Alex
>>>> 
>>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
>>>> 
>>>>> Some more rambling:
>>>>> 
>>>>> The more I'm working through this, the more I'm convinced that the
>>>>> current implementation is fundamentally broken. The cell Parcels
>>>>> really
>>>>> can't be in the same ParcelList as the Containers. I'm pretty sure
>>>>> that
>>>>> not only multi-container text threads are broken, but multi-column
>>>>> containers are broken as well.
>>>>> 
>>>>> It seems to me that there needs to be a separate ParcelList for table
>>>>> cells that are separate from the container parcel list. Table parcels
>>>>> don't exactly fit into the concept of container parcels either because
>>>>> they should be nested inside other parcels (which normal parcels are
>>>>> not). I think I should subclass Parcel as TableCellParcel which would
>>>>> have a parcel as a "parent". I'm also going to have to either modify
>>>>> ParcelList to track the cell parcels or subclass it for dealing with
>>>>> cell
>>>>> parcels.
>>>>> 
>>>>> Harbs
>>>>> 
>>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
>>>>> 
>>>>>> This is really difficult, because I'm not sure what is supposed to
>>>>>> work
>>>>>> in the current implementation. I'm trying to reverse engineer how
>>>>>> tables
>>>>>> work when they don't really work. Trying to sift out what I don't
>>>>>> understand from what simply doesn't work from what is poorly
>>>>>> implemented
>>>>>> is a huge pain.
>>>>>> 
>>>>>> I'm going to ramble a bit. I hope that things will become clearer to
>>>>>> me
>>>>>> as I ramble on... ;-)
>>>>>> 
>>>>>> If someone who understands how text flow in TLF is supposed to work
>>>>>> would either confirm or correct me, I'd appreciate it.
>>>>>> 
>>>>>> Here's how I understand the way TLF works with parcels:
>>>>>> 
>>>>>> Each composition has a ParcelList which contains one or more parcels.
>>>>>> Each ContainerController has one or more parcels in the ParcelList.
>>>>>> Generally, there is one parcel per column. (If a ContainerController
>>>>>> has
>>>>>> more than one column, the composition of each column is done
>>>>>> separately
>>>>>> as a separate parcel.)
>>>>>> 
>>>>>> For normal text frames, this is all pretty straight-forward.
>>>>>> 
>>>>>> With tables things get a bit more muddled. Each table cell is in
>>>>>> effect
>>>>>> a separate composition area. If every composition area gets its own
>>>>>> parcel, I guess this would mean that every cell in the table would
>>>>>> get
>>>>>> its own parcel. If I'm reading the code correctly, it's supposed to
>>>>>> be
>>>>>> doing this. I think another way to look at it, would be to look at
>>>>>> each
>>>>>> column of each table within a specific Container as a separate
>>>>>> composition area (parcel) and position the text within that. I'm not
>>>>>> sure this makes any sense, though. The more I'm looking at how
>>>>>> parcels
>>>>>> work (i.e. vj, etc.), the less this makes sense.
>>>>>> 
>>>>>> So, basically, every cell in the table would be a separate parcel,
>>>>>> and
>>>>>> these parcels need to be organized into rows and columns. Keeping
>>>>>> track
>>>>>> of the columns and the placement of the rows has some level of
>>>>>> complexity. Adding header and footer rows to the mix should make it
>>>>>> more
>>>>>> interesting.
>>>>>> 
>>>>>> Here's what I'm not (yet) totally clear on (or even if it works
>>>>>> right):
>>>>>> 1) The logic of placing the table parcels relative to the container
>>>>>> parcels. The way I see it, the table parcels should be arranged
>>>>>> within
>>>>>> the bounds of the column parcels of the containing container(s).
>>>>>> 2) How the calculations of the parcel placement goes. This is
>>>>>> especially true for tables that might span more than one parent
>>>>>> parcel.
>>>>>> 3) The placement of the table parcels relative to the container
>>>>>> parcels
>>>>>> they are contained within. (Should there be a separate ParcelList for
>>>>>> table parcels, or should it be part of the main ParcelList?)
>>>>>> 4) What I'm not clear on... ;-)
>>>>>> 
>>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>>>>>> 
>>>>>>> I'm back on this, and starting to make some (slow) progress.
>>>>>>> 
>>>>>>> I've started a Google Docs document to try to make some order out of
>>>>>>> the chaos that is the current state of TLF Tables. This is just a
>>>>>>> place
>>>>>>> where I'm jotting down my findings as I go and my thoughts on
>>>>>>> direction
>>>>>>> as I work on this. I made the document publicly editable and would
>>>>>>> love
>>>>>>> input. If there's anyone out there that has answers to the questions
>>>>>>> I'm posing, it would be very helpful!
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> 
>>>> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
>>>>>>> 0zDmSog/edit?usp=sharing
>>>>>>> 
>>>>>>> Harb
>>>>>>> 
>>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>>>>>>> 
>>>>>>>> My first tests are not very encouraging...
>>>>>>>> 
>>>>>>>> Trying to compose the table results in this function returning
>>>>>>>> null:
>>>>>>>>          static tlf_internal function
>>>> beginFactoryCompose():SimpleCompose
>>>>>>>>          {
>>>>>>>>                  var rslt:SimpleCompose = _factoryComposer;
>>>>>>>>                  _factoryComposer = peekFactoryCompose();
>>>>>>>>                  _savedFactoryComposer = null;
>>>>>>>>                  return rslt;
>>>>>>>>          }
>>>>>>>> 
>>>>>>>> Looks like I need to the composition process...
>>>>>>>> FWIW, it made no difference whether I added the rows to a
>>>>>>>> TableBodyElement or to the table directly.
>>>>>>>> 
>>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>>>>>>> 
>>>>>>>>> Hi Harbs,
>>>>>>>>> 
>>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
>>>>>>>>> Or even
>>>>>>>>> complete, or even working at a prototype-level.
>>>>>>>>> 
>>>>>>>>> So good luck with it.  I might be able to ask folks who used to
>>>>>>>>> work
>>>>>>>>> on it
>>>>>>>>> a few questions, but I'm pretty sure their memories of it are
>>>>>>>>> pretty
>>>>>>>>> dim
>>>>>>>>> by now.
>>>>>>>>> 
>>>>>>>>> -Alex
>>>>>>>>> 
>>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>>> I knew I was going to spend some real time on this one day, and
>>>>>>>>>> that time
>>>>>>>>>> is coming really soonŠ
>>>>>>>>>> 
>>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table
>>>>>>>>>> support?
>>>>>>>>>> I
>>>>>>>>>> know it's officially there, but I don't see any documentation on
>>>>>>>>>> it
>>>>>>>>>> --
>>>>>>>>>> not even the basics on how it's supposed to be used.
>>>>>>>>>> 
>>>>>>>>>> I fully expect to find bugs once I start really digging into it,
>>>>>>>>>> but some
>>>>>>>>>> documentation (any) would be nice to get me started.
>>>>>>>>>> 
>>>>>>>>>> Looking at the source code, I see the following classes:
>>>>>>>>>> 
>>>>>>>>>> TableElement
>>>>>>>>>> TableBodyElement
>>>>>>>>>> TableColElement
>>>>>>>>>> TableRowElement
>>>>>>>>>> TableColGroupElement
>>>>>>>>>> TableDataCellElement
>>>>>>>>>> TableFormattedElement
>>>>>>>>>> 
>>>>>>>>>> I understand the structure like this:
>>>>>>>>>> 
>>>>>>>>>> * A TableElement is the top level element for any table
>>>>>>>>>> * All elements in a table inherit from TableFormattedElement
>>>>>>>>>> * The bottom level of a table which needs to contain one or more
>>>>>>>>>> ParagraphElements in a TableDataCellElement
>>>>>>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>>>>>>> 
>>>>>>>>>> After this things get a bit fuzzier.
>>>>>>>>>> 
>>>>>>>>>> What is TableBodyElement used for?
>>>>>>>>>> How is TableColGroupElement and TableColElement used? (I assume
>>>>>>>>>> they are
>>>>>>>>>> used for formatting table columns, but the details are not very
>>>>>>>>>> clear to
>>>>>>>>>> me.)
>>>>>>>>>> What about header and footer rows? Is that supported yet?
>>>>>>>>>> Header and footer columns?
>>>>>>>>>> Is breaking tables across containers supported yet?
>>>>>>>>>> 
>>>>>>>>>> I have not started studying how to specify table formatting
>>>>>>>>>> either.
>>>>>>>>>> I'm
>>>>>>>>>> hoping that's obviousŠ
>>>>>>>>>> 
>>>>>>>>>> I'll try to add some documentation to the source code as things
>>>>>>>>>> become
>>>>>>>>>> clearer to meŠ
>>>>>>>>>> 
>>>>>>>>>> Harbs
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
> 

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

OK, good luck.

On 12/2/13 1:16 AM, "Harbs" <ha...@gmail.com> wrote:

>The way it was implemented is like this:
>
>1) Tables and table columns have fixed widths. (I might add a default
>width if none was set to prevent runtime errors. What's a reasonable
>number?)
>2) Table cell parcels are created with a maximum height of 8000. I'm not
>sure why they picked that number, but it's probably high enough that it's
>fine. After the cell is composed, the height of the parcel is adjusted.
>
>This simplifies the calculations tremendously because tables can be
>safely composed on a row-by-row basis. I think both of these limitations
>are reasonable ones and it's pretty consistent with how tables work in
>DTP apps. The only thing I'm probably going to change is to add the
>option of a fixed height to the cell parcel where the contents would just
>become overset if it does not fit.
>
>One thing I'm planning on changing is related to table widths. Currently,
>the width of a table is constrained by the with of the containing parcel.
>I think it's reasonable that tables can extend beyond the bounds of the
>parent parcel. This is the way InDesign works and I think it's necessary
>for tables that flow across multiple containers since the width of the
>containers are not necessarily constant.
>
>Another limitation that I think is reasonable is no nested tables.
>InDesign for example allows unlimited levels of nesting tables inside
>table cells. This adds a lot of complexity to the composition, and it
>seems to me that this is an edge case. Does TLF currently support nested
>text containers? (i.e. text containers as inline graphics)
>
>I think I'm also going to not allow cells to split across containers as
>this also adds complexity (and I personally have no need for this
>support).
>
>Harbs
>
>On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:
>
>> Just a random thought here, but what if you set the parcels at the end
>>of
>> table creation?   Something like, populateParcels() which gets called
>>after
>> all cell sizes and positions are known, and then get placed into those
>> rectangles?
>> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
>> 
>>> Harbs,
>>> 
>>> I haven't looked at the Table code at all.  I don't remember exactly
>>>how
>>> Parcels work for the standard case, either.
>>> 
>>> IMO, HTML Tables are really hard.  In some cases, I think you have to
>>> compose cells multiple times in order to decide the cell widths and row
>>> heights.  If your use case can constrain the problem space it might be
>>> easier to get something to work.
>>> 
>>> FWIW, I agree that it doesn't make sense for the main container's
>>> ParcelList to know about parcels in the table.
>>> 
>>> Good luck,
>>> -Alex
>>> 
>>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
>>> 
>>>> Some more rambling:
>>>> 
>>>> The more I'm working through this, the more I'm convinced that the
>>>> current implementation is fundamentally broken. The cell Parcels
>>>>really
>>>> can't be in the same ParcelList as the Containers. I'm pretty sure
>>>>that
>>>> not only multi-container text threads are broken, but multi-column
>>>> containers are broken as well.
>>>> 
>>>> It seems to me that there needs to be a separate ParcelList for table
>>>> cells that are separate from the container parcel list. Table parcels
>>>> don't exactly fit into the concept of container parcels either because
>>>> they should be nested inside other parcels (which normal parcels are
>>>> not). I think I should subclass Parcel as TableCellParcel which would
>>>> have a parcel as a "parent". I'm also going to have to either modify
>>>> ParcelList to track the cell parcels or subclass it for dealing with
>>>>cell
>>>> parcels.
>>>> 
>>>> Harbs
>>>> 
>>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
>>>> 
>>>>> This is really difficult, because I'm not sure what is supposed to
>>>>>work
>>>>> in the current implementation. I'm trying to reverse engineer how
>>>>>tables
>>>>> work when they don't really work. Trying to sift out what I don't
>>>>> understand from what simply doesn't work from what is poorly
>>>>>implemented
>>>>> is a huge pain.
>>>>> 
>>>>> I'm going to ramble a bit. I hope that things will become clearer to
>>>>>me
>>>>> as I ramble on... ;-)
>>>>> 
>>>>> If someone who understands how text flow in TLF is supposed to work
>>>>> would either confirm or correct me, I'd appreciate it.
>>>>> 
>>>>> Here's how I understand the way TLF works with parcels:
>>>>> 
>>>>> Each composition has a ParcelList which contains one or more parcels.
>>>>> Each ContainerController has one or more parcels in the ParcelList.
>>>>> Generally, there is one parcel per column. (If a ContainerController
>>>>>has
>>>>> more than one column, the composition of each column is done
>>>>>separately
>>>>> as a separate parcel.)
>>>>> 
>>>>> For normal text frames, this is all pretty straight-forward.
>>>>> 
>>>>> With tables things get a bit more muddled. Each table cell is in
>>>>>effect
>>>>> a separate composition area. If every composition area gets its own
>>>>> parcel, I guess this would mean that every cell in the table would
>>>>>get
>>>>> its own parcel. If I'm reading the code correctly, it's supposed to
>>>>>be
>>>>> doing this. I think another way to look at it, would be to look at
>>>>>each
>>>>> column of each table within a specific Container as a separate
>>>>> composition area (parcel) and position the text within that. I'm not
>>>>> sure this makes any sense, though. The more I'm looking at how
>>>>>parcels
>>>>> work (i.e. vj, etc.), the less this makes sense.
>>>>> 
>>>>> So, basically, every cell in the table would be a separate parcel,
>>>>>and
>>>>> these parcels need to be organized into rows and columns. Keeping
>>>>>track
>>>>> of the columns and the placement of the rows has some level of
>>>>> complexity. Adding header and footer rows to the mix should make it
>>>>>more
>>>>> interesting.
>>>>> 
>>>>> Here's what I'm not (yet) totally clear on (or even if it works
>>>>>right):
>>>>> 1) The logic of placing the table parcels relative to the container
>>>>> parcels. The way I see it, the table parcels should be arranged
>>>>>within
>>>>> the bounds of the column parcels of the containing container(s).
>>>>> 2) How the calculations of the parcel placement goes. This is
>>>>> especially true for tables that might span more than one parent
>>>>>parcel.
>>>>> 3) The placement of the table parcels relative to the container
>>>>>parcels
>>>>> they are contained within. (Should there be a separate ParcelList for
>>>>> table parcels, or should it be part of the main ParcelList?)
>>>>> 4) What I'm not clear on... ;-)
>>>>> 
>>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>>>>> 
>>>>>> I'm back on this, and starting to make some (slow) progress.
>>>>>> 
>>>>>> I've started a Google Docs document to try to make some order out of
>>>>>> the chaos that is the current state of TLF Tables. This is just a
>>>>>>place
>>>>>> where I'm jotting down my findings as I go and my thoughts on
>>>>>>direction
>>>>>> as I work on this. I made the document publicly editable and would
>>>>>>love
>>>>>> input. If there's anyone out there that has answers to the questions
>>>>>> I'm posing, it would be very helpful!
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>>>https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
>>>>>> 0zDmSog/edit?usp=sharing
>>>>>> 
>>>>>> Harb
>>>>>> 
>>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>>>>>> 
>>>>>>> My first tests are not very encouraging...
>>>>>>> 
>>>>>>> Trying to compose the table results in this function returning
>>>>>>>null:
>>>>>>>           static tlf_internal function
>>> beginFactoryCompose():SimpleCompose
>>>>>>>           {
>>>>>>>                   var rslt:SimpleCompose = _factoryComposer;
>>>>>>>                   _factoryComposer = peekFactoryCompose();
>>>>>>>                   _savedFactoryComposer = null;
>>>>>>>                   return rslt;
>>>>>>>           }
>>>>>>> 
>>>>>>> Looks like I need to the composition process...
>>>>>>> FWIW, it made no difference whether I added the rows to a
>>>>>>> TableBodyElement or to the table directly.
>>>>>>> 
>>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>>>>>> 
>>>>>>>> Hi Harbs,
>>>>>>>> 
>>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
>>>>>>>> Or even
>>>>>>>> complete, or even working at a prototype-level.
>>>>>>>> 
>>>>>>>> So good luck with it.  I might be able to ask folks who used to
>>>>>>>>work
>>>>>>>> on it
>>>>>>>> a few questions, but I'm pretty sure their memories of it are
>>>>>>>>pretty
>>>>>>>> dim
>>>>>>>> by now.
>>>>>>>> 
>>>>>>>> -Alex
>>>>>>>> 
>>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I knew I was going to spend some real time on this one day, and
>>>>>>>>> that time
>>>>>>>>> is coming really soonŠ
>>>>>>>>> 
>>>>>>>>> Before I dig in too deeply, what's the status on TLF Table
>>>>>>>>>support?
>>>>>>>>> I
>>>>>>>>> know it's officially there, but I don't see any documentation on
>>>>>>>>>it
>>>>>>>>> --
>>>>>>>>> not even the basics on how it's supposed to be used.
>>>>>>>>> 
>>>>>>>>> I fully expect to find bugs once I start really digging into it,
>>>>>>>>> but some
>>>>>>>>> documentation (any) would be nice to get me started.
>>>>>>>>> 
>>>>>>>>> Looking at the source code, I see the following classes:
>>>>>>>>> 
>>>>>>>>> TableElement
>>>>>>>>> TableBodyElement
>>>>>>>>> TableColElement
>>>>>>>>> TableRowElement
>>>>>>>>> TableColGroupElement
>>>>>>>>> TableDataCellElement
>>>>>>>>> TableFormattedElement
>>>>>>>>> 
>>>>>>>>> I understand the structure like this:
>>>>>>>>> 
>>>>>>>>> * A TableElement is the top level element for any table
>>>>>>>>> * All elements in a table inherit from TableFormattedElement
>>>>>>>>> * The bottom level of a table which needs to contain one or more
>>>>>>>>> ParagraphElements in a TableDataCellElement
>>>>>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>>>>>> 
>>>>>>>>> After this things get a bit fuzzier.
>>>>>>>>> 
>>>>>>>>> What is TableBodyElement used for?
>>>>>>>>> How is TableColGroupElement and TableColElement used? (I assume
>>>>>>>>> they are
>>>>>>>>> used for formatting table columns, but the details are not very
>>>>>>>>> clear to
>>>>>>>>> me.)
>>>>>>>>> What about header and footer rows? Is that supported yet?
>>>>>>>>> Header and footer columns?
>>>>>>>>> Is breaking tables across containers supported yet?
>>>>>>>>> 
>>>>>>>>> I have not started studying how to specify table formatting
>>>>>>>>>either.
>>>>>>>>> I'm
>>>>>>>>> hoping that's obviousŠ
>>>>>>>>> 
>>>>>>>>> I'll try to add some documentation to the source code as things
>>>>>>>>> become
>>>>>>>>> clearer to meŠ
>>>>>>>>> 
>>>>>>>>> Harbs
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>

Re: TLF Tables

[Harbs <ha...@gmail.com>]

The way it was implemented is like this:

1) Tables and table columns have fixed widths. (I might add a default width if none was set to prevent runtime errors. What's a reasonable number?)
2) Table cell parcels are created with a maximum height of 8000. I'm not sure why they picked that number, but it's probably high enough that it's fine. After the cell is composed, the height of the parcel is adjusted.

This simplifies the calculations tremendously because tables can be safely composed on a row-by-row basis. I think both of these limitations are reasonable ones and it's pretty consistent with how tables work in DTP apps. The only thing I'm probably going to change is to add the option of a fixed height to the cell parcel where the contents would just become overset if it does not fit.

One thing I'm planning on changing is related to table widths. Currently, the width of a table is constrained by the with of the containing parcel. I think it's reasonable that tables can extend beyond the bounds of the parent parcel. This is the way InDesign works and I think it's necessary for tables that flow across multiple containers since the width of the containers are not necessarily constant.

Another limitation that I think is reasonable is no nested tables. InDesign for example allows unlimited levels of nesting tables inside table cells. This adds a lot of complexity to the composition, and it seems to me that this is an edge case. Does TLF currently support nested text containers? (i.e. text containers as inline graphics)

I think I'm also going to not allow cells to split across containers as this also adds complexity (and I personally have no need for this support).

Harbs

On Dec 2, 2013, at 8:19 AM, Avi Kessner wrote:

> Just a random thought here, but what if you set the parcels at the end of
> table creation?   Something like, populateParcels() which gets called after
> all cell sizes and positions are known, and then get placed into those
> rectangles?
> On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:
> 
>> Harbs,
>> 
>> I haven't looked at the Table code at all.  I don't remember exactly how
>> Parcels work for the standard case, either.
>> 
>> IMO, HTML Tables are really hard.  In some cases, I think you have to
>> compose cells multiple times in order to decide the cell widths and row
>> heights.  If your use case can constrain the problem space it might be
>> easier to get something to work.
>> 
>> FWIW, I agree that it doesn't make sense for the main container's
>> ParcelList to know about parcels in the table.
>> 
>> Good luck,
>> -Alex
>> 
>> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
>> 
>>> Some more rambling:
>>> 
>>> The more I'm working through this, the more I'm convinced that the
>>> current implementation is fundamentally broken. The cell Parcels really
>>> can't be in the same ParcelList as the Containers. I'm pretty sure that
>>> not only multi-container text threads are broken, but multi-column
>>> containers are broken as well.
>>> 
>>> It seems to me that there needs to be a separate ParcelList for table
>>> cells that are separate from the container parcel list. Table parcels
>>> don't exactly fit into the concept of container parcels either because
>>> they should be nested inside other parcels (which normal parcels are
>>> not). I think I should subclass Parcel as TableCellParcel which would
>>> have a parcel as a "parent". I'm also going to have to either modify
>>> ParcelList to track the cell parcels or subclass it for dealing with cell
>>> parcels.
>>> 
>>> Harbs
>>> 
>>> On Dec 1, 2013, at 2:42 PM, Harbs wrote:
>>> 
>>>> This is really difficult, because I'm not sure what is supposed to work
>>>> in the current implementation. I'm trying to reverse engineer how tables
>>>> work when they don't really work. Trying to sift out what I don't
>>>> understand from what simply doesn't work from what is poorly implemented
>>>> is a huge pain.
>>>> 
>>>> I'm going to ramble a bit. I hope that things will become clearer to me
>>>> as I ramble on... ;-)
>>>> 
>>>> If someone who understands how text flow in TLF is supposed to work
>>>> would either confirm or correct me, I'd appreciate it.
>>>> 
>>>> Here's how I understand the way TLF works with parcels:
>>>> 
>>>> Each composition has a ParcelList which contains one or more parcels.
>>>> Each ContainerController has one or more parcels in the ParcelList.
>>>> Generally, there is one parcel per column. (If a ContainerController has
>>>> more than one column, the composition of each column is done separately
>>>> as a separate parcel.)
>>>> 
>>>> For normal text frames, this is all pretty straight-forward.
>>>> 
>>>> With tables things get a bit more muddled. Each table cell is in effect
>>>> a separate composition area. If every composition area gets its own
>>>> parcel, I guess this would mean that every cell in the table would get
>>>> its own parcel. If I'm reading the code correctly, it's supposed to be
>>>> doing this. I think another way to look at it, would be to look at each
>>>> column of each table within a specific Container as a separate
>>>> composition area (parcel) and position the text within that. I'm not
>>>> sure this makes any sense, though. The more I'm looking at how parcels
>>>> work (i.e. vj, etc.), the less this makes sense.
>>>> 
>>>> So, basically, every cell in the table would be a separate parcel, and
>>>> these parcels need to be organized into rows and columns. Keeping track
>>>> of the columns and the placement of the rows has some level of
>>>> complexity. Adding header and footer rows to the mix should make it more
>>>> interesting.
>>>> 
>>>> Here's what I'm not (yet) totally clear on (or even if it works right):
>>>> 1) The logic of placing the table parcels relative to the container
>>>> parcels. The way I see it, the table parcels should be arranged within
>>>> the bounds of the column parcels of the containing container(s).
>>>> 2) How the calculations of the parcel placement goes. This is
>>>> especially true for tables that might span more than one parent parcel.
>>>> 3) The placement of the table parcels relative to the container parcels
>>>> they are contained within. (Should there be a separate ParcelList for
>>>> table parcels, or should it be part of the main ParcelList?)
>>>> 4) What I'm not clear on... ;-)
>>>> 
>>>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>>>> 
>>>>> I'm back on this, and starting to make some (slow) progress.
>>>>> 
>>>>> I've started a Google Docs document to try to make some order out of
>>>>> the chaos that is the current state of TLF Tables. This is just a place
>>>>> where I'm jotting down my findings as I go and my thoughts on direction
>>>>> as I work on this. I made the document publicly editable and would love
>>>>> input. If there's anyone out there that has answers to the questions
>>>>> I'm posing, it would be very helpful!
>>>>> 
>>>>> 
>>>>> 
>> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
>>>>> 0zDmSog/edit?usp=sharing
>>>>> 
>>>>> Harb
>>>>> 
>>>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>>>>> 
>>>>>> My first tests are not very encouraging...
>>>>>> 
>>>>>> Trying to compose the table results in this function returning null:
>>>>>>           static tlf_internal function
>> beginFactoryCompose():SimpleCompose
>>>>>>           {
>>>>>>                   var rslt:SimpleCompose = _factoryComposer;
>>>>>>                   _factoryComposer = peekFactoryCompose();
>>>>>>                   _savedFactoryComposer = null;
>>>>>>                   return rslt;
>>>>>>           }
>>>>>> 
>>>>>> Looks like I need to the composition process...
>>>>>> FWIW, it made no difference whether I added the rows to a
>>>>>> TableBodyElement or to the table directly.
>>>>>> 
>>>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>>>>> 
>>>>>>> Hi Harbs,
>>>>>>> 
>>>>>>> I see code for Tables, but I'm not sure it is "officially" there.
>>>>>>> Or even
>>>>>>> complete, or even working at a prototype-level.
>>>>>>> 
>>>>>>> So good luck with it.  I might be able to ask folks who used to work
>>>>>>> on it
>>>>>>> a few questions, but I'm pretty sure their memories of it are pretty
>>>>>>> dim
>>>>>>> by now.
>>>>>>> 
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> I knew I was going to spend some real time on this one day, and
>>>>>>>> that time
>>>>>>>> is coming really soonŠ
>>>>>>>> 
>>>>>>>> Before I dig in too deeply, what's the status on TLF Table support?
>>>>>>>> I
>>>>>>>> know it's officially there, but I don't see any documentation on it
>>>>>>>> --
>>>>>>>> not even the basics on how it's supposed to be used.
>>>>>>>> 
>>>>>>>> I fully expect to find bugs once I start really digging into it,
>>>>>>>> but some
>>>>>>>> documentation (any) would be nice to get me started.
>>>>>>>> 
>>>>>>>> Looking at the source code, I see the following classes:
>>>>>>>> 
>>>>>>>> TableElement
>>>>>>>> TableBodyElement
>>>>>>>> TableColElement
>>>>>>>> TableRowElement
>>>>>>>> TableColGroupElement
>>>>>>>> TableDataCellElement
>>>>>>>> TableFormattedElement
>>>>>>>> 
>>>>>>>> I understand the structure like this:
>>>>>>>> 
>>>>>>>> * A TableElement is the top level element for any table
>>>>>>>> * All elements in a table inherit from TableFormattedElement
>>>>>>>> * The bottom level of a table which needs to contain one or more
>>>>>>>> ParagraphElements in a TableDataCellElement
>>>>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>>>>> 
>>>>>>>> After this things get a bit fuzzier.
>>>>>>>> 
>>>>>>>> What is TableBodyElement used for?
>>>>>>>> How is TableColGroupElement and TableColElement used? (I assume
>>>>>>>> they are
>>>>>>>> used for formatting table columns, but the details are not very
>>>>>>>> clear to
>>>>>>>> me.)
>>>>>>>> What about header and footer rows? Is that supported yet?
>>>>>>>> Header and footer columns?
>>>>>>>> Is breaking tables across containers supported yet?
>>>>>>>> 
>>>>>>>> I have not started studying how to specify table formatting either.
>>>>>>>> I'm
>>>>>>>> hoping that's obviousŠ
>>>>>>>> 
>>>>>>>> I'll try to add some documentation to the source code as things
>>>>>>>> become
>>>>>>>> clearer to meŠ
>>>>>>>> 
>>>>>>>> Harbs
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 

Re: TLF Tables

[Avi Kessner <ak...@gmail.com>]

Just a random thought here, but what if you set the parcels at the end of
table creation?   Something like, populateParcels() which gets called after
all cell sizes and positions are known, and then get placed into those
rectangles?
On Dec 2, 2013 7:02 AM, "Alex Harui" <ah...@adobe.com> wrote:

> Harbs,
>
> I haven't looked at the Table code at all.  I don't remember exactly how
> Parcels work for the standard case, either.
>
> IMO, HTML Tables are really hard.  In some cases, I think you have to
> compose cells multiple times in order to decide the cell widths and row
> heights.  If your use case can constrain the problem space it might be
> easier to get something to work.
>
> FWIW, I agree that it doesn't make sense for the main container's
> ParcelList to know about parcels in the table.
>
> Good luck,
> -Alex
>
> On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:
>
> >Some more rambling:
> >
> >The more I'm working through this, the more I'm convinced that the
> >current implementation is fundamentally broken. The cell Parcels really
> >can't be in the same ParcelList as the Containers. I'm pretty sure that
> >not only multi-container text threads are broken, but multi-column
> >containers are broken as well.
> >
> >It seems to me that there needs to be a separate ParcelList for table
> >cells that are separate from the container parcel list. Table parcels
> >don't exactly fit into the concept of container parcels either because
> >they should be nested inside other parcels (which normal parcels are
> >not). I think I should subclass Parcel as TableCellParcel which would
> >have a parcel as a "parent". I'm also going to have to either modify
> >ParcelList to track the cell parcels or subclass it for dealing with cell
> >parcels.
> >
> >Harbs
> >
> >On Dec 1, 2013, at 2:42 PM, Harbs wrote:
> >
> >> This is really difficult, because I'm not sure what is supposed to work
> >>in the current implementation. I'm trying to reverse engineer how tables
> >>work when they don't really work. Trying to sift out what I don't
> >>understand from what simply doesn't work from what is poorly implemented
> >>is a huge pain.
> >>
> >> I'm going to ramble a bit. I hope that things will become clearer to me
> >>as I ramble on... ;-)
> >>
> >> If someone who understands how text flow in TLF is supposed to work
> >>would either confirm or correct me, I'd appreciate it.
> >>
> >> Here's how I understand the way TLF works with parcels:
> >>
> >> Each composition has a ParcelList which contains one or more parcels.
> >>Each ContainerController has one or more parcels in the ParcelList.
> >>Generally, there is one parcel per column. (If a ContainerController has
> >>more than one column, the composition of each column is done separately
> >>as a separate parcel.)
> >>
> >> For normal text frames, this is all pretty straight-forward.
> >>
> >> With tables things get a bit more muddled. Each table cell is in effect
> >>a separate composition area. If every composition area gets its own
> >>parcel, I guess this would mean that every cell in the table would get
> >>its own parcel. If I'm reading the code correctly, it's supposed to be
> >>doing this. I think another way to look at it, would be to look at each
> >>column of each table within a specific Container as a separate
> >>composition area (parcel) and position the text within that. I'm not
> >>sure this makes any sense, though. The more I'm looking at how parcels
> >>work (i.e. vj, etc.), the less this makes sense.
> >>
> >> So, basically, every cell in the table would be a separate parcel, and
> >>these parcels need to be organized into rows and columns. Keeping track
> >>of the columns and the placement of the rows has some level of
> >>complexity. Adding header and footer rows to the mix should make it more
> >>interesting.
> >>
> >> Here's what I'm not (yet) totally clear on (or even if it works right):
> >> 1) The logic of placing the table parcels relative to the container
> >>parcels. The way I see it, the table parcels should be arranged within
> >>the bounds of the column parcels of the containing container(s).
> >> 2) How the calculations of the parcel placement goes. This is
> >>especially true for tables that might span more than one parent parcel.
> >> 3) The placement of the table parcels relative to the container parcels
> >>they are contained within. (Should there be a separate ParcelList for
> >>table parcels, or should it be part of the main ParcelList?)
> >> 4) What I'm not clear on... ;-)
> >>
> >> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
> >>
> >>> I'm back on this, and starting to make some (slow) progress.
> >>>
> >>> I've started a Google Docs document to try to make some order out of
> >>>the chaos that is the current state of TLF Tables. This is just a place
> >>>where I'm jotting down my findings as I go and my thoughts on direction
> >>>as I work on this. I made the document publicly editable and would love
> >>>input. If there's anyone out there that has answers to the questions
> >>>I'm posing, it would be very helpful!
> >>>
> >>>
> >>>
> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
> >>>0zDmSog/edit?usp=sharing
> >>>
> >>> Harb
> >>>
> >>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
> >>>
> >>>> My first tests are not very encouraging...
> >>>>
> >>>> Trying to compose the table results in this function returning null:
> >>>>            static tlf_internal function
> beginFactoryCompose():SimpleCompose
> >>>>            {
> >>>>                    var rslt:SimpleCompose = _factoryComposer;
> >>>>                    _factoryComposer = peekFactoryCompose();
> >>>>                    _savedFactoryComposer = null;
> >>>>                    return rslt;
> >>>>            }
> >>>>
> >>>> Looks like I need to the composition process...
> >>>> FWIW, it made no difference whether I added the rows to a
> >>>>TableBodyElement or to the table directly.
> >>>>
> >>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
> >>>>
> >>>>> Hi Harbs,
> >>>>>
> >>>>> I see code for Tables, but I'm not sure it is "officially" there.
> >>>>>Or even
> >>>>> complete, or even working at a prototype-level.
> >>>>>
> >>>>> So good luck with it.  I might be able to ask folks who used to work
> >>>>>on it
> >>>>> a few questions, but I'm pretty sure their memories of it are pretty
> >>>>>dim
> >>>>> by now.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>>> I knew I was going to spend some real time on this one day, and
> >>>>>>that time
> >>>>>> is coming really soonŠ
> >>>>>>
> >>>>>> Before I dig in too deeply, what's the status on TLF Table support?
> >>>>>>I
> >>>>>> know it's officially there, but I don't see any documentation on it
> >>>>>>--
> >>>>>> not even the basics on how it's supposed to be used.
> >>>>>>
> >>>>>> I fully expect to find bugs once I start really digging into it,
> >>>>>>but some
> >>>>>> documentation (any) would be nice to get me started.
> >>>>>>
> >>>>>> Looking at the source code, I see the following classes:
> >>>>>>
> >>>>>> TableElement
> >>>>>> TableBodyElement
> >>>>>> TableColElement
> >>>>>> TableRowElement
> >>>>>> TableColGroupElement
> >>>>>> TableDataCellElement
> >>>>>> TableFormattedElement
> >>>>>>
> >>>>>> I understand the structure like this:
> >>>>>>
> >>>>>> * A TableElement is the top level element for any table
> >>>>>> * All elements in a table inherit from TableFormattedElement
> >>>>>> * The bottom level of a table which needs to contain one or more
> >>>>>> ParagraphElements in a TableDataCellElement
> >>>>>> * TableDataCellElements must reside within a TableRowElement
> >>>>>>
> >>>>>> After this things get a bit fuzzier.
> >>>>>>
> >>>>>> What is TableBodyElement used for?
> >>>>>> How is TableColGroupElement and TableColElement used? (I assume
> >>>>>>they are
> >>>>>> used for formatting table columns, but the details are not very
> >>>>>>clear to
> >>>>>> me.)
> >>>>>> What about header and footer rows? Is that supported yet?
> >>>>>> Header and footer columns?
> >>>>>> Is breaking tables across containers supported yet?
> >>>>>>
> >>>>>> I have not started studying how to specify table formatting either.
> >>>>>>I'm
> >>>>>> hoping that's obviousŠ
> >>>>>>
> >>>>>> I'll try to add some documentation to the source code as things
> >>>>>>become
> >>>>>> clearer to meŠ
> >>>>>>
> >>>>>> Harbs
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

Re: TLF Tables

[Alex Harui <ah...@adobe.com>]

Harbs,

I haven't looked at the Table code at all.  I don't remember exactly how
Parcels work for the standard case, either.

IMO, HTML Tables are really hard.  In some cases, I think you have to
compose cells multiple times in order to decide the cell widths and row
heights.  If your use case can constrain the problem space it might be
easier to get something to work.

FWIW, I agree that it doesn't make sense for the main container's
ParcelList to know about parcels in the table.

Good luck,
-Alex

On 12/1/13 6:14 AM, "Gavriel Harbater" <ga...@gmail.com> wrote:

>Some more rambling:
>
>The more I'm working through this, the more I'm convinced that the
>current implementation is fundamentally broken. The cell Parcels really
>can't be in the same ParcelList as the Containers. I'm pretty sure that
>not only multi-container text threads are broken, but multi-column
>containers are broken as well.
>
>It seems to me that there needs to be a separate ParcelList for table
>cells that are separate from the container parcel list. Table parcels
>don't exactly fit into the concept of container parcels either because
>they should be nested inside other parcels (which normal parcels are
>not). I think I should subclass Parcel as TableCellParcel which would
>have a parcel as a "parent". I'm also going to have to either modify
>ParcelList to track the cell parcels or subclass it for dealing with cell
>parcels.
>
>Harbs
>
>On Dec 1, 2013, at 2:42 PM, Harbs wrote:
>
>> This is really difficult, because I'm not sure what is supposed to work
>>in the current implementation. I'm trying to reverse engineer how tables
>>work when they don't really work. Trying to sift out what I don't
>>understand from what simply doesn't work from what is poorly implemented
>>is a huge pain.
>> 
>> I'm going to ramble a bit. I hope that things will become clearer to me
>>as I ramble on... ;-)
>> 
>> If someone who understands how text flow in TLF is supposed to work
>>would either confirm or correct me, I'd appreciate it.
>> 
>> Here's how I understand the way TLF works with parcels:
>> 
>> Each composition has a ParcelList which contains one or more parcels.
>>Each ContainerController has one or more parcels in the ParcelList.
>>Generally, there is one parcel per column. (If a ContainerController has
>>more than one column, the composition of each column is done separately
>>as a separate parcel.)
>> 
>> For normal text frames, this is all pretty straight-forward.
>> 
>> With tables things get a bit more muddled. Each table cell is in effect
>>a separate composition area. If every composition area gets its own
>>parcel, I guess this would mean that every cell in the table would get
>>its own parcel. If I'm reading the code correctly, it's supposed to be
>>doing this. I think another way to look at it, would be to look at each
>>column of each table within a specific Container as a separate
>>composition area (parcel) and position the text within that. I'm not
>>sure this makes any sense, though. The more I'm looking at how parcels
>>work (i.e. vj, etc.), the less this makes sense.
>> 
>> So, basically, every cell in the table would be a separate parcel, and
>>these parcels need to be organized into rows and columns. Keeping track
>>of the columns and the placement of the rows has some level of
>>complexity. Adding header and footer rows to the mix should make it more
>>interesting.
>> 
>> Here's what I'm not (yet) totally clear on (or even if it works right):
>> 1) The logic of placing the table parcels relative to the container
>>parcels. The way I see it, the table parcels should be arranged within
>>the bounds of the column parcels of the containing container(s).
>> 2) How the calculations of the parcel placement goes. This is
>>especially true for tables that might span more than one parent parcel.
>> 3) The placement of the table parcels relative to the container parcels
>>they are contained within. (Should there be a separate ParcelList for
>>table parcels, or should it be part of the main ParcelList?)
>> 4) What I'm not clear on... ;-)
>> 
>> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>> 
>>> I'm back on this, and starting to make some (slow) progress.
>>> 
>>> I've started a Google Docs document to try to make some order out of
>>>the chaos that is the current state of TLF Tables. This is just a place
>>>where I'm jotting down my findings as I go and my thoughts on direction
>>>as I work on this. I made the document publicly editable and would love
>>>input. If there's anyone out there that has answers to the questions
>>>I'm posing, it would be very helpful!
>>> 
>>> 
>>>https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj
>>>0zDmSog/edit?usp=sharing
>>> 
>>> Harb
>>> 
>>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>>> 
>>>> My first tests are not very encouraging...
>>>> 
>>>> Trying to compose the table results in this function returning null:
>>>> 		static tlf_internal function beginFactoryCompose():SimpleCompose
>>>> 		{
>>>> 			var rslt:SimpleCompose = _factoryComposer;
>>>> 			_factoryComposer = peekFactoryCompose();
>>>> 			_savedFactoryComposer = null;
>>>> 			return rslt;
>>>> 		}
>>>> 
>>>> Looks like I need to the composition process...
>>>> FWIW, it made no difference whether I added the rows to a
>>>>TableBodyElement or to the table directly.
>>>> 
>>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>>> 
>>>>> Hi Harbs,
>>>>> 
>>>>> I see code for Tables, but I'm not sure it is "officially" there.
>>>>>Or even
>>>>> complete, or even working at a prototype-level.
>>>>> 
>>>>> So good luck with it.  I might be able to ask folks who used to work
>>>>>on it
>>>>> a few questions, but I'm pretty sure their memories of it are pretty
>>>>>dim
>>>>> by now.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>>> I knew I was going to spend some real time on this one day, and
>>>>>>that time
>>>>>> is coming really soonŠ
>>>>>> 
>>>>>> Before I dig in too deeply, what's the status on TLF Table support?
>>>>>>I
>>>>>> know it's officially there, but I don't see any documentation on it
>>>>>>--
>>>>>> not even the basics on how it's supposed to be used.
>>>>>> 
>>>>>> I fully expect to find bugs once I start really digging into it,
>>>>>>but some
>>>>>> documentation (any) would be nice to get me started.
>>>>>> 
>>>>>> Looking at the source code, I see the following classes:
>>>>>> 
>>>>>> TableElement
>>>>>> TableBodyElement
>>>>>> TableColElement
>>>>>> TableRowElement
>>>>>> TableColGroupElement
>>>>>> TableDataCellElement
>>>>>> TableFormattedElement
>>>>>> 
>>>>>> I understand the structure like this:
>>>>>> 
>>>>>> * A TableElement is the top level element for any table
>>>>>> * All elements in a table inherit from TableFormattedElement
>>>>>> * The bottom level of a table which needs to contain one or more
>>>>>> ParagraphElements in a TableDataCellElement
>>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>>> 
>>>>>> After this things get a bit fuzzier.
>>>>>> 
>>>>>> What is TableBodyElement used for?
>>>>>> How is TableColGroupElement and TableColElement used? (I assume
>>>>>>they are
>>>>>> used for formatting table columns, but the details are not very
>>>>>>clear to
>>>>>> me.)
>>>>>> What about header and footer rows? Is that supported yet?
>>>>>> Header and footer columns?
>>>>>> Is breaking tables across containers supported yet?
>>>>>> 
>>>>>> I have not started studying how to specify table formatting either.
>>>>>>I'm
>>>>>> hoping that's obviousŠ
>>>>>> 
>>>>>> I'll try to add some documentation to the source code as things
>>>>>>become
>>>>>> clearer to meŠ
>>>>>> 
>>>>>> Harbs
>>>>> 
>>>> 
>>> 
>> 
>

Re: TLF Tables

[Gavriel Harbater <ga...@gmail.com>]

Some more rambling:

The more I'm working through this, the more I'm convinced that the current implementation is fundamentally broken. The cell Parcels really can't be in the same ParcelList as the Containers. I'm pretty sure that not only multi-container text threads are broken, but multi-column containers are broken as well.

It seems to me that there needs to be a separate ParcelList for table cells that are separate from the container parcel list. Table parcels don't exactly fit into the concept of container parcels either because they should be nested inside other parcels (which normal parcels are not). I think I should subclass Parcel as TableCellParcel which would have a parcel as a "parent". I'm also going to have to either modify ParcelList to track the cell parcels or subclass it for dealing with cell parcels.

Harbs

On Dec 1, 2013, at 2:42 PM, Harbs wrote:

> This is really difficult, because I'm not sure what is supposed to work in the current implementation. I'm trying to reverse engineer how tables work when they don't really work. Trying to sift out what I don't understand from what simply doesn't work from what is poorly implemented is a huge pain.
> 
> I'm going to ramble a bit. I hope that things will become clearer to me as I ramble on… ;-)
> 
> If someone who understands how text flow in TLF is supposed to work would either confirm or correct me, I'd appreciate it.
> 
> Here's how I understand the way TLF works with parcels:
> 
> Each composition has a ParcelList which contains one or more parcels. Each ContainerController has one or more parcels in the ParcelList. Generally, there is one parcel per column. (If a ContainerController has more than one column, the composition of each column is done separately as a separate parcel.)
> 
> For normal text frames, this is all pretty straight-forward.
> 
> With tables things get a bit more muddled. Each table cell is in effect a separate composition area. If every composition area gets its own parcel, I guess this would mean that every cell in the table would get its own parcel. If I'm reading the code correctly, it's supposed to be doing this. I think another way to look at it, would be to look at each column of each table within a specific Container as a separate composition area (parcel) and position the text within that. I'm not sure this makes any sense, though. The more I'm looking at how parcels work (i.e. vj, etc.), the less this makes sense.
> 
> So, basically, every cell in the table would be a separate parcel, and these parcels need to be organized into rows and columns. Keeping track of the columns and the placement of the rows has some level of complexity. Adding header and footer rows to the mix should make it more interesting.
> 
> Here's what I'm not (yet) totally clear on (or even if it works right):
> 1) The logic of placing the table parcels relative to the container parcels. The way I see it, the table parcels should be arranged within the bounds of the column parcels of the containing container(s).
> 2) How the calculations of the parcel placement goes. This is especially true for tables that might span more than one parent parcel.
> 3) The placement of the table parcels relative to the container parcels they are contained within. (Should there be a separate ParcelList for table parcels, or should it be part of the main ParcelList?)
> 4) What I'm not clear on… ;-)
> 
> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
> 
>> I'm back on this, and starting to make some (slow) progress.
>> 
>> I've started a Google Docs document to try to make some order out of the chaos that is the current state of TLF Tables. This is just a place where I'm jotting down my findings as I go and my thoughts on direction as I work on this. I made the document publicly editable and would love input. If there's anyone out there that has answers to the questions I'm posing, it would be very helpful!
>> 
>> https://docs.google.com/document/d/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQoj0zDmSog/edit?usp=sharing
>> 
>> Harb
>> 
>> On Sep 10, 2013, at 11:22 PM, Harbs wrote:
>> 
>>> My first tests are not very encouraging…
>>> 
>>> Trying to compose the table results in this function returning null:
>>> 		static tlf_internal function beginFactoryCompose():SimpleCompose
>>> 		{
>>> 			var rslt:SimpleCompose = _factoryComposer;
>>> 			_factoryComposer = peekFactoryCompose();
>>> 			_savedFactoryComposer = null;
>>> 			return rslt;
>>> 		}
>>> 
>>> Looks like I need to the composition process...
>>> FWIW, it made no difference whether I added the rows to a TableBodyElement or to the table directly.
>>> 
>>> On Sep 10, 2013, at 7:17 PM, Alex Harui wrote:
>>> 
>>>> Hi Harbs,
>>>> 
>>>> I see code for Tables, but I'm not sure it is "officially" there.  Or even
>>>> complete, or even working at a prototype-level.
>>>> 
>>>> So good luck with it.  I might be able to ask folks who used to work on it
>>>> a few questions, but I'm pretty sure their memories of it are pretty dim
>>>> by now.
>>>> 
>>>> -Alex
>>>> 
>>>> On 9/10/13 6:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>>> I knew I was going to spend some real time on this one day, and that time
>>>>> is coming really soonŠ
>>>>> 
>>>>> Before I dig in too deeply, what's the status on TLF Table support? I
>>>>> know it's officially there, but I don't see any documentation on it --
>>>>> not even the basics on how it's supposed to be used.
>>>>> 
>>>>> I fully expect to find bugs once I start really digging into it, but some
>>>>> documentation (any) would be nice to get me started.
>>>>> 
>>>>> Looking at the source code, I see the following classes:
>>>>> 
>>>>> TableElement
>>>>> TableBodyElement
>>>>> TableColElement
>>>>> TableRowElement
>>>>> TableColGroupElement
>>>>> TableDataCellElement
>>>>> TableFormattedElement
>>>>> 
>>>>> I understand the structure like this:
>>>>> 
>>>>> * A TableElement is the top level element for any table
>>>>> * All elements in a table inherit from TableFormattedElement
>>>>> * The bottom level of a table which needs to contain one or more
>>>>> ParagraphElements in a TableDataCellElement
>>>>> * TableDataCellElements must reside within a TableRowElement
>>>>> 
>>>>> After this things get a bit fuzzier.
>>>>> 
>>>>> What is TableBodyElement used for?
>>>>> How is TableColGroupElement and TableColElement used? (I assume they are
>>>>> used for formatting table columns, but the details are not very clear to
>>>>> me.)
>>>>> What about header and footer rows? Is that supported yet?
>>>>> Header and footer columns?
>>>>> Is breaking tables across containers supported yet?
>>>>> 
>>>>> I have not started studying how to specify table formatting either. I'm
>>>>> hoping that's obviousŠ
>>>>> 
>>>>> I'll try to add some documentation to the source code as things become
>>>>> clearer to meŠ
>>>>> 
>>>>> Harbs
>>>> 
>>> 
>> 
>