[EMAIL PROTECTED] wrote:
> The markers work fine
> except in one instance: if ROW4 and ROW5 overflow into the next page, the
> retrieve marker will pull ROW5MARKERDATA1 and ignore ROW4MARKERDATA1 even
> though ROW 4 is a distinctly new row. If more than two rows overflow, it
> seems to work OK (i.e. if ROW3,ROW4 and ROW5 overflow, it pulls from ROW3).
This could have something to do with the spilling
algorithm. The ROW4 is added to a page, with markers,
then it is discovered not to fit, the layout is undone
and the row goes onto the next page. It is quite
possible that markers aren't handled properly in this
case.
There *could* be problems with rendering areas if
the marker isn't the first child of the FO it marks,
though I was unsuccessful so far to construct one.
> I do get several "ERROR [fop]:fo:marker
> must be an initial child,and 'marker-class-name' must be unique for same
> parent" messages,
Markers which cause the latter message are ignored. You should
fix these errors.
The first message can already be caused by whitespace preceding
the marker, like
<fo:table-cell>
<fo:marker ...>
(you see the whitespace, don't you?)
This is usually not a real pressing problem, though it is
always advisable to fix error messages as well as warnings,
lest you ignore something important.
> but I thought these were a function of markers in 20.2.
Duh?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
