flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: TLF Tables
Date Mon, 02 Dec 2013 09:16:10 GMT
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).


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" <aharui@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" <gavharbs@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
>>>>>>> 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,
>>>>>>>> that time
>>>>>>>> is coming really soonŠ
>>>>>>>> Before I dig in too deeply, what's the status on TLF Table
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> they are
>>>>>>>> used for formatting table columns, but the details are not
>>>>>>>> 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
>>>>>>>> I'm
>>>>>>>> hoping that's obviousŠ
>>>>>>>> I'll try to add some documentation to the source code as
>>>>>>>> become
>>>>>>>> clearer to meŠ
>>>>>>>> Harbs

View raw message