Bug 65738

Summary: OpenOffice got screwed up.
Product: [Retired] Red Hat Linux Reporter: Need Real Name <tengchiangtsao>
Component: ttfonts-zh_TWAssignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: 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 Flags
Patch to make OpenOffice use the system freetype instead of its own ancient copy none

Description Need Real Name 2002-05-30 23:37:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311

Description of problem:
If you included all language support in RedHat Linux installation, Any language
version of OpenOffice got screwed up.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install RedHat Linux 7.3 with All languages supported
2.Install OpenOffice.org original English version. v1.0 or any earlier versions.
3.Start OpenOffice.org
	

Actual Results:  Characters (any language) are spaced too much in between.
If in Traditional chinese version of OpenOffice.org, chinese characters won't
show up in OpenOffice.org Writer's main edit window.

Additional info:

Please refer to http://www.openoffice.org  Bug ID4726
Not only chinese version of OpenOffice.org is effected, but any language,
including the original English version got screwed up.
The really problem is Traditional Chinese support. If you disable Traditional
Chinese support, the problem is corrected.
This bug didn't exist in RedHat Linux 7.2
People in OpenOffice.org suspect problems could be in freetype, ttfonts,
ttfonts-zh_TW, XFree86-xfs, or taipeifonts.

Comment 1 Mike A. Harris 2002-05-31 00:08:18 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?

Comment 2 Mike A. Harris 2002-05-31 00:10:01 UTC
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.

Comment 3 Yu Shao 2002-05-31 00:45:25 UTC
llch is testing openoffice with CJK right now.

Comment 4 Need Real Name 2002-05-31 02:08:07 UTC
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 !

Comment 5 Need Real Name 2002-05-31 02:22:21 UTC
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!
-------------------------------------------------------------------------------


Comment 6 Need Real Name 2002-05-31 02:55:34 UTC
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!!!!!

Comment 7 Leon Ho 2002-05-31 04:17:16 UTC
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

Comment 8 Need Real Name 2002-05-31 06:48:18 UTC
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
-------------------------------------------------------------------------------

Comment 9 Need Real Name 2002-06-02 19:58:26 UTC
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.

Comment 10 Bernhard Rosenkraenzer 2002-06-02 20:14:53 UTC
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.

Comment 11 Bernhard Rosenkraenzer 2002-06-02 20:15:46 UTC
Created attachment 59284 [details]
Patch to make OpenOffice use the system freetype instead of its own ancient copy

Comment 12 Leon Ho 2002-06-02 23:39:19 UTC
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.

Comment 13 Need Real Name 2002-06-03 00:55:51 UTC
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.

Comment 14 Mike A. Harris 2002-06-03 03:56:23 UTC
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.

Comment 15 Mike A. Harris 2002-06-03 04:29:18 UTC
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


Comment 16 Mike A. Harris 2002-06-03 04:43:40 UTC
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?

Comment 17 Mike A. Harris 2002-06-03 04:51:02 UTC
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.

Comment 18 Yu Shao 2002-06-03 05:11:15 UTC
Could someone post the working fonts.dir and the problemaic fonts.dir.

Comment 19 Leon Ho 2002-06-03 05:28:01 UTC
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. 


Comment 20 Need Real Name 2002-06-04 01:29:40 UTC
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.

Comment 21 Need Real Name 2002-06-04 05:03:17 UTC
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...

Comment 22 Leon Ho 2002-08-27 03:02:28 UTC
It's great to hear it works now. You may also want to check out (Null) release + OO. Closing this 
bug now.