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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >
