On 6/10/14 12:06 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>Import/Export is a good question. What’s the use case for Export? No idea. I don't know how much it is used, but I would assume being able to go back and forth between TLF and HTML would be useful. I certainly remember folks trying to import HTML. Having implicit items and/or wrapping on import but not unwrapping on export could create problems where, after several import/exports, things are now wrapped multiple times. Just wondering, did you consider a plan where you tell TLF that the table is another container? Or maybe each cell is another container in row-major order? Would that eliminate some or all of these issues? -Alex > >Is it important to have valid HTML on export, or is export more of a >convenience method to be able to re-import content back into TLF? > >There’s actually another import/export issue beyond tables within >paragraphs. Namely TextFlows inside cells. > >Here’s what I’d *like* to do: > >1)Import should allow implicit items. If a structure such as this ><table><tr><td>some <b>important</b> content here.</td></tr></table> >should be equivalent to this: <table><tr><td><TextFlow>some ><b>important</b> content here.</TextFlow></td></tr></table> > >2) Export could either keep, or drop the extra <TextFlow>. I’d go for >keeping it, because there might be pertinent markup in the TextFlow. The >same would go for wrapping <p> tags around the table. I’d rather keep >them in. > >On Jun 10, 2014, at 9:57 PM, Alex Harui <aha...@adobe.com> wrote: > >> OK, good luck. The only concerned that occurred to me is that it could >> make import/export trickier. Will you always unwrap the paragraph from >> around the table or could there be situations in the future, like if you >> do allow inline tables, where you will have to guess whether to unwrap >>or >> not. >> >> -Alex >> >> On 6/10/14 11:53 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> Coming from InDesign, it does not seem so hacky to me. That’s how >>> InDesign handles tables. >>> >>> Extending Paragraph has its own set of issues. A paragraph is expected >>>to >>> have a TextBlock which represents the text as the children within the >>> paragraph. That does not work well with cells. If the table is a child >>>f >>> the paragraph, that should not be a problem. >>> >>> There’s actually an advantage to have table be a child of a paragraph. >>>It >>> could theoretically be composed inline to text on the same line as >>>other >>> span text ― although I’m not planning on doing that at this point. >>> >>> Harbs >>> >>> On Jun 10, 2014, at 7:58 PM, Alex Harui <aha...@adobe.com> wrote: >>> >>>> >>>> >>>> On 6/10/14 1:20 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>>> This seems to be working well. >>>>> >>>>> Next problem: >>>>> >>>>> https://github.com/Harbs/TLF-Table-Work/issues/29 >>>>> >>>>> TLF assumes in quite a few places that all leaves belong to a >>>>> paragraph. >>>>> If tables can be siblings of paragraphs (as it stands now), this will >>>>> not >>>>> work. >>>>> >>>>> I¹m thinking of requiring tables to be children of paragraphs. I >>>>>cannot >>>>> think of any obvious problems with this. Anything obvious that I¹m >>>>> missing? >>>> >>>> Bummer. Seems hacky, but no real objections. Did you consider making >>>> Table extend Paragraph? >>>> >>>> -Alex >>>> >>> >> >
