On Tuesday 19 July 2011, Caolán McNamara wrote:
Well, this'll work I guess, and I'm minded to push it, but why ;-) Is there a concrete bug this fixes ?
Yes, but it is a little obscure. If you take the attached ODT file, save it as an RTF, and then load the RTF, the prefix to the paragraph number will be wrong ("\x05(" instead of "(["). With the patch, it works. The problem is that in this file, the leveltext field in the number format is (correctly) exported to RTF as follows: \'05([\'00]) Without the patch the embedded NUL gets dropped, so the resulting string on reading is: "\x05([])" With that string, the following test in rtfnum.cxx fails: if( DelCharAtEnd( sLvlText, ';' ).Len() && sLvlText.Len() && sLvlText.Len() == (sal_uInt16)(sLvlText.GetChar( 0 )) + 1 ) sLvlText.Erase( 0, 1 ); If the correct string ("\x05([\0])") were read, the test would succeed, and the first character would be stripped, giving "([\0])" Later, when the string is decoded in the number format we get "\x05(" as the prefix instead of "([". The suffix comes out OK because the missing NUL is made up for by the additional \x05 - so the suffix is in the right position in the string. However the prefix was shifted one position to the right. This particular manifestation of the problem only shows up clearly when the first list level has a visible prefix before the number.
Attachment:
Number RTF test.odt
Description: application/vnd.oasis.opendocument.text