Jeremias Maerki wrote:
> Wow, what complexity/effort for so little gain. I guess there's no way

It’s not complicated; no more than adding one area for the whole row. 
And it needs to be done anyway! And that allows to address all issues at 
the same time: border-separation filled with table background, as well 
as background of row/column-spanning cells which must be taken from the 
first spanned row/column. Only the placement of images is a bit tricky.

> around adding reference values to the area tree so you can redo the
> percentage calculations in the renderer without the FO tree percentage
> infrastructure. But that doesn't really feel right.

Well I don’t need to redo any percentage calculation. I just need the 
table’s IPD when adding the row background. But it isn’t accessible in 
the TraitSetter.addBackground method, which is LayoutManager-agnostic. 
But I have a workaround in mind that I’ll try to implement.


> The only other possibility to me seems to investigate what we've talked
> about once or twice in the past: Going for a different style of area
> tree and use absolute coordinates instead of relative coordinates there.

AFAICT that won’t help to retrieve the ipd of the row (table).


> But switching just for covering this feature...I don't know. If this
> were investigated in the context of the new intermediate format it might
> suddenly make sense again but I haven't thought this through.
> 
> So in the end, I don't have any really good ideas right now.

<snip/>

Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to