Bugzilla – Bug 146181
Incorectly displayed ť, ľ in SK locales
Last modified: 2006-02-13 15:59:08 UTC
I see in menu squares instaed of ť or ľ. Others letters like č,š are displayed correctly. My locale is sk_SK.UTF-8 .
I seems that a problem with font cache is here again. I have started OOo in windowmaker (where the original problem appeared) in sk_SK locales several times. It sometimes started correctly and sometimes incorrectly. Kendy, I think that you have already solved a similar problem half an year ago. At the time, it was deterministic. It started well and wrong in turns. It seems to be more random now. However, I started it sometimes in sk_SK locales and sometimes sk_SK.UTF-8 locales. So, there could be a system dependant on the locales. Also note, that some problems with font cache have been discussed on research@suse.de in the thread Firefox-1.5 is slower last week. Last note. I reproduced it on beta2. I did not see such problems on beta1.
Created attachment 65479 [details] A screenshot when the fonts are correct.
Created attachment 65481 [details] A screenshot when the fonts are broken.
Ah, I found a system. OOo starts with correct fonts after I remove the font cache ~/.fonts.cache-2 or after the cache is updated by a "smart" application, such as gimp. So, it is most probably related to the new fontconfig as discussed on research@suse.de, http://mailman.suse.de/mlarch/SuSE/research/2006/research.2006.01/msg00266.html It seems to be a beta2-specific problem. It seems to be quite common problem, which must be fixed before we release 10.1, so I'll increase severity to crytical. Mike, do you have any idea what goes wrong?
No, I don't know what is going wrong. But I know that there are many remaining bugs in fontconfig and that it usually helps to delete all caches in /var/cache/fontconfig and ~/.fonts.cache-2. Of course that's a workaround only. I am very interested in broken ~/.fonts.cache-2 files, i.e. if you have a system where a problem occurs which can be fixed by moving the ~/.fonts.cache-2 out of the way, then please don't delete that ~/.fonts.cache-2 file, just move it somewhere else and send it to me. That would help me to investigate what is going wrong. I fixed a problem with ~/.fonts.cache-2 Friday evening, i.e. you can also try the fontconfig which I submitted Friday evening (still in /work/src/done/STABLE/fontconfig, mbuild job magellan-mfabian-80) and see whether that helps.
Created attachment 65603 [details] "good" cache This cache has been generated when the gimp was started. A similar (such a big cache) was generated also log in. When such a big chache is present, OOo starts correctly, witch correct font.
Created attachment 65605 [details] "wrong" cache This cache was generated when OOo was started. OOo starts with wrong/broken font when such a small cache is present on the system. To avoid misunderstanding. The most important thing is what cache is present before OOo is being started. When the big cache is available, it starts well. When the small cache is available, it starts with wrong fonts. By another words. When OOo is beeing started and the good cache is present, the cache is regenerated to the small variant, OOo starts with good fonts but the cache is broken and OOo starts with wrong fonts next time. When OOo is beeing started with the wrong cache, the cache is not regenerated, OOo starts with wrong fonts, the cache is still broken and OOo starts with wrong fonts next time as well.
Wow, I updated fontconfig from STABLE and it works now. OOo still produces small cache, gimp big cache, OOo works everytime, though. So, it works and we would close this bug. However, I would like to be sure that there is not a problem with the cache size. Is it correct that gimp produce a bigger font cache than OOo? I think that either gimp adds its own private fonts or OOo disables some system fonts. There are two problems with it: 1. It would be ugly if OOo does not find some system fonts. 2. It takes quite a long time to regenerate the user font cache. The applications start slowly then. So, we should avoid the situation when some applications modify the cache this way. We should probably open another bug for this. Mike, what do you think about it?
Petr> Is it correct that gimp produce a bigger font cache than OOo? No, that cannot be correct.
Petr> I think that either gimp adds its own private fonts or OOo disables Petr> some system fonts. I don't think this is what is happening. All applications using fontconfig should see the same set of fonts. If not something is badly wrong.
I cannot reproduce this in Beta 3. (But I cannot be 100% sure.)
The fontconfig packages in Beta3 are unfortunately very broken. Please try the updated packages available from ftp://ftp.suse.com/pub/projects/m17n/10.1/RPMS Please update both the "fontconfig" and the "fonts-config" packages! As I believe this problem has been fixed, I'm closing this bug as FIXED. Please REOPEN if the problem remains with the updated packages from the above ftp URL.
I'm using beta3. After I have updated fontconfig*, groff and fonts-config everything related with X begun crashing. Applications, also gdm. I tried to launch yast2. I can attach strace and core if needed. Actually I had no problem in beta 3 with original fontconfig*, fonts-config, groff. So I had to downgrade.
You did call "SuSEconfig --module fonts"?
No.
Does it help if you do it now? If not, does "fc-cache -v -f" (called as root) help?
Runing SuSEconfig --module fonts did not helped. Try to run Yast2 ends with segfault. But fc-cache -v -f helped. Yast2 runs fine. Probably this information could be mentioned on the page http://en.opensuse.org/Bugs:Most_Annoying_Bugs .
Characters in OOo are displayed correctly after update.
Ladislav> Probably this information could be mentioned on the page Ladislav> http://en.opensuse.org/Bugs:Most_Annoying_Bugs . Done.
Ladislav> Characters in OOo are displayed correctly after update. Can you give some more information please?
I can not reproduce this bug [description] any more. So this bug can be closed.
Closing as FIXED according to comment #21.