https://issues.apache.org/ooo/show_bug.cgi?id=121479
--- Comment #8 from Andre <[email protected]> --- I know now a bit better what goes wrong: RTF document content is stored as nodes in a node array. Some content is organized as "fly frames", blocks of text or parts of a table, that are displayed at a position that differs from their logical position in the document. While the RTF document is read, adjacent fly frames that also have the same properties, are merged into larger fly frames. Later the fly frame nodes are moved inside the node array to their final location. There seem to be too problems with that: 1) The merging of fly frames seems not to be working correctly. Look at a part of the bug document, nodes 13 to 27. Five text nodes are each enclosed by one start and one end node: 13: start node ends at 15 14: text node 15: end node starts at 13 16: start node ends at 18 17: text node 18: end node starts at 16 19: start node ends at 21 20: text node 21: end node starts at 19 22: start node ends at 24 23: text node 24: end node starts at 22 25: start node ends at 27 26: text node 27: end node starts at 25 Lets assume that we have two fly frames that reference the single nodes 17 and 20. When they are merged the result is the node range 17 to 20. This includes the end node of text node 17 and the start node of text node 20. But not the start node of 17 nor the end node of 20. This leads to a followup bug when the merged fly frames are moved to their final position. In SwRTFParser::SetFlysInDoc() there is some magic that adapts the start and end nodes of fly frames. While this works for the end, it does not work for the start node. This results in the pathological situation that ultimately triggers the crash/loop where the merged and adapted fly frames cover one half and one complete table. Moving the fly frames works from end to start. Therefore the second and complete table is moved without problem, the first and incomplete table is not moved correctly and leads to the error. 2) The SwNodes::_MoveNodes() method seems to have problems in some cases. In one experiment fly frames where not merged. This resulted in more but smaller fly frames. Moving them to their final location resulted in a completely broken document. Apparently there are some constellations of start, end, and destination index that are not handled correctly. Also, the case mentioned above where one half and one complete table are moved the first half table should be handled correctly because the given start node, that points into the middle of the table, is ignored. Instead the end node is asked for the real start node. But this move still results in the error described by this bug. -- You are receiving this mail because: You are on the CC list for the bug.
