On the other hand, HTML has row-level styling / compositing. So it might be easier to work internally with rows/cells rather than cells directly.
IMO, not supporting vertically joined cells is acceptable. Maurice -----Message d'origine----- De : Avi Kessner [mailto:akess...@gmail.com] Envoyé : mercredi 4 décembre 2013 14:33 À : dev@flex.apache.org Objet : Re: TLF Tables 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/1sT0IAiMfIOBVgmo8wwF6ZZviuNFcW2bUfQ > oj > >>>>>>> 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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >> > > > >
