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.



Vincent Hennebert                            Anyware Technologies
Apache FOP Committer                         FOP Development/Consulting

Reply via email to