/!\ This page does not apply to the current design anymore. It was written prior to switching to the Knuth approach. It may still hold some interesting information, though.
BP signalling a full page
The layoutengine testcase test-markers5a.xml is a carefully constructed page, which can hold 4 blocks of BPD 14400 = 57600 total (4 lines). This is the Area Tree of the body of page 1:
When block 4 ends, the target BPD of 57600 has not been exceeded. Therefore block 5 starts
getNextBreakPoss. When the first BP is returned, the target BPD is exceeded, the child LM is reset, and a BP is created with the flag
BreakPoss.NEXT_OVERFLOWS set to true. The BPD of this BP is zero. Therefore this BP's only role is to signal the page break. Nevertheless an area is created for it. This area acts as the first area generated by the block fo, and therefore the corresponding marker is set. A recent patch prevents this by using the flag
This bogus BP might also get the
BreakPoss.ISFIRST flag, which would also be inappropriate.
BlockLM may return a BP which does not generate an area in the following cases:
- The returned BP causes overflow and is reset. This was the first BP of this block. That means that the block was started just before the page break. See FOP's testcase markers5a.xml. The BP has a position of
childBreaks.size() - 1 = -1.
- The Block is empty. The BP has a position of
FINISHED_LEAF_POS = -2. Such a BP does not generate an area.
- The Block has a page break just before its end; after the page break its childLMs return no further BPs. That is not possible, because a page break is decided by:
- a BP that causes overflow of the page; this BP is reset and reappears on the next page;
- a BP that has the
NEXT_OVERFLOWSflag set; that means that the childLM has more content.
Would it be a good idea to just omit the BPs of cases 1 and 2?
This is a nasty case:
when the text 'Several...' starts on the new page. There would again be an empty area on the previous page, which would qualify as
is-first. It is a combination of 2 and 1, but the position of the BP is 0. This can be aggravated by having several empty blocks at the end of the page.
Can an empty FO element have markers?  If so, BPs under case 2 should be generated and be allowed to set markers (current situation). Around a page break it would not be defined to which page the marker would belong. The spec does not seem to rule it out. But it speaks about the area to which a marker is associated. A marker in an empty block would not be associated with an area, or is an area of bpd = 0 a valid area? 
BlockLM has a boolean member
isfirst, which starts out as true. When a BP is returned which generates a real area and
isfirst == true, the BP gets the flag
BreakPoss.ISFIRST, and isfirst is set to false. When the LM
isFinished(), the BP gets the flag
BreakPoss.ISLAST. Note that an area can have both the
 Yes, this is valid. fo:markers are permitted on any descendant of an fo:flow. The question is rather if this makes sense. BTW, markers5b.xml is such an example. (JM)
 I think this is valid. Reason: 6.5.2 says, that fo:block generates one or more normal block areas. An empty fo:block creates exactly one area with bpd=0. (JM)