And better still, this is a mac application package that you download, not installation package(s). No installation needed apart from putting it in the /Applications folder. I'm deeply impressed - thanks Eric![/quote]
FYI. The reason that Neo/J doesn't use a drag-and-drop install wasn't technical. In fact, creating a drag-and-drop installer is actually a lot easier than creating an installer package. The reason was twofold:
1. Patching - With an installer, it made it much easier to find a pre-existing Neo/J installation. Without this, patching becomes very difficult and you would have to redownload a whole new installation to get fixes. Although OOo can afford that amount of bandwidth, we can't so Neo/J will continue to use the installer so that we can support installation of small patch files. Also, I am curious how the new drag-and-drop installation handles installation of multiple languages? I know that not many people need more than one installation, but I have found many sites (i.e. larger organizations) that are using Neo/J in a shared installation (even Sun does this with StarOffice) so have a multi-lingual installation is common for those types of users.
2. User customization - I have found that many users customize Neo/J after installation by adding JDBC binaries, custom dictionaries, etc. to their Neo/J installation. By having an installer, I am able to identify such customizations, temporarily move them out of the way during upgrade, and restore them.
The OOo team might want to see if any of these issues will apply to them.
yoxi wrote:
EDIT: one weird thing, though - after running OO2 in X11, NeoJ with the j1.4 patch crashes repeatedly until I log out/in again.
Are you trying to run both OOo 2.0 and Neo/J at the same time? If so, it could be a simple case of running out of memory. Both OOo 2.0 and Neo/J are both big applications and both load Java 1.4.x.
If memory isn't the issue, you may have found a Java 1.4.x bug as I know that Java 1.4.x does use some built-in shared memory among multiple Java processes.
EDIT: one weird thing, though - after running OO2 in X11, NeoJ with the j1.4 patch crashes repeatedly until I log out/in again.
I thought some more about this and I am curious where OOo 2.0 is dumping the fondu fonts. Can you check your ~/Library/Fonts folder and see if there are now a ton of fonts in there? If so, this is very, very bad as it would mean that OOo 2.0 is polluting your font collection that all native applications use with the duplicate fonts that fondu has stripped down. This could easily cause Neo/J to crash because now Java is loading twice as many fonts and is feeding the duplicate fondu fonts to the native text rendering APIs.
I'm also curious about what happens when people think they can just start moving OOo2 around, since it installs with a drag-and-drop like most apps that *can* be moved around. (OOo, on the other hand, as we well know, hard-codes and hard-writes a bunch of pathnames of first launch, so if you ever move/rename it, your installation is toast.)
Neo/J insisting on installing itself in /Applications makes it more clear to users (IMO) that it needs to rest in place and not be moved. (Plus all the other things Patrick mentioned.)
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: Oct 14, 2005 Posts: 1 Location: Toronto, Canada
Posted: Fri Oct 14, 2005 5:46 pm Post subject:
pluby wrote:
I thought some more about this and I am curious where OOo 2.0 is dumping the fondu fonts. Can you check your ~/Library/Fonts folder and see if there are now a ton of fonts in there? If so, this is very, very bad as it would mean that OOo 2.0 is polluting your font collection that all native applications use with the duplicate fonts that fondu has stripped down. This could easily cause Neo/J to crash because now Java is loading twice as many fonts and is feeding the duplicate fondu fonts to the native text rendering APIs.
Patrick
I did some checking on this, and it appears that OOo 2.0 stores the fondu-ized fonts in /Applications/OpenOffice.org2.0.app/Contents/openoffice.org/share/fonts/truetype, i.e., within the OOo application bundle itself. (Remember that applications on the Mac, though they look and act like single entities from the Finder, are really just directories and appear that way from the command line, though I imagine most people reading this thread know that already.) So that probably isn't the reason NeoOffice/J is crashing in any case.
I haven't done enough testing so far to verify this, but it appears that this version of OOo checks for new fonts in the system (/System/Library/Fonts, /Library/Fonts and /System Folder/Fonts) every time it starts up. If a new font is TTF, it gets copied directly to OOo's own "shadow" font directory as noted above, whereas if it's a Mac-style .dfont or FFIL bundle, then fondu gets called on it and the resulting TTFs and BDFs (BDF=Unix-style bitmap font) are copied to that directory as well. Ergo, OOo's "shadow" font directory is continuously updated with TTF and BDF versions of all fonts on the Mac system, or at least that's the way it's supposed to work. This avoids polluting the Mac's standard font directories with superfluous TTFs (and BDFs, though I believe the Mac doesn't use those anyway).
One problem with this method (as I discovered to my chagrin, as the user of a multi-user Mac) is that it entirely ignores any fonts users have installed in their own home directories in ~/Library/Fonts; only fonts accessible to all users on the system are mirrored to OOo's "shadow" directory. This issue definitely needs to be addressed somehow. The canonical solution would be to have each user have their own "shadow" font directory under ~/.openoffice.org or somewhere similar, though this would have the disadvantage of wasteful duplication of fonts common to all users, possibly to the tune of hundreds of megabytes per user.
Another, more minor carp: if OOo must use "shadow" font directories in lieu of adding code to handle Mac-style fonts directly, it would be more Mac-like to have them under /Library/Application Support/OpenOffice.org, ~/Library/Application Support/OpenOffice.org or somewhere similar, though seeing as how this is an X11 application, all bets are probably off anyway.
then fondu gets called on it and the resulting TTFs and BDFs (BDF=Unix-style bitmap font) are copied to that directory as well.
The BDFs are not used at all, so they're just wasting space. OOo 1.1.2 and Start OpenOffice.org deleted those files so as not to waste space.
linuxspice wrote:
One problem with this method (as I discovered to my chagrin, as the user of a multi-user Mac) is that it entirely ignores any fonts users have installed in their own home directories in ~/Library/Fonts; only fonts accessible to all users on the system are mirrored to OOo's "shadow" directory.
I think this is the way that 1.1.2 worked, too, although I'd have to do some digging to tell for sure. I know it *didn't* convert fonts from Classic, but the installer *might* have converted the active user's fonts, too. There was a release note about it, though.
(Edit: I happened to run across my notes for the release notes last night, and they indicated in 1.1.2 we did convert the ~/Library/Fonts folder, but only for the active user....)
linuxspice wrote:
The canonical solution would be to have each user have their own "shadow" font directory under ~/.openoffice.org or somewhere similar.
Within the OOo user profile folder, there's a fonts folder already, which could (should) be used for this purpose.
linuxspice wrote:
Another, more minor carp: if OOo must use "shadow" font directories in lieu of adding code to handle Mac-style fonts directly, it would be more Mac-like to have them under /Library/Application Support/OpenOffice.org, ~/Library/Application Support/OpenOffice.org or somewhere similar, though seeing as how this is an X11 application, all bets are probably off anyway.
1.0.x and 1.1.2 put each user's OOo user profile folder(s) in ~/Library/Preferences/OpenOffice.org1.n.n; the Tech Preview builds used ~/Library/Application Support/OpenOffice.org/1.n.n. Where the user profile ends up is a matter of the preference of the person doing the build.
Since Ed is not doing any 2.0 builds and the people who are doing the 2.0 builds stop by here infrequently, you should file issues against the porting project in the OOo IssueZilla, http://qa.openoffice.org
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Last edited by sardisson on Sat Oct 15, 2005 5:54 pm; edited 1 time in total
I did some checking on this, and it appears that OOo 2.0 stores the fondu-ized fonts in /Applications/OpenOffice.org2.0.app/Contents/openoffice.org/share/fonts/truetype, i.e., within the OOo application bundle itself.
This is good news. Thanks for verifying that this.
FYI. The reason that Neo/J doesn't use a drag-and-drop install wasn't technical. In fact, creating a drag-and-drop installer is actually a lot easier than creating an installer package. The reason was twofold...
Just so's ya know, I wasn't bashing the NeoJ Way there - it was really an expression of relief after installing many versions of OO1.9.hundred'n'something, each of which made their own folder in /Applications and in the home folder, and some of which had 30 installer packages to run. And I'm not knocking those either (! - very grateful for the efforts of those who made those versions available), I'm just lazy and like having a drag and launch installation for a change, given that .134 and upwards will be along next week so I'll be doing it again...
Quote:
Quote:
EDIT: one weird thing, though - after running OO2 in X11, NeoJ with the j1.4 patch crashes repeatedly until I log out/in again.
Are you trying to run both OOo 2.0 and Neo/J at the same time? If so, it could be a simple case of running out of memory. Both OOo 2.0 and Neo/J are both big applications and both load Java 1.4.x.
If memory isn't the issue, you may have found a Java 1.4.x bug as I know that Java 1.4.x does use some built-in shared memory among multiple Java processes.
Nope - I ran NeoJ to copy my macros to the clipboard, then quit NeoJ, then ran OO.133 to paste in the macros, then quit OO.133 and X11 and relaunched NeoJ - then I clicked on a menu item, got 15 secs of beachball, then NeoJ quit unexpectedly, and kept on doing so until I logged out/in again. If I have time to do this again tiday, I'll look for console stuff to send you.
Patrick: update on OO.133 causing NeoJ to crash (in 10.4.2):
Launched OO.133/X11, edited and saved a file, quit OO.133/X11.
Launched NeoJ (patch 1.5) - clicked on new doc window, NeoJ quit unexpectedly.
See neocrash.zip for a zipped folder containing the relevant exerpt from console.log, and the files JavaNativeCrash_pid7036.crash.log and soffice.bin.crash.log which it refers to.
Whatever this crash does affects the whole system until I relog in - typing this post in safari, the text appears a second after I type...
I haven't logged this as a NeoJ bug because I don't know which app is causing it. If you want me to do so after you've looked at these logs, I will. (Oh, and if you want me to try this again with all my haxies disabled, I will )
Whatever this crash does affects the whole system until I relog in - typing this post in safari, the text appears a second after I type...
I haven't logged this as a NeoJ bug because I don't know which app is causing it. If you want me to do so after you've looked at these logs, I will. (Oh, and if you want me to try this again with all my haxies disabled, I will
Thanks for the crash log. From it, the cause of the crashing and the strange Safari behavior is very obvious: one of the Fondu'd fonts is badly converted. Your logs are filled with "ATS server" fatal exceptions. ATS server is the Mac native font server. Even though OOo X11 puts the Fondu'd fonts in a private directory, loading those fonts into the X11 server causes the X11 server to make those fonts global to all processes until you log out. So, when you run Neo/J, it is picking up one of those corrupt fonts and when it uses the Mac OS X native font rendering functions with that font, the bad font causes the native font rendering font to crash the entire app (see http://bugzilla.neooffice.org/bug.php?op=show&bugid=210&pos=0 for more info). This is not a Neo/J bug but a Mac OS X bug so you are likely to run into this problem until you can eliminate the bad font from OOo X11's private font directory.
Posted: Sat Oct 15, 2005 1:22 pm Post subject: about fondu
ericb->pluby
In fact, after contacting the author of fondu, it appears I have to change for a most up to date version, including a fix for Tiger (errors in res2data, which recopies the resource fork of a mac file into a data fork).
Posted: Sat Oct 15, 2005 1:40 pm Post subject: Use Start OpenOffice.org to convert fonts
linuxspice wrote:
One problem with this method (as I discovered to my chagrin, as the user of a multi-user Mac) is that it entirely ignores any fonts users have installed in their own home directories in ~/Library/Fonts; only fonts accessible to all users on the system are mirrored to OOo's "shadow" directory.
Here's a temporary fix that worked for me:
Place a copy of Terry Teague's "Start OpenOffice.org.app" into OpenOffice.org2.0.app/contents/openoffice.org2.0.
(I find it handiest to keep this Start OpenOffice.org in the dock, so I won't have to right-click on OpenOffice org2.0 every time I need it).
Then you can drag fonts to the Start OpenOffice.org application and it will invoke fondu, convert the fonts, and place them in the ..../share/fonts/truetype directory.
Posted: Sat Oct 15, 2005 6:03 pm Post subject: Re: Use Start OpenOffice.org to convert fonts
Guest wrote:
Here's a temporary fix that worked for me:
Place a copy of Terry Teague's "Start OpenOffice.org.app" into OpenOffice.org2.0.app/contents/openoffice.org2.0.
(I find it handiest to keep this Start OpenOffice.org in the dock, so I won't have to right-click on OpenOffice org2.0 every time I need it).
Then you can drag fonts to the Start OpenOffice.org application and it will invoke fondu, convert the fonts, and place them in the ..../share/fonts/truetype directory.
If you've been using OOo 1.x, there's an easier way that doesn't involve burying Start OOo inside OOo2.app. There's an invisible file in the root of your user folder (~/.sversionrc). You can edit that file to add an entry for OOo2 and then Start OOo will find it, no matter where Start OOo is located, and do its thing with fondu, delete unnecessary .BDFs, open files--especially those with non-Roman characters, which OOo2 cannot do itself--run the printer admin, etc.
Then in Start OOo preferences, I can switch which OOo version Start OOo activates.
Before he passed, Terry mentioned that he had a version under development that dealt with OOo 2 (which no longer needs/installs the .sversionrc file), but unfortunately he never released it
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
you are likely to run into this problem until you can eliminate the bad font from OOo X11's private font directory.
Is there any kind of short cut to identifying the dodgy font(s)? I tried running Font Doctor, but the 2 fonts it said were corrupt were not ones that had made it into OO2's font folder. I don't relish having to add fonts one by one until I find the one that causes the trouble, unless there's no easier way to see which fonts are triggering the ATS Server fatal exceptions?
- yoxi
EDIT: no worries, I fixed the problem by trashing all the fonts on my system that are over 1MB, i.e. all the SE Asian fonts that never get used (and include the 2 that are supposed to be corrupt) and now NeoJ not only doesn't crash, but starts up faster...
All times are GMT - 7 Hours Goto page Previous1, 2, 3, 4
Page 4 of 4
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
)
