Created attachment 93156 [details] Problem WMF, screenshot and PDFs Importing the attached WMF using LO with Russian locale gives garbled Cyrillic letters. The file was generated by AutoCAD 2014 Russian under Win7x64 Russian. If open with an ASCII text editor using Win-1251 codepage, the text string are visible in the file. It seems that the codepage info is not specified in the file. I think that if the encoding information is missing, then LO should honour the Default document language option, or else what is the point in it? Ignoring this setting when no other information is present is clearly a bug. I additionally include PDFs to the attachment to show the problem: the PDF generated by AutoCAD from the source (not from WMF - just to show the desired output), and the PDF generated by LO from imported WMF. Also, a screenshot of the WMF open in Notepad showing that the text is present in the file. This problem is already present in OOo 3.3.0. Still present in LO 4.2.0.4 under Win7x64, and in 4.1.4.2 under Ubuntu 13.10 x64.
Confirmed under GNU/Linux using: - v4.3.0.3 Build ID: 08ebe52789a201dd7d38ef653ef7a48925e7f9f7 - v4.4.0.0.alpha0+ Build ID: 4aa9b041de3129f19b48e66d349f48657b73f33e (2014-07-19) Status set to NEW.
I cannot get the metafile supplied to display properly, the text does use Latin letters.
I've checked it once again and there are no traces of either 'Arial Cyr' font or charset 204.
(In reply to Urmas from comment #3) Please note that the issue is not that "LO doesn't use some charset information available in the file", but that "in ABSENCE of such charset information in the file LO doesn't honor its own locale setting". This WMF file surely DOESN'T contain charset info. I noted it in comment 0: > It seems that the codepage info is not specified in the file. It contain 8-bit textual information in (some unknown for LO) charset. This is unfortunate, and the maker software is to be blamed. But such files exist. And I expect LO to follow the same logic that it uses when opening plain text files (single-byte, i.e. Win-1251) without language information available: it should use information that is set in "Options - Language settings - Languages". The same problem exist for some other formats that don't store language information, e.g. Autodesk DXF (pre-2007), see Bug 74299. By the way, there's no "Arial Cyr" for quite a long time, IIRC since Win2K? Modern localized (Russian) MS OSes contain only "Arial".
There are LOGFONT structures in metafiles, so they provide charset info explicitly. The Arial Cyr font is emulated for non-charset-aware applications in every Windows version.
Created attachment 113108 [details] WMF with CharSet set to DEFAULT_CHARSET (In reply to Urmas from comment #5) > There are LOGFONT structures in metafiles, so they provide charset info > explicitly. I agree. After exploring the contents of the file and referring to [MS-WMF] v.11/1 at https://msdn.microsoft.com/en-us/library/cc250370.aspx I see that CharSet fields of Font objects in the original file contain zero (ANSI_CHARSET = 0x00), i.e. "Specifies the English character set". This is clearly the fault of the generating SW. But when I manually set that field to DEFAULT_CHARSET = 0x01, I see that LO still ignores its locale setting, as if it were ANSI_CHARSET. In the new attachment, there is a WMF containing single Russian word "Текст" ("Text"). It has CharSet set to DEFAULT_CHARSET. According to the spec, it should be treated as "a character set based on the current system locale; for example, when the system locale is United States English, the default character set is ANSI_CHARSET" (page 31 of abovementioned doc). But LO imports it as arbacadabra when its locale is set to Russian, which is inconsistent behaviour WRT spec.
Submitted patch to gerrit: https://gerrit.libreoffice.org/15641
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6bc9b33d5cac1ea40a829754004fde6ae16d8b1 tdf#74301: WMF: use LibreOffice locale on OEM_CHARSET/DEFAULT_CHARSET It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.