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! :-)
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.
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
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
