From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; X11; en_US) KHTML/3.4.2 (like Gecko)
Description of problem:
When you double click on an equation to go into equation editor the font used
in the editor is something weird, many of the special characters show as blanks.
I am attaching an image of the screen to see.
Now, if you are in any of the applications (calc, impress, etc.) and go into the
tools--->options---->View and uncheck the box that sais "Use system font for user
interface" then all the menu fonts turn into the same weird font used in equation
editor! Which seems to suggest that equation editor should be using the system font
as well, but there is no option for this.
This just started to happen with 116. I am not sure what changed...cairo/pango?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start a presentation containing equations
2. double-click on an equation to go to equation editor
Created attachment 116614 [details]
page showing math editor with bad font
OK. This seems to be the same as bug #160873.
If I copy the weird looking line in math editor and paste it into Writer it shows that long
list of fonts mentioned in that bug. If I change the font for the line then all of the missing
characters show up.
I wonder if it's the fontconfig stuff. We'll check again in 1.9.117-1 which will
have some fontconfig changes.
The problem seems to be in the VCL.xcu file in directory
Default fonts in this file are listed with ";" as separator, which is not
parsed properly by OO or something should be different. If I edit this file
and leave only one font in each list then I get things working correctly for
oomath and oowriter and ooimpress. To solve the other problem in oocalc font
I had to replace some font (Andale Sans UI or Alabany) with Arial.
After this the default fonts are fine and if you want to change the font the
list of available fonts are correct. If the other members in the list
intended to be fallback fonts the code that is supposed to this is failing.
it's not actually the parsing of the ";", but indeed undoubtedly related to
let me know if 1.9.117-1 solves this or not when it hits the mirrors.
The answer is YES for most people!
When I first started oocalc or ooimpress I still had bad fonts although
there was no longer the long list of fonts displayed. Instead there was
a fontname I never heard before. It turns out that I had two fonts that
I must have installed at some point named "mumumu.ttf" and "hotplate.ttf".
In the font list they showed up as "mumumu(sRB)" and "hotplate(sRB)".
For some reason the default font went to these. First it was mumumu. I removed
the font recreated cache etc... then it went to hotplate. After removing that
it ended up with Arial since I don't seem to have Albany. Perhaps it is the
brackets (sRB) messing something up. I don't need these fonts but there may
be people out there who have similar problems. Of course, everything worked
fine with earlier versions when these fonts were present.
So far, things look good. I only got one irreproducible crash of ooimpress.
If it keep happening I'll report it. On another point the visibility is
very buggy. I experienced this in some packages I build. KDE packages
have a patch to correct admin packages to properly check for the compiler.
I can call this fixed then. At this stage OOo doesn't really do anything itself
clever with fonts except ask fontconfig what font it should use from a given
name so the buck gets passed to fontconfig now.
By visibility you mean the gcc -fvisibility stuff ? e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22482 is there some cunning the kde
guys are aware of that I should be using ?
KDE has a piece in acinclude.m4.in that check for the flag (I attached this
part which also mentiones another gcc bug like above).
Fedora SRPMS add a small patch that corrects part of the above check (also
Created attachment 116763 [details]
part of kde acinclude.m4.in
Created attachment 116765 [details]
patch to correct the above segment
yeah, figured out today that this affects OOo if built with g++'s stl rather