Created attachment 42470 [details] rtf saved with ru_RU locale 1) Start Writer with ru_RU locale 2) Type something like 'Тест' 3) Save as rtf 4) Try to open rtf file, you will get 'General Error. General input/output error.' If save file with en_US or C locale it opens without error but non-ascii characters changed. E.g. 'Òåñò' instead expected 'Тест'. Rtf files created by OO 3.2 opens just fine.
Miklos for you I think
Created attachment 42498 [details] Test document containing a style named "x{y" The general error part is caused by an unescaped { in the stylesheet group. I'm attaching a simple English document reproducing the issue in a locale-independent way.
Created attachment 42499 [details] Patch fixing the style name escape part of the issue
Created attachment 42501 [details] Test doc reproducing the second part The problem seems to be that with an empty locale only 5 fonts are printed in the font table, the 6th one is added to it during the export, so \f6 is used, but it'll point to nowhere. Now the interesting fact is that wwFontHelper::InitFontTable() already preloads fonts for RTF, but in case locale is empty, the 6th one will be missing there - which is strange, since later the font is referred by RtfAttributeOutput::CharFont(), which is called for each RES_CHRATR_FONT (but ideally InitFontTable() already printed those). So what I can imagine is that the SfxItemPool gets modified and a new RES_CHRATR_FONT gets added somewhere but from a quick look I don't see where that would happen. To sum up - no idea what's going on - yet. :)
OK after some poking in gdb, it turns out that SwWW8AttrIter::OutAttr() is the strange caller (at the very end of the function). The question: is there any easy way to search for those fonts in the document model before starting the export? (Provided that we have access to rDoc.GetAttrPool()).
After dicussing with caolan on IRC, this is fixed in master with commit a37fae128b4badc8f9f2201e28dca3e08948ddec in writer.git.
Fixed a typo in the summary FILESAFE -> FILESAVE RTF written by LO 3.4 and 3.5 does not show the bug. Closing