2.0 Beta For MS Files
by
kg4gyt
·
· Score: 5, Informative
I've found that 2.0 Beta has very few bugs, from what I've seen, almost the same beta that gmail is still beta. But anyways, OOo 2.0 Beta seems to handle the microsoft documents extremly well. Well worth the download.
Re:Version 1.1.5?
by
HUADPE
·
· Score: 5, Informative
OpenOffice.org 2.0 is a beta. 1.1.5 is the stable release. The beta is not supposed to be for general consumption, it is a prototype which may have bugs and be unstable.
-- This sig has not been evaluated by the FDA. It is not designed to diagnose, treat, prevent, or cure any disease.
I wonder if openoffice 2.0 can export them properly too. I just tried to open an odt document that I saved from openoffice 2.0 (the latest version from SUSE 9.3, it's beta, but it's good enough for Novell) and KOffice says that it isn't a valid OASIS opendocument, then refuses to open it.
Can't find the bugs? Want mine?
by
jfengel
·
· Score: 1, Informative
Really? I find it pretty darn buggy. It crashes frequently; the change-tracking feature is intolerably slow; it often mis-numbers autonumbering; it botches not-terribly-complicated page layouts.
I guess it's all in the features you use. I still use it because the price is right. And "pretty darn buggy" is still "only about as buggy as Microsoft Office."
And is also its Achilles heel.
by
soullessbastard
·
· Score: 5, Informative
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
As someone who's wrangled with the OOo build system since 2001, I have to respectfully disagree. While it is good that it supports so many different operating systems, the build system is also one of the major Achilles heels of OOo. Some examples:
It builds its own build tools as part of its bootstrapping process. This makes it near impossible to cross-compile without completely retooling the build system (a pain for doing any type of single-machine PPC & x86 OS X builds).
It has its own "make" equivalent that encodes module dependencies and language localizations in a custom format. To add appropriate dependencies you need to learn yet another makefile system. Don't mention trying to figure out the module build order without actually running a compile. Try it sometime if you want to lose your mind.
It uses quite a few preprocessing tools for custom file formats for processing including slots files, IDL files that generate more headers, resource compilers, and more. Custom toolchains make figuring out what generated what file even more fun to discover.
Some of the build tools have dependencies on versions of Java that do not exist on all the platforms on which the application might be able to run, preventing it from even compiling on those platforms.
The end result of all of this is that the entire 8 million line plus project is quite dependent on its build system in order to successfully compile. The system is so intricate that most all of the attempts to move it to a different system, such as XCode, have failed. This is a bummer. From a Mac perspective, it sucks ass to be forced to use command line tools for such a huge project. You lose access to such useful tools as the symbolic browser information (e.g. "Jump to Definition" for a symbol in an editor file) and within-project searches. Not to mention you don't gain access to other nice things in the environment like distributed compiles. Probably the worst side effect, however, is that most Mac developers aren't command-line junkies (unless they were MPW freaks like me). They've been raised on CodeWarrior and other great IDEs. It's a real turn-off to have to learn an arcane command line build system that is used for only one program and will probably not give you any useful skills for any other applications on the Mac platform. Forget about being able to examine the interface in InterfaceBuilder or ResEdit, too.
The whole complexity of learning the build system and all of the custom formats involved has been a real turn-off for many a Mac developer who just take a look at the build instructions and vomit. The lack of standard dev tools has definitely hindered my productivity, and I'm sure I'm not alone. A fantastic build system is one that doesn't get in a developer's way and on Macs at least, that's most definitely not the case.
ed
You mean like
by
guybarr
·
· Score: 3, Informative
Re:OpenOffice in government contracts...
by
Anonymous Coward
·
· Score: 1, Informative
The largest regional government in Spain, Andalusia, is a heavy user of OpenOffice as are many other regional governments in Spain but to a lesser degree.
Re:pssshhh stable.
by
leonmergen
·
· Score: 2, Informative
When you're quoting Linux Torvalds, at least give him the credits he deserves...
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
-- Social scientists are inspired by theories; scientists are humbled by facts.
Re:Sweet: just installed Beta 2 on Ubuntu Linux
by
b.e.n.n.y_b.o.y_1234
·
· Score: 2, Informative
Why didn't you just type apt-get install openoffice.org2 ?
MacOS X Version
by
tranquillity
·
· Score: 3, Informative
Btw, KOffice is coming out with a new stable release, 1.4.2, very soon.
Re:Sweet!
by
abandonment
·
· Score: 4, Informative
I've been very pleased with the stability, performance and featureset of the open office 2 beta - we've been using it internally for a month or so and it is miles better than the current 1.x codebase.
you might look into trying it out - it might be a 'beta' but it's been very stable on our range of machines - we don't open any massive sized files like what you are looking for, and for that matter i haven't tried out the db side of the new release, but overall it's worth looking into if you are simply trying to open & examine large files.
oh, and i seem to recall that the max rows limit was increased in the 2.x oo spreadsheet app as well, but can't remember how much...
Re:Sweet!
by
Neil+Blender
·
· Score: 2, Informative
Ah. I see. I still feel a bit vindicated, though; because it still looks as though the proliferation of file formats you are seeing is due to others upstream using a spreadsheet when what they really wanted was a database.
No, not really. The multitudes of software our customers use in reading their arrays always provide an export function. The export options (and mind you this is third party software) is generaly "you pick and name the columns" or "export everything". This is very advantageous to us. As long as their software can export tab delimited text, we can accomidate their data. If their software only allowed MS access or the like, it would be too hard for us to accomadate all the platforms out there. When we are able to tell our customers, "Send us a tab delimited text file of your data, we will figure it out for you" - they love it. We spend a few minutes in OO or Excel (depending on if it as developer or support staff), quickly reformat their file and load it for them. Given the compexity of most bioinformatics software platforms out there, this is like living at the ritz. We strive for excellence in customer service and my initial remark about 32 vs 64 vs 100K lines of data had to do with quick spot checking for quality of our work. If a statisical error exists, we have to solve the problem ASAP. I'll still spot check, but a spread sheet makes it easier and quicker than doing it by hand.
Slashdot Mirror
I've found that 2.0 Beta has very few bugs, from what I've seen, almost the same beta that gmail is still beta. But anyways, OOo 2.0 Beta seems to handle the microsoft documents extremly well. Well worth the download.
OpenOffice.org 2.0 is a beta. 1.1.5 is the stable release. The beta is not supposed to be for general consumption, it is a prototype which may have bugs and be unstable.
This sig has not been evaluated by the FDA. It is not designed to diagnose, treat, prevent, or cure any disease.
I wonder if openoffice 2.0 can export them properly too. I just tried to open an odt document that I saved from openoffice 2.0 (the latest version from SUSE 9.3, it's beta, but it's good enough for Novell) and KOffice says that it isn't a valid OASIS opendocument, then refuses to open it.
Really? I find it pretty darn buggy. It crashes frequently; the change-tracking feature is intolerably slow; it often mis-numbers autonumbering; it botches not-terribly-complicated page layouts.
I guess it's all in the features you use. I still use it because the price is right. And "pretty darn buggy" is still "only about as buggy as Microsoft Office."
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
As someone who's wrangled with the OOo build system since 2001, I have to respectfully disagree. While it is good that it supports so many different operating systems, the build system is also one of the major Achilles heels of OOo. Some examples:
The end result of all of this is that the entire 8 million line plus project is quite dependent on its build system in order to successfully compile. The system is so intricate that most all of the attempts to move it to a different system, such as XCode, have failed. This is a bummer. From a Mac perspective, it sucks ass to be forced to use command line tools for such a huge project. You lose access to such useful tools as the symbolic browser information (e.g. "Jump to Definition" for a symbol in an editor file) and within-project searches. Not to mention you don't gain access to other nice things in the environment like distributed compiles. Probably the worst side effect, however, is that most Mac developers aren't command-line junkies (unless they were MPW freaks like me). They've been raised on CodeWarrior and other great IDEs. It's a real turn-off to have to learn an arcane command line build system that is used for only one program and will probably not give you any useful skills for any other applications on the Mac platform. Forget about being able to examine the interface in InterfaceBuilder or ResEdit, too.
The whole complexity of learning the build system and all of the custom formats involved has been a real turn-off for many a Mac developer who just take a look at the build instructions and vomit. The lack of standard dev tools has definitely hindered my productivity, and I'm sure I'm not alone. A fantastic build system is one that doesn't get in a developer's way and on Macs at least, that's most definitely not the case.
ed
WYSIWYM ?
Working for necessity's mother.
The largest regional government in Spain, Andalusia, is a heavy user of OpenOffice as are many other regional governments in Spain but to a lesser degree.
When you're quoting Linux Torvalds, at least give him the credits he deserves...
- Leon Mergen
http://www.solatis.com
Search for NeoOffice/J. A much better port for OS X. Of course, it's not 1.1.5, but it works great, no X server required.
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
Social scientists are inspired by theories; scientists are humbled by facts.
Why didn't you just type apt-get install openoffice.org2 ?
For those who cannot find a 1.1.5 version for MacOS X (that also works on tiger) on www.openoffice.org try this link: http://ooofr.org/telechargement/macosx/1.1.5/
There ist also a 2.0 beta version available: http://ooofr.org/telechargement/macosx/2.0/
Of course you'll still need X11 to run those applications, but 1.1.5 works fine and stable for me (havn't tried 2.0 yet) on tiger with Apple's X11.
You should try Kexi, the Access replacement in KOffice. If you don't want to install all of KOffice, Kexi can be installed stand-alone as well.
Go to http://www.koffice.org/kexi/ to find out more.
Btw, KOffice is coming out with a new stable release, 1.4.2, very soon.
I've been very pleased with the stability, performance and featureset of the open office 2 beta - we've been using it internally for a month or so and it is miles better than the current 1.x codebase.
you might look into trying it out - it might be a 'beta' but it's been very stable on our range of machines - we don't open any massive sized files like what you are looking for, and for that matter i haven't tried out the db side of the new release, but overall it's worth looking into if you are simply trying to open & examine large files.
oh, and i seem to recall that the max rows limit was increased in the 2.x oo spreadsheet app as well, but can't remember how much...
Gekido's Lair
Ah. I see. I still feel a bit vindicated, though; because it still looks as though the proliferation of file formats you are seeing is due to others upstream using a spreadsheet when what they really wanted was a database.
No, not really. The multitudes of software our customers use in reading their arrays always provide an export function. The export options (and mind you this is third party software) is generaly "you pick and name the columns" or "export everything". This is very advantageous to us. As long as their software can export tab delimited text, we can accomidate their data. If their software only allowed MS access or the like, it would be too hard for us to accomadate all the platforms out there. When we are able to tell our customers, "Send us a tab delimited text file of your data, we will figure it out for you" - they love it. We spend a few minutes in OO or Excel (depending on if it as developer or support staff), quickly reformat their file and load it for them. Given the compexity of most bioinformatics software platforms out there, this is like living at the ritz. We strive for excellence in customer service and my initial remark about 32 vs 64 vs 100K lines of data had to do with quick spot checking for quality of our work. If a statisical error exists, we have to solve the problem ASAP. I'll still spot check, but a spread sheet makes it easier and quicker than doing it by hand.