On Jun 10, 2014, at 10:26 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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.
Using this plan, import should work. > 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. When I say implicit wrapping, I mean it’ll add the wrapping only if necessary. If the table/cell content is wrapped in a TextFlow/p tag, the explicit one would be used instead of the implicit one. > 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? Not sure I understand what you’re asking. The way I’m currently handling cells, is by creating containers for each one. Tables are composed using TextFlowTableBlocks for each visual section of the table. > -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 >>>>> >>>> >>> >> >
