flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavriel Harbater <gavha...@gmail.com>
Subject Re: TLF Tables
Date Sun, 01 Dec 2013 14:14:42 GMT
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.


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" <harbs.lists@gmail.com> wrote:
>>>>> I knew I was going to spend some real time on this one day, and that
>>>>> 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
>>>>> 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
>>>>> used for formatting table columns, but the details are not very clear
>>>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message