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.
