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
