https://bz.apache.org/ooo/show_bug.cgi?id=128549
--- Comment #7 from dam...@apache.org --- A hack such as the following, that stops some of the font-related code in main/editeng/source/rtf from calling SetEncoding(), gets the "é" and other characters to show correctly: ---snip--- diff --git a/main/editeng/source/rtf/rtfitem.cxx b/main/editeng/source/rtf/rtfitem.cxx index 33b0a48153..363ff16aff 100644 --- a/main/editeng/source/rtf/rtfitem.cxx +++ b/main/editeng/source/rtf/rtfitem.cxx @@ -689,7 +689,7 @@ SET_FONTALIGNMENT: SetScriptAttr( eCharType, *pSet, aTmpItem ); if( RTF_F == nToken ) { - SetEncoding( rSVFont.GetCharSet() ); +// SetEncoding( rSVFont.GetCharSet() ); RereadLookahead(); } } @@ -1963,7 +1963,7 @@ void SvxRTFParser::RTFPardPlain( int bPard, SfxItemSet** ppSet ) if (nDfltFont != -1) { const Font& rSVFont = GetFont(sal_uInt16(nDfltFont)); - SetEncoding(rSVFont.GetCharSet()); +// SetEncoding(rSVFont.GetCharSet()); } else SetEncoding(GetCodeSet()); ---snip--- Bug 125495 dealt with a similar issue but allegedly fixed it and reverting that patch doesn't fix this. What they did in bug 68639 might explain why the system locale overwrites the Mac locale, although I am not sure that causes this bug yet. The more I look at this, the more complex it gets :-/. -- You are receiving this mail because: You are the assignee for the issue.