Unable to Start Openoffice

[Alsmacstarter]

I have a newly installed MAC with X11 downloaded from apple. I have successfully installed openoffice. I even got it to run a couple of times.
NO problem I hear you say...
Now It will not start.
I click on Start OpenOffice
The Icon Appears in the Dock for Open Office, X11 starts
I click on File -> new -> text document
No action....
I then use the open x window and look at running processes...
I see this... in the process table taking all free processing time.
soffice.bi
If I leave the system for a couple of hours I see the new document open...

Any ideas what I'm doing wrong ?

Info
MAC Os 10.2.6
X11 beta 3 xfree86 4.2.1
open office version 1.0.3
open office starter 1.0.b8

All other install instructions I believe I have followed...

Any ideas....

??

Regards,

newbee mac user
Al

[OPENSTEP]

Well, the icon in the dock is for Start OpenOffice.org, not OpenOffice.org itself. OOo hasn't fully started until you see the splashscreen and the initial document window. OOo actually doesn't have any icon in the dock.

Unfortunately, the only thing I can think of offhand is fonts...how many fonts do you have installed? First idea would be to remove the pspfontcache file and the majority of the truetype fonts and try starting. This may improve your start times. If it's not fonts though...

Do you have the Apple developer's tools installed? If so, perhaps you could attach to soffice.bin while it appears to be spinning with gdb. These kinds of issues are notoriously difficult to nail down without more information...by its nature the program doesn't give much feedback while it's starting up, so there's really no way to tell what's causing the slowdown without attaching to it with gdb and getting a stacktrace:

1) Start OOo and let it spin.
2) Open a Terminal
3) top -u
make a note of the pid for soffice.bin, let's call it pid
4) gdb -p pid
5) Wait for gdb to load the symbols and such...will take a while.
6) thread 1
7) bt

Then take the output afte the "bt" from gdb and post it. This assumes the block is in thread 1...it may be in a different thread, so we may need to go through it a few times.

ed