Apache OpenOffice (AOO) Bugzilla – Issue 76587
WW8: MathType object displayed without brackets etc.
Last modified: 2013-08-07 14:38:26 UTC
This problem applies to Openoffice 2.x my Linux openSUSE 10.2, both the distro version 2.0 and the Openoffice.org 2.2 rpms. Openoffice 2.x on WinXP doesn't show the problem: Download the attached example .doc and load it into Writer. It contains a single math formula which shows a few numbers and plus and minus signs in Arial, except that brackets and a few operators like the multiplication dot are not displayed. All fonts from a XP OS (which is installed on a separate partition and where the formula displays fine in a local OO.org 2) have been copied over to the Linux partition and registered with my Openoffice.org. If have checked with users on the users@openoffice.org list and opensuse@opensuse.org. Some can verify, others can't. Someone reported that with textmaker on his openSUSE the formula is ok, so I tried to load the formula into textmaker on my system, without success. I tried a iconv conversion from iso-8859-1 to utf-8 on the file, without really knowing the original coding, and the log contained the following lines (they might be helpful if the cause of the problem is font substitution): MathType 5.0 Equation MathType EFEquation.DSMT4ô9²q[ÁÞÌè<¤èDSMT5WinAllBasicCodePagesArialSymbolCourier NewTimes New RomanMT Extr)
Created attachment 44588 [details] MSWord file containing MathType equation
This file will not display correctly in Word:Mac either - Maybe MathType needs to be installed to view? If MS's own products can't open it properly maybe the problem does not lie with OOo
Confirming with 2.2 on Suse 10.2 - Office would not display formula correctly (circled in red on attached screenshot). YET OO 2.1 on Windows 2000 displays the formula just fine (circled in green). Windows machine does not have (and never had) _any_ additional software installed - just the OS and OpenOffice 2.1.
MRU->SJ: could you please have a look - I do not think that this is an OLE problem, because MathType 5 is not available in newer MSO's, so the objets view is not affected by any OLE mechanism. Looks more like a problem of displaying the metafile on Linux... On Win and Solaris this looks good.
Confirmed in OOo 2.3.1 on Fedora 8. Actually, it looks correct if OOo is started with LANG=en_US.ISO8859-1, but the brackets disappear when LANG=en_US.UTF-8 or zh_CN.UTF-8, and strange characters show up in their place when LANG=zh_CN.GB2312. My Symbol font is the one from Ghostscript. If I use the symbol.ttf from Windows or "Standard Symbols L" instead via font substitution, I get the same results except that, of course, the symbols look slightly different. I guess the formula is being displayed as a Windows Metafile, and the symbols are specified by multibyte (non-Unicode) characters, but OOo did not figure out the encoding of these characters correctly. In any case, this encoding should not be LANG-dependent. This bug is annoying because my system has LANG=zh_CN.UTF-8 by default, and with LANG=en_US.ISO8859-1 the Chinese filenames are messed up and I cannot input any Chinese. This also appears to be different from bug #82469. The attached document in that bug does not display correctly even with LANG=en_US.ISO8859-1.
*** Issue 89900 has been marked as a duplicate of this issue. ***
LANG=en_US.ISO8859-1 workaround don't work for me. Still rectangles instead of signs in some places prevents me from reading that formulas. (And people around see this and blaims OOo that "can't display the task correclty while the majority with MSOffice have no problems").
Created attachment 66146 [details] This document in OOo 3.0.1. Isn't acceptable at all
Fedora 12's version (3.1.1-19.14.fc12.x86_64) also has this problem, and I did some investigations today. The WMF import code is in OOO310_m19/svtools/source/filter.vcl/wmf. In the offending documents, the Symbol font has DEFAULT_CHARSET, so the original code uses the charset from gsl_getSystemTextEncoding() which is dependent on LANG. When I replace these gsl_getSystemTextEncoding() calls with RTL_TEXTENCODING_MS_1252, the problem disappears. I don't think the calls to gsl_getSystemTextEncoding() make any sense in the WMF importer, at least under Linux. The default charset of a WMF file is a property of the file itself, and perhaps the system generating it, but it should not depend on the settings of the system loading the file. Since WMF files are usually generated in Windows, if the ANSI version of TEXTOUT is used with DEFAULT_CHARSET, most likely the intended charset is MS 1252. The user can be given the option to specify another default charset, or use some language- and font-dependent default ANSI codepage, if that's truly necessary. Some more testing is needed to check if this works for Windows-generated WMFs containing CJK text, and if the metafiles exported from OO.o can still be loaded in OO.o and in MS Word.
*** Issue 25392 has been marked as a duplicate of this issue. ***
*** Issue 108323 has been marked as a duplicate of this issue. ***
This issue was first reported for OOo 2.2 in April 2007. I confirm it is still an issue in November 2010, 3.6 years later. Isn't it ridiculous having an equation writer that can't display, for example, parentheses or plus signs i.e. ()+ ?
*** Issue 117104 has been marked as a duplicate of this issue. ***