Bug 65738
Summary: | OpenOffice got screwed up. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <tengchiangtsao> | ||||
Component: | ttfonts-zh_TW | Assignee: | Mike A. Harris <mharris> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.3 | CC: | anders, eng-asia-list, saint, yshao | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2002-06-04 05:03:23 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Need Real Name
2002-05-30 23:37:30 UTC
We have people using OpenOffice here that don't report problems. I would suspect the problem lies in the OpenOffice you're using, however without a _LOT_ more information, and someone debugging the exact problem, there isn't anything I can do. I'm certainly not going to debug OpenOffice. Especially since we don't even ship it currently. Yu Shao, do you feel like looking into this at all? Also note... while this may in fact be a legitimate bug, without a report of a very specific problem, it is unlikely to even get looked at. You mentioned 5 things it could possibly be. It could also just be an OpenOffice bug. It is up to someone who experiences the bug to narrow it down to something specific. llch is testing openoffice with CJK right now. Yu Shao, or llch, Please, please, don't spend time on CJK testing! Let's forget about Chinese right now, ok? Just fresh install RedHat7.3 with ALL language supporting and install original English OpenOffice 1.0 and do every thing in default English. It is so obvious that OpenOffice's GUI is ridiculously not readible! Harris, People using any version of OpenOffice with RH7.3 will never report any problem because they didn't enable ALL language support when they install RH7.3 ! Yu Shao, or llch, Here i attached the original report from www.openoffice.org Bug ID 4726 ------------------------------------------------------------------------------- I recently upgraded from RedHat 7.2 to 7.3 and found that both the installation program and the applications themselves were using the wrong font for their display. All the entries were too wide and looked bad. I tried running OpenOffice1.0 on the 7.3 machine remotely from a machine running Redhat 7.2 (upon which I didn't have this problem) and it worked fine, which confirmed that the problem was due to the font server in RedHat 7.3 serving up the wrong font to the OpenOffice1.0 application. I don't know if this can be controlled at all from within OpenOffice, but I thought I'd report it since others who install the complete RedHat distribution with all the fonts may also have this problem I tracked the problem down to the installation of a font package called ttfonts-zh_TW which is austensibly a true type Chinese font package. I can only assume it also includes a Roman font which xfs is choosing to provide to OpenOffice. I assume one solution (not tried) would be just not to install the package. A second solution is to modify the X font server (xfs) configuration file as follows to not use it. Become root and do the following cd /etc/X11/fs emacs config Find the line /usr/share/fonts/zh_TW/TrueType and comment it out by putting a # sign in front of it: # /usr/share/fonts/zh_TW/TrueType Exit emacs and restart the x font server with the command /etc/rc.d/init.d/xfs restart The font problem was thereby corrected by disabling the font. I don't know if anything can be done to solve this from within OpenOffice or not. It would be nice if I didn't have to disable a font to make OpenOffice work. Maybe the providers of the font package should be contacted? Thanks. Keep up the good work! ------------------------------------------------------------------------------- Hi! All, I found a work around !! Uninstall the above five packages (freetype, ttfonts, ttfonts-zh_TW, XFree86-xfs, and taipeifonts.)and then reinstall them all again with "rpm -i" (I didn't try "rpm -U"), then the problem is corrected !! Ya!!!!! We don't ship OpenOffice package yet so we don't offically support it. However we will try our best to resolve it. You can try the following steps and report if it helps or not: - reinstall those packages - edit /usr/share/fonts/zh_TW/TrueType/fonts.scale - delete any entries with ascii-0 charset - add bsmi00lp.ttf -Arphic Technology Co.-AR PL Mingti2L Big5-medium-r-normal--0-0-0- 0-p-0-iso8859-1 bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM Big5-medium-r-normal--0-0-0-0- p-0-iso8859-1 - save and exit - # cp /usr/share/fonts/zh_TW/TrueType/fonts.{scale,dir} - # service xfs restart Thanks Yes, it is ascii-0 that is causing all these troubles. However, according to my bash history, if we use this perticular sequence to reinstall these packages, the ascii-0 won't show up. So, I didn't manually modify any fonts.scale or fonts.dir . Hope this can help. ------------------------------------------------------------------------------ 322 rpm -U --force ttfonts-zh_TW-2.11-5.noarch.rpm 323 rpm -q ttfm 324 exit 325 rpm -U ttfm-0.9.1-8.i386.rpm 326 ttfinfo 327 ./ttfinfo /usr/share/fonts/ttf/bkai00mu.ttf 328 ttfinfo /usr/share/fonts/ttf/bkai00mu.ttf 329 exit 330 /usr/sbin/ttfm.sh --list 331 exit 332 /usr/share/fonts/install/xttfm.ttfm 333 /usr/sbin/ttfm.sh --add /usr/share/fonts/zh_TW/TrueType/bkai00mp.ttf 334 /usr/sbin/ttfm.sh --add /usr/share/fonts/zh_TW/TrueType/bsmi00lp.ttf 335 exit 336 cd /etc/init.d 337 ls 338 ./xfs restart 339 exit 340 /usr/sbin/ttfm.sh --remove bkai00mp.ttf 341 /usr/sbin/ttfm.sh --remove bsmi00lp.ttf 342 /usr/sbin/ttfm.sh --list 343 rpm -e ttfm 344 exit 345 rpm -U --force /mnt/cdrom/RedHat/RPMS/freetype-2.0.3-7.i386.rpm 346 rpm -U --force --nodeps /mnt/cdrom/RedHat/RPMS/freetype-2.0.3-7.i386.rpm 347 ln -s /usr/lib/libfreetype.so.6.0.1 /usr/lib/libfreetype.so.6.3.0 348 ls /usr/lib/libfreetype.so.6.3.0 349 exit 350 cd /usr/lib 351 ls *.6.3 352 ls *.6.3* 353 rm libfreetype.so.6.3.0 354 rpm -U /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 355 exit 356 rpm -U --force --nodeps /mnt/cdrom/RedHat/RPMS/freetype-2.0.3-7.i386.rpm 357 cd /usr/lib 358 ln -s libfreetype.so.6.0.1 libfreetype.so.6.3.0 359 exit 360 cd /etc/init.d 361 ./xfs restart 362 exit 363 rpm -U /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 364 rm /usr/lib/libfreetype.so.6.3.0 365 rpm -U /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 366 rpm -U --nodeps --force /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 367 exit 368 cd /etc/init.d/ 369 ./xfs restart 370 exit 371 init 3 372 init 5 373 rpm -e ttfonts-zh_TW 374 rpm -e ttfonts 375 rpm -e --nodeps ttfonts 376 rpm -e taipeifonts 377 rpm -e freetype 378 rpm -e --nodeps freetype 379 rpm -e --nodeps XFree-xfs 380 rpm -q XFree86-xfs 381 rpm -e --nodeps XFree86-xfs 382 exit 383 mount /mnt/cdrom 384 ls /mnt/cdrom/ 385 ls /mnt/cdrom/RedHat/RPMS/ 386 rpm -i /mnt/cdrom/RedHat/RPMS/XFree86-xfs-4.2.0-8.i386.rpm 387 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-1.0-9.noarch.rpm 388 rpm -i /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 389 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-1.0-9.noarch.rpm 390 umount /mnt/cdrom 391 eject 392 mount /mnt/cdrom/ 393 umount /mnt/cdrom 394 eject 395 mount /mnt/cdrom/ 396 rpm -i /mnt/cdrom/RedHat/RPMS/taipeifonts-1.2-16.noarch.rpm 397 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-zh_TW-2.11-10.noarch.rpm 398exit 399 umount /mnt/cdrom 400 exit 401 ls 402 cd /etc/init.d 403 ls 404 ps -ef | grep gdm 405 kill 1415 406 ./xfs restart ------------------------------------------------------------------------------- Hi ! I just happened to fesh reinstalled RH7.3 with All Language supported and repeated the procedure from line 345 to line 406 in the above history. llch, Simply reinstalling the 5 packages doesn't solve the bug even after making sure ascii-0 is gone. I suspect my procedure between line 345 and line 406 actually downgraded freetype. But simply downgrading freetype wouldn't solve the bug either. I must exectly follow line 345 to line 406 to solve this bug. Unbelievable but true .... Harris, Now I suspect freetype more. I will do a fresh installation of RH7.3 and do my procedure with only those lines related to freetype (if) when i have time. Freetype is a tough project. Well, DVD css is also a tough one. If this is a freetype problem, it's not a Red Hat Linux problem because OpenOffice uses its own ancient version of freetype. Please try rebuilding OpenOffice with the patch I'm attaching (makes it use the system freetype) and see if the problem disappears. Created attachment 59284 [details]
Patch to make OpenOffice use the system freetype instead of its own ancient copy
What is your entry of iso8856-1 /usr/share/zh_TW/TrueType/fonts.dir? Try to use -p- spacing instead of -c-. ie. bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM Big5-medium-r-normal--0-0-0-0-p-0-iso8859-1 Except it may be the spacing or freetype problem, it shouldn't use these fonts as the menu font. What is your first available font that listed in your font section pull down menu? I am not sure what alogthmin it finds the font for menu etc, but look like it uses the first available font (from the font name). If it is the case, then this is not very nice at all. Hi! all, I reinstaled RH7.3 again this afternoon (yes, the third time in two days). With this absolutely fresh install, I did the following: -------------------------------------------------------------------------------- 356 rpm -U --force --nodeps /mnt/cdrom/RedHat/RPMS/freetype-2.0.3-7.i386.rpm 358 ln -s libfreetype.so.6.0.1 libfreetype.so.6.3.0 363 rpm -U /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 364 rm /usr/lib/libfreetype.so.6.3.0 366 rpm -U --nodeps --force /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 373 rpm -e ttfonts-zh_TW 375 rpm -e --nodeps ttfonts 376 rpm -e taipeifonts 378 rpm -e --nodeps freetype 381 rpm -e --nodeps XFree86-xfs 386 rpm -i /mnt/cdrom/RedHat/RPMS/XFree86-xfs-4.2.0-8.i386.rpm 388 rpm -i /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 389 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-1.0-9.noarch.rpm 396 rpm -i /mnt/cdrom/RedHat/RPMS/taipeifonts-1.2-16.noarch.rpm 397 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-zh_TW-2.11-10.noarch.rpm -------------------------------------------------------------------------------- And fixed the bug again. llch, Now I don't have a problematic OpenOffice again to see which font is on the top. But I am sure OpenOffice folks is working on their algorithm to pick up right font for their GUI. See their Bug # 4726. They realize the algorithm needs improvement couple days back. They will pick a right font next time. bero, Hope OpenOffice folks will pick up the patch. As far as freetype is concerned, I have heard comments from freetype people, that OpenOffice uses freetype internal interfaces, which is a REALLY big NO. Internal interfaces are just that - internal. They are not available to be used by other applications, since they are free to change in incompatible ways, due to them not being intended for other applications to use in the first place. If this problem is indeed traced back to freetype, I consider it to entirely be an OpenOffice bug. The commands present in the last comment from tengchiangtsao above mostly make no sense. From the starting point of 356 up until 366, absolutely nothing is accomplished: 356 rpm -U --force --nodeps /mnt/cdrom/RedHat/RPMS/freetype-2.0.3-7.i386.rpm 358 ln -s libfreetype.so.6.0.1 libfreetype.so.6.3.0 363 rpm -U /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 364 rm /usr/lib/libfreetype.so.6.3.0 366 rpm -U --nodeps --force /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 356 force downgrades freetype to an older version, 358 adds an irrelevant symlink, because 363 removes everything done above that since the installation of freetype 2.0.9 in 363 wipes out the previous freetype installation(2.0.3), as well as removing the symlink and overwriting it with new files from the new freetype package. Then you remove the freetype library .so in 364, which accomplishes nothing, because you reinstall freetype again in 366 which puts the file right back. So the net result so far, is that your system is in the identical state that it was in when you started. 373 rpm -e ttfonts-zh_TW 375 rpm -e --nodeps ttfonts 376 rpm -e taipeifonts 378 rpm -e --nodeps freetype 381 rpm -e --nodeps XFree86-xfs 386 rpm -i /mnt/cdrom/RedHat/RPMS/XFree86-xfs-4.2.0-8.i386.rpm 388 rpm -i /mnt/cdrom/RedHat/RPMS/freetype-2.0.9-2.i386.rpm 389 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-1.0-9.noarch.rpm 396 rpm -i /mnt/cdrom/RedHat/RPMS/taipeifonts-1.2-16.noarch.rpm 397 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-zh_TW-2.11-10.noarch.rpm The above block of commands however do hold some clues as to what is possibly going wrong. You can safely leave freetype alone - it is not involved. The real problem, and I'll wager money on this one, is the _order_ in which those font packages are being installed in, with respect to when xfs is getting installed. I'm willing to bet that one of those font packages, installs a fixed fonts.scale or fonts.dir file which is included in the package itself, rather than installing just the fonts, and calling ttmkfdir and mkfontdir in it's %post postinstallation script like all other font packages do. If I am correct, then what is happening, is that the fonts.scale and/or fonts.dir files which the package installs manually - rather than generating dynamically ends up differing from the fonts.dir and/or fonts.scale file which ttmkfdir/mkfontdir would generate in the same directory. Continuing my hypothesis, what is occuring then, is that a possibly invalid fonts.dir file is present, or it contains entries which are incorrect. When X is used afterward, "bad things happen(TM)". Then the series of commands executed above which seems to magically work, in reality is only doing one thing - removing the ttmkfdir/mkfontdir generated fonts.dir file, and replacing it with the original file included in that particular font package. Every time you restart your system, the problem will magically reappear again, and uninstalling/reinstalling those random packages will seem to fix it again. Again, assuming I am correct... why does this happen? It happens because all *proper* font packages in the distribution *do not* include fonts.dir and fonts.scale files in the package themselves, nor should they - ever. The *proper* way to package fonts, is to have ttmkfdir/mkfontdir generate these files in the postinstall script at install time - the same way that the XFree86-fonts-* packages do. The xfs initscript, in order to ensure that all of the system font directories contain valid fonts.dir files, checks all of the font dirs when it starts up, and automatically runs ttmkfdir and mkfontdir as deemed necessary to recreate fonts.scale and fonts.dir. When this happens, is likely when the problem occurs. My guess, is that the generated fonts.dir from one of the above font packages is NOT the same as the one that is included inside the font package (if my theory is correct). As such, one works, and one doesn't, and you'll only see problems when the one that does not work is present. I presume that the broken one, is the one generated by ttmkfdir/mkfontdir, because if it was the working one, simply restarting xfs would fix the problem. So, again assuming I am correct above, there are two problems: 1) ttmkfdir/mkfontdir is creating invalid fonts.dir files for one of the font packages *OR* one or more of the fonts in those packages contain invalid data which is causing a bad fonts.dir file to be generated. 2) The font packages should NOT EVER include static fonts.dir/fonts.scale files *ever*. There is no point in doing so, because they WILL get overwritten as soon as xfs starts up the first time. In short, if a specific fonts.dir file needs to exist, then the automated utilities need to be fixed to properly generate the proper files, or the fonts need to be repaired to not contain invalid data - depending on the root cause of the problem. Also to note, is that ttmkfdir has various options in it now for excluding various encodings based on percentages of different missing characters, etc. While it may be possible that some ttmkfdir commandline option may solve the problem if ran in the given broken directory, it is not possible for an automated process such as the xfs initscript which automatically hits all directories to know when it should and when it shouldn't use some random commandline option to avoid problems in a given font. The default behaviour of ttmkfdir ran with no options, should at all times just do the right thing. We'll be switching to mkfontscale in the future, so any problems in ttmkfdir, should likely be fixed in mkfontscale as well if present. I will go investigate the above listed font packages now to test my theory. If anyone is wondering how I came up with such an extensive theory based on so little information... ;o) I've basically discovered thissort of problem about 500 times now, but it never seems to get fixed properly anywhere. Hopefully we can find a proper fix for it soon however. In the mean time, remove the offending font package entirely if possible, or else after installation of the package, chmod 444 the fonts.dir and fonts.scale files in the given directory. the symlink which was created I believe I've discovered the problem: ttfonts-zh_TW The ttfonts-zh_TW spec file contains the following code: %install ... ... install -m 0644 %{SOURCE10} $RPM_BUILD_ROOT%{xfontdir}/fonts.scale /usr/X11R6/bin/mkfontdir -e /usr/X11R6/lib/X11/fonts/encodings \ -e /usr/X11R6/lib/X11/fonts/encodings/large \ $RPM_BUILD_ROOT%{xfontdir} That is a big no-no, since it is using an included fonts.scale rather than one that is generated by ttmkfdir et al. If ttmkfdir's fonts.scale that gets generated at xfs init time is different, then the problem will occur most likely. %files %defattr(-, root, root) %doc $RPM_BUILD_DIR/%{name}-%{PACKAGE_VERSION}/doc/ %config %{xfontdir}/fonts.dir %config %{xfontdir}/fonts.scale %config %{xfontdir}/encodings.dir %config %{xfontdir_}/default*.font %attr(0755, root, root) %dir %{xfontdir_} %attr(0755, root, root) %dir %{xfontdir} %{xfontdir}/*ttf And above it shows that it does include the fonts.dir and fonts.scale, as well as another file "encodings.dir". None of these files should be included. They're also flagged wrong. Since these files are supposed to be generated at installtime via %post, and %postun, they are supposed to be %ghost files with %verify flag as well. The XFree86-fonts packages have examples in the XFree86.spec file to show proper flags for these files. The problem is ultimately either the fonts themselves, or ttmkfdir bugs. If it is the fonts themselves, there isn't much we can do about it really other than hack ttmkfdir to work around the problem. Another alternative is to hack the xfs initscript to purposefully ignore this directory when it automatically does its magic. Either way it is ugly though. Thoughts? I just thought of a possible hack that MIGHT workaround this issue for the time being. If the ttfonts-zh_TW postinstall script updates the timestamp on the fonts.dir/fonts.scale etc. files that it just installed, they will be newer than the timestamp on the actual files stored in the package. This may be enough to trick the xfs initscript into not touching this directory. Still however, the longterm solution is to fix ttmkfdir. Could someone post the working fonts.dir and the problemaic fonts.dir. That's right. The problem for this bug entry has two folds: 1. We have -c- (char spacing) for iso8859-1 (or ascii-0) in CJK fonts (which produces double spacing) 2. and the main problem is that OpenOffice is using the first font that avilable to it And yes, we are using customized fonts.scale because of ttmkfdir. That method have been done for other ttfonts_{ja,ko,zh_CN} also. And it is because we don't want to use ttmkfdir generated one. Two ways we can approach in RHL. Hack ttmkfdir again, or we can rebuild ttfonts-zh_TW to stop the double spacing in OO. However OpenOffice need to change the font usage implementation for menu to stop using these ugly latin glyphs. mharris, llch, I think my testing confirmed your diagnosis here. I fresh reinstalled RH7.3 with ALL language supported again. And did the following: ------------------------------------------------------------------------------- 35 mv /usr/bin/ttmkfdir /usr/bin/ttmkfdir.ttsao.bak 91 rpm -e ttfonts-zh_TW 92 rpm -i /mnt/cdrom/RedHat/RPMS/ttfonts-zh_TW-2.11-10.noarch.rpm 94 /etc/init.d/xfs restart 110 mv /usr/bin/ttmkfdir.ttsao.bak /usr/bin/ttmkfdir 111 /etc/init.d/xfs restart ------------------------------------------------------------------------------- Line 110 and 111 proved mharris' "time stamp trick". RH+OO becomes a perfect match again. I am very happy. Hope RH ships with OO sooner, some day. Hi! All, I just did another fresh reinstall RH7.3 (yes, the sixth time in these three days) on my laptop computer. And did the procedure line 35 to 111 in the previous message, and OpenOffice always crashes right after it starts. Now fonts is no problem at all, so this should be purely a OO's bug. This is the second time i did fresh install on this laptop computer and i always install a laptop class installation on this laptop computer. The first time i did this i used the procedure from line 373 to 397 in the second previous message i sent you. Now it is proved that line 373 to 397 has the same affect as line 35 to 111. But a "Laptop Class" installation in RH7.3 installation really has some problem with OO. All the 5 packages (XFree86-xfs, freetype, ttfonts, ttfonts-zh_TW, taipeifonts) are installed in place in the laptop, I don't know what can go wrong. All the other fresh installs I mentioned before this message are all done as "Install Everything". There could be something missing in a laptop class compact installation but that thing is installed correctly in a "Install Everything". However, today's laptop are so capacitive, we should do "Install Everything" on laptops, too. Shouldn't bother making a Laptop class installation. I should realy post this in OpenOffice.org Logically speaking, RH would not give up OO since RH now ships with SO 5.2 . However StarOffice 6.0 is not free and won't be free in a near future. Obviously, RH+OO is the alternative to SO 6.0 . Similarly, Mozilla to Netscape... It's great to hear it works now. You may also want to check out (Null) release + OO. Closing this bug now. |