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
>> about
>> 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
>> find
>> 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 
fo.flow.RetrieveMarker#cloneSingleNode).


> 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
> page-breaks.
> 
> 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 
things.)


Cheers,
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