Created attachment 55399 [details]
Original file (in russian) with a lot of formulas, which caused the crash and lost symbols.

I cannot reproduce this problem. Tested it with native OO 2.4.1 and 3.0 dev
build on WinXP, Fedora Core 5 and SUSE 10.2. You work on ubuntu the by-packed
OOo build? In this case, please refer to the distributors support or even run
the native OOo builds which can be downloaded from Openoffice.org.

Closed.

I am the Ubuntu maintainer and have opened this file on Ubuntu under official
Openoffice.org 3.0.0 (not our packages) and I still see lots of missing glyphs
(or at least weird question mark symbols) just like it does with the Ubuntu
packages which I believe is what this bug was mainly about.

mru,

So this file displays completely correct for you?

Chris

I can confirm this behavior too (apart from crashing). I also want to stress
that it is more generic than what is described here in that it does not only
affect MS Word to Linux-OOWriter import. It also happens if you create for
instance a powerpoint .ppt file, a  OOWriter .odt, or a OODraw .odg file
containing OLE mathype objects in windows: such a document won't display
properly some parts of the equations in a linux version of OO (but it's fine in
windows OO version). More specifically: upon import, some characters are
obviously not recognized and replaced by funny signs (white question mark in a
black rhombus for instance).

I have tried to figure out what is wrong, and came to the conclusion that,
whatever their origin, embedded Mathtype objects (OLE objects) containing
characters from the MS "Symbol" font, or the Mathtype "Fences" font are not
interpreted correctly when loaded in a linux version of OO (I have tried v. 2.3,
2.4 and 3.0 in several Ubuntu versions and in the Mandriva One live CD).
Installing these fonts on the linux system does not solve the problem. 

If the OLE object are converted to Metafile drawings prior to saving in windows,
then the equations are rendered correctly in linux (with the Symbol and Fences
fonts installed, I haven't checked without, sorry).

I guess this is related to issue #76587 (apart from crashing).

The bug was mainly about the crash and regarding mis-display of the characters,
we already have a handful of issues which describe this. Also there should not
be tracked two problems in one issue. Thus I closed the issue. 

MRU->HDU: please handle the "wrong symbols on Linux" problem. When opening the
attached document on a Linux-OOo 3.0. Some characters in the object metafiles
are displayed wrongly from the Font "Symbol":
Integral - U+F0F2
Sum - U+F0E5
Fracture capital R - U+F0C2

*** Issue 106912 has been marked as a duplicate of this issue. ***

This problem is related to issue 92011: Using a generic font name like "Symbol" that differs between the 
different platforms is bound to introduce problems => the solution is to import the document by 
replacing the use of ambiguous font names by platform-independent fonts such as OpenSymbol and 
convert the codepoints as needed.

Please see
http://www.openoffice.org/nonav/issues/showattachment.cgi/62619/Symbol_OSX_vs_Win.png for the 
differences between "Symbol" on Win and OSX. For completeness I'll attach a screenshot of the 
corresponding map on Ubuntu below.

I know nothing about OSX, but Linux has no "native" Symbol font, so that 
problem isn't related anyway

Well, running "fc-match Symbol" suggests "Standard Symbols L". It has the same mapping as the OSX 
Symbol font though. So independently on how isssue 92011 gets fixed (either via OpenSymbol or the 
system's native Symbol font) the symbol codepoint conversion needed for solving issue 92011 should fix 
this issue too.

Adding me to CC.

Reading about missing fences, integrals etc. it sounds very much like a effect
related to issue 105084. Thus I'm adding that one to the 'depends' list of this
issue. This issue should be reevaluated once the new OpenSymbol font is available.
That will be when CWS tl76 gets integrated. Currently we still need to make some
modifications to the font, namely switching two code points.

Aside from that everything should already work but is yet untested.
If anyone likes to take a preview I just started the 'Ubuntu-9.04-i386'
buildbot. Thus feel free to check things once the installations set is ready.

I forgot to mention that you need to be aware of issue 106941 as well when using
the installation set from the buildbot. That basically means that in the
resulting installation set you need to copy the 'OpenSymbol' font (version 2.1)
from the 'truetype' directory and install that one system wide in order to get
things working.

Is replacement of opensymbol font with improved version enough for test? I've
installed latest version attached to 105084, but nothing changed in my document

tl->annulen: Just changing the OpenSymbol font is NOT enough. You need the code
changes from Math as well since the code point changes in the font needed to be
reflected in the code to get rid of the old import/export changes code.
Thus only the combination of the new font and the installation set from the
buildbot together are the correct test environment.

annulen->tl: Right build is tl76
(http://termite.go-oo.org/buildbot/waterfall?show=Ubuntu-9.04-i386), isn't it?
It seems to be finished, but without installation set

I have uploaded an installation set named CWS_tl76_so-9-bin-linux-en-US.tar.gz
to the ftp server named 'qa-upload.services.openoffice.org' in the directory 'tl76'.

You can use the OpenSymbol font from the installation set or get it from here:
http://www.openoffice.org/nonav/issues/showattachment.cgi/66020/opens___.ttf
(The latest version attached to issue 105084)

Good luck! And please report back your findings. If it is going to be longer
please use PM (we don't want to spam this issue). Thanks!

*** Issue 107699 has been marked as a duplicate of this issue. ***

The problem here is not with the doc format it self. It is the same as in issue
107699 where a MathType OLE object are embedded into the document. 

In both issues version of MathType used is higher then 3.1 thus even with the
Mathtype <-> Math Load/Save conversions enabled Math is not involved as well.
Thus the problem is with importing the meta file.
The problem when doing that is that MathType is probably making use of the
"symbol" font. According to HDU the symbol font in use with Ubunto is very close
to the symvol font used in Mac OSX. Unfortunately the "symbol" font used in
Windows is quite different!

Therefore if we want to be interoperable with all those OS we need the following
- a heuristic to decide if the Mac or Windows symbol font is in used
- a conversion table between both of the fonts, or even better a conversion
  table for both of the fonts to OpenSymbol. In the latter case only 
  official Unicode code points may be used, this especially means: no use of
  the private-use area of Unicode.
These problems are the same as in issue 92011. Thus you may want to wait until
that issue is solved since part of the solution can probably be reused.

TL->SJ: Since this one is about the meta files, can you please take over? Thanks!

Adding hbrinkm to CC since the problem is related to his remaining issue.

*** Issue 112342 has been marked as a duplicate of this issue. ***