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