Hi Andreas, Manuel,
Andreas L Delmelle wrote:
> On Dec 14, 2007, at 01:59, Manuel Mall wrote:
> Hi Manuel, Vincent,
>> Just a quick question coming from someone who has absolutely no clue
>> what you are really doing and just based on the commit comment.
>> We have been 'bitten' before by moving things into the fo tree only to
>> out that it doesn't work when it comes to fo:markers as they inherit the
>> environment from where they are retrieved into not from where they come
>> from. Is that possibly an issue here?
Normally not. The code dealing with border resolution is only triggered
for tables which are not descendants of a marker (there are !inMarker()
guards wherever needed —which as some point will need to be replaced by
something more elegant).
The basic idea is this: when a table is a descendant of a marker,
nothing more is done than recording its children FO elements; only when
the table is retrieved will the FO tree be properly built, with implicit
columns creation, border resolution, etc. (see
> I too haven't looked very closely at Vincent's changes, but he did
> manage to implement something that up to now, I have only speculated to
> be possible, so I am VERY interested ;-)
> There is already one certainty that should make things much more
> straightforward here:
> fo:tables in retrieved fo:markers can, by definition, not have any
> Since, as I recall, it should be possible to resolve/collapse /all/
> borders in a table in the FO Tree, provided it does not span multiple
> pages, I wouldn't suspect any problems here.
Well, even if the table spans multiple pages, IIC. See the javadoc of
fo.flow.table.ConditionalBorder and please tell me if there is anything
unclear. I’ll try to improve the code readability later on.
> Borders are also not inherited
They are, in one case: when using the "inherit" keyword.
> , and IIC, it is not possible to put, for
> example, separate fo:table-rows in fo:markers that will be retrieved
> into a fo:table-body in a static-content.
Indeed no, because fo:retrieve-marker can only be put where #PCDATA,
%block; or %inline; are allowed, which is not the case for fo:table-body
(nor any other table element except fo:table-cell).
> But this is all theoretical, so up to Vincent to confirm...
Yes I confirm that in theory, everything should work fine :-P
(Actually there are a few testcases in the repository with tables in
markers that confirm that to a certain extent –and helped me debugging
Vincent Hennebert Anyware Technologies
Apache FOP Committer FOP Development/Consulting