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.


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]

Reply via email to