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.li...@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.li...@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" <aha...@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" <gavha...@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" <harbs.li...@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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >> > > > >
