Issues to follow up: - Absent markers lead to ClassCastException in LineLM.getNextBreakPoss() line 409 preceded by message (in RetrieveMarkerLM) "found no marker with name: ..." - Markers with only a CDATA child node leads to ClassCastException in Marker.rebind() line 72 - Markers with fo:block child node leads to ClassCastException in LineLM.getNextBreakPoss() line 409 preceded by message (in RetrieveMarkerLM) "retrieved: org.apache.fop.layoutmgr.InlineStackingLM..."
Created attachment 13470 [details] FO to demonstrate described problems
I implemented InlineLevelLM in RetrieveMarkerLM. That cures some of the ClassCast Exceptions. The exceptions in Marker.rebind are due to the recent change of FOText from FObj to FONode. That change has not yet been made in this method.
Thanks for the assist, Simon. I noticed the problem in Marker.rebind() as well... and was wondering Since: 1. all FObjs are also FONodes 2. FOText has its own bind() method maybe we could cast i.next() to FONode first, to check the base class: FONode childNode = (FONode) i.next(); Then test: if( childNode.getClass().equals("class org.apache.fop.fo.FOText") ) And based upon the result of that test, cast to either FObj or FOText... Sound like a good idea, or would this be classified as 'sloppy'? (Alternative could be to try-and-catch the ClassCastException, but IIRC this is considered bad practice...) BTW: stumbled upon the Joerg's favourite dreadful nested 'block-inline-block' problem --which throws ClassCastExceptions in InlineLayoutManager
On second thought... simply using: if( childNode.getName() == null ) seems even better to test whether it's an FObj.
...but this leads to yet another CCE, this time in RetrieveMarkerLM.getNextKnuthElements() line 82
...due to the retrieved LM being an InlineStackingLM?? Where does that come from? Shouldn't that be a TextLM?
[Andreas] >Then test: >if( childNode.getClass().equals("class org.apache.fop.fo.FOText") ) Just using instanceof (i.e., childNode instanceof FOText) should be sufficient--I implemented a similar change in fo.flow.Block when I switched text nodes from FObj to FONode. Thanks, (and sorry for the oversight--let me know if I can be of help here) Glen
Yes! I just *knew* there was a much more obvious way of testing that. Thanks Glen (--still enjoying himself in Vegas, I presume?)
Committed a fix in Marker, which cures the ClassCastException in Marker.rebind(). Now all markers lead to a ClassCastException in RetrieveMarkerLM.getNextKnuthElements(), line 81. This should be cured by removing the LMs for fo:marker and for fo:retrieve-marker: at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree): ... | parentLM | RetrieveMarkerLM | InlineStackingLM ---+--- | | chldLM1 chldLM2 but, as a marker can only have children which could replace its retrieve-marker, wouldn't it be better to have just: ... | parentLM ---+--- | | chldLM1 chldLM2 (Luca Furini at fop-dev)
Removed RetrieveMarkerLM. The LMs of the marker children are attached in the LM tree as the direct children of the LM of the parent of the RetrieveMarker.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed