xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Indent Inheritance and Collapsing Border Model
Date Wed, 07 Dec 2005 15:19:56 GMT
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


Mime
View raw message