Keiron Liddle wrote:
Marker handling is deferred until area tree construction. Not all of the FOs that can have markers have been fitted with handling yet, but the model for it at the FO tree building level is as follows (from FoListBlock.java). The table-row comment, which I just noticed, is a hang-over from another FO.The only questions I have at the moment: - are markers handled properly, you mentioned something about that earlier so maybe it is dealt with already - what about arbitrary xml anywhere for extensions, is that still possible (also instream-foreign-object but that is probably okay) I know it is not a spec thing but it can enhance using FOP for many users.
/** The number of markers on this FO. */
private int numMarkers = 0;
/** The number of list-items on this FO. */
private int numItems = 0;
/** The offset of 1st table-row within the children. */
private int firstItemOffset = -1;
....
while ((ev = xmlevents.expectStartElement
(FObjectNames.MARKER, XMLEvent.DISCARD_W_SPACE))
!= null) {
new FoMarker(getFOTree(), this, ev, stateFlags);
numMarkers++;
ev = xmlevents.getEndElement(xmlevents.DISCARD_EV, ev);
pool.surrenderEvent(ev);
}
There is no provision for extension elements, apart from the keeping track of incoming elements with variant namespace declarations. In terms of the inherent input validation of pull parsing, the checking of foreign namespace elements could be inserted in the get/expect processing of the FOs. The FO generation is already generalised (most Fo? elements are nto named in the code, and are generated by the makeFlowObject() method of FObjects, so generalising the validation of foreign elements should be feasible. The semantics of such objects is always going to be more of a problem.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
