OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] two-column problem

At 20:44 2003 06 19 +0200, Lars Trieloff wrote:
>>> The bug is in XSL FO stylesheets, and, in my opinion, it should be
>>> fixed. If Antenna House demonstrates a non-compliant behaviour,
>>> it can be used in the corresponding customization level; but the
>>> base stylesheets should not rely on it.
>The XSL-FO stylesheets should follow the XSL-FO specification, but they should also make it possible to span columns. As Bob points out, it should be very difficult with the current architecture of stylesheets.
>>Looking at the DocBook XSL stylesheets, this could be
>>tough to implement.  The stylesheets often nest fo:blocks
>>as nested DocBook elements are processed.  If a column
>>span is requested in some nested element (like a table
>>in a section in a chapter), then all pending blocks would
>>have to be closed out, a new block started that is a direct
>>child of the fo:flow, and then start over with the blocks
>>that follow the table.
>>Or the stylesheet architecture would have to change
>>to a much flatter sequence of blocks that are direct
>>children of the fo:flow.
>In any case, this means a lot of work and many changes to the XSL-FO-
>stylesheets. I You need results fast, I would rely on a "broken" XSL-FO processor and include support for this "broken" processor in the parametrization of the stylesheets.

Everything said to date is correct (about what the XSL spec
says, about how hard it would be to follow it, and about
the fact that some implementations don't enforce this

Arbortext's XSL FO implementation is another one that does
not enforce this problematic restriction.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]