The problem is that a paragraph needs a terminator. So, it has to have a
SpanElement in addition to the TableElement. Adding the span for the terminator
caused all sorts of issues which sent me down the rabbit hole today.
There’s two ways I can see to go:
1) Instead of nesting a table inside a
In HTML, I thought Table defaults to a block element, effectively ending
the paragraph.
If that's true, then:
some text (table content) more text
Should be re-factored as:
some text (table content) more text
And then table would have its own TextBlock?
-Alex
On 6/11/14 8:25 AM, "Harbs" wr
FYI:
I’ve been having a really difficult time resolving content with TextBlocks. I
can’t seem to work within TextBlocks and keep the tables outside a composed
TextLine. Making the width really wide just messes things up.
I tried keeping the table outside the TextBlock, but that causes all kinds
On Jun 10, 2014, at 11:10 PM, Alex Harui wrote:
>
>>> 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 unders
>>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
>cell
On Jun 10, 2014, at 10:26 PM, Alex Harui wrote:
>
>
> On 6/10/14 12:06 PM, "Harbs" 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 use
On 6/10/14 12:06 PM, "Harbs" 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
Import/Export is a good question. What’s the use case for Export?
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
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.
-A
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
On 6/10/14 1:20 AM, "Harbs" 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.
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 childre
On 6/9/14 1:09 PM, "Harbs" wrote:
>Here¹s a wacky idea:
>
>I can leave tables as group elements for managing table cell elements and
>formatting inheritance purposes.
>I can introduce a TableLeafElement class whose sole purpose is describing
>the contents of the table and satisfying getLeaf() c
Here’s a wacky idea:
I can leave tables as group elements for managing table cell elements and
formatting inheritance purposes.
I can introduce a TableLeafElement class whose sole purpose is describing the
contents of the table and satisfying getLeaf() calls. I’d override getLeaf()
for TableEle
Bah!
I’ve been relying on replaceChildren(), findChild(), etc.for TableCellElements.
None of that will work if I change TableElement to a leaf…
I could really use multiple inheritance.
Why was TLF designed that elements are either leaf elements of group elements?
Couldn’t elements conceivably
OK.
I’ll see how it goes...
On Jun 9, 2014, at 9:31 PM, Alex Harui wrote:
> OK, I guess TLF doesn't really have block elements. I was just wondering
> if there would be some problem further down the line. Folks seem to want
> to have TLF elements work like HTML elements.
>
> I was pondering
OK, I guess TLF doesn't really have block elements. I was just wondering
if there would be some problem further down the line. Folks seem to want
to have TLF elements work like HTML elements.
I was pondering if you next had to support DIV and if block elements
should first be introduced to TLF.
That’s pretty close to what I already did. Table composition is all working
very well as each table cell acting as a separate TextFlow and container.
Except extending InlineGraphicElement does not make sense. There’s a lot of
code in there dealing with loading assets which is not applicable to t
I'm not an HTML expert, but they seem to divide up their elements between
those that default to "inline" and those that default to "block". I think
in TLF, SpanElement and InlineGraphicElement are inline and
ParagraphElement is "block". I haven't really thought through this, but
one possible stra
I have not yet implemented arrow navigation (beyond what was there originally),
but here’s my plan:
* When text outside the table is selected, arrow navigation would treat the
entire table like a single atom (i.e. if the cursor is right before, a right
arrow will move the cursor beyond the tabl
What is the leftArrow/rightArrow navigation model when Tables are involved?
Also, in HTML, isn't a Table a block-level element? Are there other
reasons for making it a leaf? Shouldn't Table be more like
ParagraphElement?
-Alex
On 6/8/14 10:48 PM, "Harbs" wrote:
>My real concern is the fact t
My real concern is the fact that findLeaf() is used in so many places. It makes
the assumption that you can find a leaf by index anywhere in a text flow. That
assumption falls apart with tables. I make a clear separation between tables
and their contents. As far as the text flow is concerned, th
Hmm. The doc says that FlowLeafElement doesn't have any children. But
Tables can certainly contain other tables, right? And aren't the
headers/rows/cells considered children?
FlowLeafElement also has a text property. Are you going to be overriding
that?
Is it just too hard to make a TableElem
23 matches
Mail list logo
