Indent Inheritance and Collapsing Border Model

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Hey gang,

There are two issues I'd like to discuss. They come from feedback from
customers:

The first concerns indent inheritance which I documented in [1]. It
turns out that most commercial implementations decided to deliberately
break indent inheritance to work around the expectations of
inexperienced XSL-FO users. This obviously breaks the specification and
it creates an interoperability issue. This becomes an issue, especially
since I know a few companies that would like switch from commercial
implementations back to Apache FOP now that it's "more usable" now. I've
asked the XSL WG in [2] on their updated opinion about the issue. There
are arguments in both directions.

So what I'd like to do is implement the alternative behaviour as a
configurable option in the FO tree. The default would still be what the
specification describes (see [1]), but users would be able to set a
switch that would make FOP reset start-indent and end-indent to zero in
cases where in the area tree a reference area boundary would be crossed
(block-containers and table-cell, mainly).

[1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
[2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0024.html


The second issue is about the collapsing border model. Currently, having
an fo:table with no explicit border-collapse="separate" results in a
warning message in the log as well as frequent exceptions due to the
fact that this border model not completely implemented. I would like to
modify the FO tree in a way that a table always reports being in
separate border model mode. The other idea would have been to change the
default but I don't particularly like that approach because it breaks
the spec. Obviously, this is only a temporary measure until the
collapsing border model becomes usable. I was recently thinking about
doing a scaled-down implementation which ignores the tricky interactions
between headers/footers and the table-body. But my priorities here are
not particularly high, so it might be some time until I get to this.

Any objections? Comments?

Thanks,
Jeremias Maerki

Re: Indent Inheritance and Collapsing Border Model

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Both proposed changes are now implemented. I'm not sure if I got
everything right WRT the indent behaviour. I guess I'll have to wait for
feedback from those people who wanted that "feature" in the first place.

http://svn.apache.org/viewcvs?rev=354763&view=rev
http://svn.apache.org/viewcvs?rev=354075&view=rev

On 01.12.2005 12:53:56 Jeremias Maerki wrote:
> Hey gang,
> 
> There are two issues I'd like to discuss. They come from feedback from
> customers:
> 
> The first concerns indent inheritance which I documented in [1]. It
> turns out that most commercial implementations decided to deliberately
> break indent inheritance to work around the expectations of
> inexperienced XSL-FO users. This obviously breaks the specification and
> it creates an interoperability issue. This becomes an issue, especially
> since I know a few companies that would like switch from commercial
> implementations back to Apache FOP now that it's "more usable" now. I've
> asked the XSL WG in [2] on their updated opinion about the issue. There
> are arguments in both directions.
> 
> So what I'd like to do is implement the alternative behaviour as a
> configurable option in the FO tree. The default would still be what the
> specification describes (see [1]), but users would be able to set a
> switch that would make FOP reset start-indent and end-indent to zero in
> cases where in the area tree a reference area boundary would be crossed
> (block-containers and table-cell, mainly).
> 
> [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
> [2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0024.html
> 
> 
> The second issue is about the collapsing border model. Currently, having
> an fo:table with no explicit border-collapse="separate" results in a
> warning message in the log as well as frequent exceptions due to the
> fact that this border model not completely implemented. I would like to
> modify the FO tree in a way that a table always reports being in
> separate border model mode. The other idea would have been to change the
> default but I don't particularly like that approach because it breaks
> the spec. Obviously, this is only a temporary measure until the
> collapsing border model becomes usable. I was recently thinking about
> doing a scaled-down implementation which ignores the tricky interactions
> between headers/footers and the table-body. But my priorities here are
> not particularly high, so it might be some time until I get to this.
> 
> Any objections? Comments?
> 
> Thanks,
> Jeremias Maerki



Jeremias Maerki

Re: Indent Inheritance and Collapsing Border Model

[Andreas L Delmelle <a_...@pandora.be>]

On Dec 1, 2005, at 12:53, Jeremias Maerki wrote:

Hi,

> There are two issues I'd like to discuss. They come from feedback from
> customers:
>
> The first concerns indent inheritance which I documented in [1].
> <snip />

+1 for making this configurable.

>
> [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
> [2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/ 
> 0024.html
>
>
> The second issue is about the collapsing border model. Currently,  
> having
> an fo:table with no explicit border-collapse="separate" results in a
> warning message in the log as well as frequent exceptions due to the
> fact that this border model not completely implemented. I would  
> like to
> modify the FO tree in a way that a table always reports being in
> separate border model mode.

Easiest way, I guess, would be to expand the already existing test in  
fo.flow.Table.bind()... Weird that this wasn't already being done. I  
must have read over that bit a hundred times, and never wondered  
about it, but indeed, it's almost like saying: "Not implemented, and  
now we're going to prove it to you by just continuing as if it  
were... Who knows, maybe you're lucky." :-)

+1

Cheers,

Andreas

Re: Indent Inheritance and Collapsing Border Model

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 01.12.2005 13:30:05 Luca Furini wrote:
> Jeremias Maerki wrote:
> 
> > The first concerns indent inheritance [...]
> > 
> > So what I'd like to do is implement the alternative behaviour as a 
> > configurable option in the FO tree. The default would still be what the 
> > specification describes (see [1]), but users would be able to set a 
> > switch that would make FOP reset start-indent and end-indent to zero in 
> > cases where in the area tree a reference area boundary would be crossed 
> > (block-containers and table-cell, mainly).
> 
> I agree with the need to provide users what they expect, but I did not 
> understand where this switch will be: 

I did not say.

> in the configuration file (+1) or in 
> the document itself as an extension property / element (not so 
> enthusiastic about that)?
> 
> In the first case the file would be correct, only its rendering will be 
> "deliberately wrong": the user is aware that he is requiring a 
> non-standard rendering *to the formatter*.
> 
> In the second the document itself would require a non-standard rendering, 
> which only our implementation will provide; in other words, it seems to me 
> that this solution would give the impression that the file itself is 
> enough to achieve the expected result, while it is not.
> 
> Or maybe you were thinking of something else?

No. The second idea would kill the effect of the change. Someone would
still have to modify a stylesheet to make it work with FOP. That is not
the idea. I assume it will be good enough to control the option via the
user agent and indirectly through the configuration file.

> > The second issue is about the collapsing border model. Currently, having 
> > an fo:table with no explicit border-collapse="separate" results in a 
> > warning message in the log as well as frequent exceptions due to the 
> > fact that this border model not completely implemented. I would like to 
> > modify the FO tree in a way that a table always reports being in 
> > separate border model mode. The other idea would have been to change the 
> > default but I don't particularly like that approach because it breaks 
> > the spec. Obviously, this is only a temporary measure until the 
> > collapsing border model becomes usable.
> 
> I agree with you, I prefer the first option.

Thanks for your feedback.


Jeremias Maerki