table overflow and markers on 20.2

[Lo...@log-net.com]

I just experienced some bizarre marker/table behavior that I hope someone
can shed some light on.  I am using fop 0.20.2.  Here is the scenario:

Say I have a table that has rows of data and marker data:

ROW1DATA1    ROW1DATA2    ROW1DATA3    ROW1MARKERDATA1
ROW2DATA1    ROW2DATA2    ROW2DATA3    ROW2MARKERDATA1
ROW3DATA1    ROW3DATA2    ROW3DATA3    ROW3MARKERDATA1
ROW4DATA1    ROW4DATA2    ROW4DATA3    ROW4MARKERDATA1
ROW5DATA1    ROW5DATA2    ROW5DATA3    ROW5MARKERDATA1

The marker data is being used for running headers on each page
(retrieve-position=first-starting-within-page).  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).

Am I doing something wrong here?  I do get several "ERROR  [fop]:fo:marker
must be an initial child,and 'marker-class-name' must be unique for same
parent" messages, but I thought these were a function of markers in 20.2.

-Lou



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: table overflow and markers on 20.2

["J.Pietschmann" <j3...@yahoo.de>]

Louis.Masters@log-net.com 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org