Description of problem: When openoffice.org is ran in gnome (with --enable-gtk), everything looks well. However when it is ran in kde (with --enable-kde), it does not show all the characters in some of the lanauges (i.e. CJK) Version-Release number of selected component (if applicable): 1.1.2-6 How reproducible: everytime Steps to Reproduce: 1. log into KDE 2a. LANG=ja_JP.UTF-8 ooffice or 2b. LANG=zh_CN.UTF-8 ooffice .. Actual results: does not show all the characters Expected results: show all the characters Additional info: Other than this bug. should we unify to use gtk widget by default only even if it is in kde desktop, as our default desktop and toolkit is gtk2. More problems may arise basically kde/Qt widgets/layers get less QA/testing.
Created attachment 104344 [details] ooffice in kde
Created attachment 104345 [details] ooffice in gnome
Verified. That really looks like ass, doesn't it? :)
Appears to be fixed with 1.1.2-7
Created attachment 104702 [details] 1.1.2 screenshot on zh_CN Dan, tested with latest -7 and the problem is still there.
Do you by chance NOT have ttfonts-zh_CN and ttfonts-zh_TW installed? You'll need those. Remember that OOo will NOT use bitmapped X fonts, it will only use TrueType and Type1 PostScript fonts, and if you don't have either of these, you're kind of out of luck. I was able to get no menu text when I removed both of these. So, the question becomes, should openoffice.org-i18n Require: ttfonts-zh_CN/ttfonts-zh_TW/ttfonts-ja/etc?
> should openoffice.org-i18n Require: > tfonts-zh_CN/ttfonts-zh_TW/ttfonts-ja/etc? IMO, yes. Some users may grumble about being forced to install fonts they'll never use, but at least it will guarantee a working ooo for everybody. Of course, the grumbling will go away if/once the i18n bits get split up... (-:
> Do you by chance NOT have ttfonts-zh_CN and ttfonts-zh_TW installed? > You'll need those. Remember that OOo will NOT use bitmapped X fonts, He *did* say it worked under gtk, so if your statements hold true there, then the answer is probably yes.
Ok, I lied, its also horribly busted under GTK if you don't have these ttfonts-* packages installed. The problem with requiring the ttfonts-* packages for the i18n package is that they are huge, ttfonts-ko is 18MB itself. However, OOo ain't gonna work in either of these locales unless you have these packages, so...
Considering the -i18n subpkg is already many, many MB in size, an additional 18MB is a drop in the bucket...
I have all ttfonts-* installed. If you look at the screenshot, the kde's konsole menu rendered correctly with ttf. What is your step of reproduce and is it a fresh installation (i.e. without any config)? Does it works for you if you followed my steps? For the question on requires ttfonts-* or not - I would say it may piss a bunch of people if doing so. Also from the logic if OOo requires ttfonts-*, i think gnome and kde would need to do so as well.
Ok, I'm getting this with a clean rawhide install even when the ttfonts-* are loaded. Debugging
Ok, the problem really is that you probably don't have openoffice.org-kde package installed, right Leon? I'm not quite sure how to handle this. We probably should install the -kde package if you install KDE stuff in Anaconda. I'll have to talk to Jeremy about that.
You are quite right. -kde has to be installed manually as seems comps does not include it. It maybe have some screwing dep. if it is included to be installed by default. If it is installed with KDE group then probably it openoffice.org-kde will require openoffice.org isn't it? Are there any way to fallback to use gtk+ in kde if module is not available?
Technically, the KDE VCLplug needs to get fixed in OOo to use font fallback like the GTK VCLplug does.
*** Bug 150432 has been marked as a duplicate of this bug. ***