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 Wed, 04 Dec 2013 14:38:04 GMT
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

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" <harbs.lists@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" <harbs.lists@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" <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
>>>>>> 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
>>>>>> 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>
>>>>>>> Some more rambling:
>>>>>>> The more I'm working through this, the more I'm convinced that
>>>>>>> current implementation is fundamentally broken. The cell Parcels
>>>>>>> really
>>>>>>> can't be in the same ParcelList as the Containers. I'm pretty
>>>>>>> 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
>>>>>>> cells that are separate from the container parcel list. Table
>>>>>>> don't exactly fit into the concept of container parcels either
>> because
>>>>>>> they should be nested inside other parcels (which normal parcels
>>>>>>> not). I think I should subclass Parcel as TableCellParcel which
>>>>>>> have a parcel as a "parent". I'm also going to have to either
>>>>>>> ParcelList to track the cell parcels or subclass it for dealing
>>>>>>> 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
>>>>>>>> work
>>>>>>>> in the current implementation. I'm trying to reverse engineer
>>>>>>>> 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
>>>>>>>> get
>>>>>>>> its own parcel. If I'm reading the code correctly, it's supposed
>>>>>>>> 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
>>>>>>>> parcels
>>>>>>>> work (i.e. vj, etc.), the less this makes sense.
>>>>>>>> So, basically, every cell in the table would be a separate
>>>>>>>> and
>>>>>>>> these parcels need to be organized into rows and columns.
>>>>>>>> track
>>>>>>>> of the columns and the placement of the rows has some level
>>>>>>>> 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
>>>>>>>> right):
>>>>>>>> 1) The logic of placing the table parcels relative to the
>>>>>>>> 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
>>>>>>>> especially true for tables that might span more than one
>>>>>>>> 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
>>>>>>>>> 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
>> 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
>>>>>>>>>> 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>
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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

View raw message