To reproduce: Insert formula object Click on the "insert symbol" icon. All icons look like empty squares This can be edited to work: For each symbol: choose "edit" select font "Times New Roman" Choose symbol click "modify" click "ok"
Cannot reproduce the problem with 64 bits version on openSUSE 11.2
Can you please provide us with the screenshot showing the problem?
Created attachment 39448 [details] screenshot (png) of faulty rendering of math characters I have attached a screenshot of the problem in math editor
Created attachment 39449 [details] screenshot of missing symbols in the symbols dialog in math editor
Ups I should, of course, add I use Ubuntu 10.04 32bit 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 GNU/Linux
Riight - could well be a missing opensymbol font I suppose. Can you have a look for opens___.ttf on your system ? Interestingly, I'm getting the same problem with a developer build / install - and opens___.ttf is in place and opened: most odd. Hmm ;-)
The opens___.ttf font is there. The math editor works perfectly in Openoffice and formulas created in libreoffice will look correct after being opened and closed (i.e. no editing just updated) in ooo. Math objects created in ooo will look wrong after open/close in LO and again look correct in ooo.
I can confirm this issue. My OpenSymbol is correctly installed since I can do Insert -> Special Character in Writer, select OpenSymbol and everything shows up correctly. However, selecting the Catalog option in Math shows boxes instead of symbols. If I edit one of them, I can fetch the correct glyph, modify it, and that particular symbol will be fixed. It seems the issue is that the mapping between the Catalog symbols and the OpenSymbol font got corrupted somehow. (In reply to comment #0) > To reproduce: > Insert formula object > Click on the "insert symbol" icon. > All icons look like empty squares > > This can be edited to work: > For each symbol: > > choose "edit" > select font "Times New Roman" > Choose symbol > click "modify" > click "ok"
I confirm this bug for LibreOffice 3.3 beta2 on Ubuntu 10.10 Maverick Meerkat x86. Quite easy to reproduce. VERY important. That's the reason why I had to swtich back to OpenOffice. :(
I'm informed that this might be http://qa.openoffice.org/issues/show_bug.cgi?id=113586 i.e. there may be *another* older opensymbol font being used first ? http://qa.openoffice.org/issues/show_bug.cgi?id=115038
What's the output of... fc-list -v |grep opens I can reproduce this problem if I install libreoffice onto RHEL-5 without uninstalling the pre-installed OpenOffice.org which places its older opens___.ttf into the system-wide shared fonts dir. Meaning that the older opensymbol font is discovered first by libreoffice. i.e. if its the same problem then it'll "go away" when distros move over to libreoffice entirely.
Replacing the old OpensSymbol font with the new one solves the problem (form my short testing it's completely solved)
*mumble* Debugging this I see that when two fonts with equal attributes are discovered, the first one found gets priority over the other which is rather arbitrary.
removing needinfo, closing as not our bug - distro packages will properly conflict, and fontconfig should get a fix - Caolan, could you forward?
I've no special hotline to fontconfig devs these days FWIW. I'm rather swayed towards the thought that LibreOffice should be pulling the font version id out and using it as input into the existing mechanism we have for favouring one font above the other when two or more candidates exist. i.e. this case is a more striking example of what probably happens every day for the "vanilla" packages and the bundled DejaVu fonts etc which generally already exist on the system. Its a low priority for me to fix this though at the moment, given that it "goes away" for the "distro" bundled case. Leave this with me for the moment, and I'll have another poke eventually and either formulate a convincing fontconfig test-case or accept that we should compare font versions ourselves
*** Bug 30699 has been marked as a duplicate of this bug. ***
*** Bug 32052 has been marked as a duplicate of this bug. ***
*** Bug 33086 has been marked as a duplicate of this bug. ***
*** Bug 33482 has been marked as a duplicate of this bug. ***
now fixed for 3.4