Hi Arved (and other interested parties),
Lots of other bugs (like the inline-area height) show up well in tables
because the grid makes things visible. That's the case with the trailing
white-space bug I saw the other day, resulting in an empty table row.
Some of these can also be shown by using border, padding and background
on fo:block, which also needs more test cases.
I think base-level table functionality has gotten considerably better,
and we need to publicize that with the next release, since there have
been so many problems in the past releases. Of course, I know there are
still a number of bugs, but I think the row-spanning, vertical alignment
and general border-handling improvements should help lots of people.
Off the top of my head, here are major areas for work:
1. border-collapse=collapse. There is a partial bandaid for this now.
I've written a lot of pseudo-code for this, as the general case is quite
complex. It should take into account cell, row and column borders
(though I'd like to see the final word in the PR on this). As often, I
ran up against the problem of handling the break conditions, since that
can affect the borders. But unless someone else has done lots of work
here or has some easy improvements, I'd like to keep it on my plate
(after vacation).
2. Keeps and breaks. There are some cases where breaks cause problems;
as I recall the culprit is in table-body. I know the general problem of
keeps can't really be handled, but tables are a particularly sore point
for that. It's worth trying to do keep-together for table-row; actually
I think I did a first pass on this when I did spans.
3. Handling limit conditions, like table-row with keeps but which
doesn't fit on the page.
4. Indents. Just looked at Koen's bug, which involves the indents not
affecting the table itself, but rather the cell content. My reading of
the CR is that the areas created by fo:table are block areas and should
be positioned by indents. Lots of people also want to center their
tables; I can't figure out how this is supposed to happen, unless it's
in table-and-capation.
5. The table-and-caption fo.
6. Row-less tables using start-row and end-row properties on the cells.
I think this can be handled in addChild for the table-body by creating
"fake" TableRow objects as needed.
7. Automatic table layout style (this is a fairly big deal). Or at least
really implement the percentage stuff, which would be simpler and still
quite flexible. This needs some work in calculating the column widths
once the size of the containing reference area is known.
8. The relative-align style for vertical alignment. Needs
post-processing once all cells in the row are done. Might as well wait
until we get our line-stacking straightened out.
That should keep people thinking for a while...
There are also a few remarks below. I'll be away from my Internet access
for a while, so this is probably it for now. Overall the idea seems
good. Obviously if I've temporarily let go of bottom-up layout, it was
to try to reduce the volume of table-related complaints.
Regards and "a bientot"
Karen
Arved Sandstrom wrote:
>
> Hi, Karen (and other interested parties)
>
> A thought occurred to me just now. A high percentage of our bandwidth (and
> bug reports) are devoted to tables. There are so many table-related bug
> reports mainly because so many folks want to use tables, I believe, not
> because there are more bugs in tables than elsewhere.
>
> I'm thinking that perhaps we can use table support as the centrepiece for
> all of our FOP efforts. In order to have tables be fully supported, and work
> properly, a really big percentage of the XSL specification (and FOP
> mechanics) gets exercised. Redesign of layout is something of a fuzzy goal;
> making tables work isn't.
>
> You've currently got probably the best perspective on tables. What I am
> thinking would be useful would be a report concerning table FOs, with a
> property-by-property breakdown, that assesses what works, and what doesn't,
> and what needs to happen in order to make things work. This could drive a
> whole bunch of tasks that people could take on. It would be easier to gauge
> the progress of FOP, because table support would be a bellwether for FOP as
> a whole.
>
> This doesn't mean that everything else would be ignored. But the shift of
> emphasis would be as follows: if I want to work on markers, I make sure that
> they work inside fo:table-and-caption, fo:table, fo:table-caption,
> fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If
> someone wants to make sure FO X works, they make sure it works also as a
> descendant of fo:table-cell. Keiron has laid the groundwork for testing - a
> really suitable area for a first comprehensive set of test-cases could be
> (you guessed it) tables! :-)
KL: Agreed. I started to do some test cases, but then discovered I
needed to add more properties to the AreaTree concerning borders and
padding. I didn't get around to doing this, so we can put that on the
list.
> It would be really cool if you could generate such a report concerning table
> status - we could generate tasks from the description of unimplemented or
> work-in-progress features, and take it from there. My concern at the moment
> is that a lot of what we have is somewhat superficial - things that work on
> fo:block begin to break down when blocks are nested, or occur inside lists
> and tables. I'm as guilty of this as anyone, I figure. Having one central
> major area that we can concentrate on allows us to get to the point where
> things work everywhere they are supposed to.
KL: I think that if we correctly implement layout of FOs with respect to
their containing reference areas, layout of fo:xxx in a table shouldn't
be an issue. On the other hand, as you say, if it looks wierd in the
table, it probably means there is a bug in the layout of the fo:xxx
itself.
> This is an initial thought. I'm certainly not trying to pile more work on
> your shoulders, but I genuinely believe that this is a good route to follow,
> and you can be of great assistance here.
>
> Thanks,
> Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
