On May 13, 2008, at 16:01, Andreas Delmelle wrote:
Before the changes I made, this sequence would also result in an Inline area, which would cause a ClassCastException during the addAreas() phase. Instead, the check in FlowLM was put there to filter the InlineKnuthSequence out, and signal an error/warning if the fo:wrapper was a descendant of the fo:flow.
Note to self: when I fix the WrapperLM's element-generation, the check should no longer be necessary. The only item that may result in inline-areas, and at the same time be a descendant of the fo:flow, is a fo:wrapper. Text under the fo:flow will be ignored (behavior may be revisited at some point), fo:inline (or something equivalent) will lead to a ValidationException at parse-time.
