Hi Keiron,
>. . .
> We should be able to set common objects like the logging and config on
> the structure handler itself.
> But the context idea could be useful for other objects that it may need
> to access.
>. . .
ok, It wasn't clear for me either what would go into the context object, but
it is certainly better that passing the FO object directly.
>. . .
> I'm not sure about the best way to do things like the table columns. It
> would be simpler if it could do a start table after it has all the table
> columns rather than needing to get each table column individually
> through method calls.
>. . .
Would this scenario be easy to implement?
startTable
startRow (maybe after all FOs for the row have been parsed)
startCell (maybe after all FOs for the cell have been parsed)
start/end stuff for cell contents
endCell
more start/endCell
endRow
more start/endRow
endTable
or do you mean just one startTable with row/columns contained in the FO?
I'd prefer many event calls, as the StructureHandler wouldn't need to know as
much about FOs in this case. Conceptually (and this might be useful for
concrete stuff like testing too), I think the StructureHandler needs to
be able to rebuild the XSL-FO structure with as little code as possible.
Maybe (if easier to implement or to avoid slowing down PDF
rendering) this "event generation" can be done by an intermediate component
that "decodes" the FOs and generates detailed events?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
