Slashdot Mirror
OpenOffice 2.0 Preview Release
gmuslera writes "A preview release of
OpenOffice.org 2.0 was released, which has new
features like better MS-Office compatibility, an Access-like program and a more. Here is a review
of it with screenshots and how it performs. It's work in progress, maybe not recomended for production sites, but it is a good sample of what is coming."
But when will they ever have native OS X support?
an Access-like program
I remember when those were called "databases."
Here's my completely subjective, indicitive-of-nothing compatibility test.
I have an old version of my resume I drafted in Word some time ago. It's not very complicated - just a few boxes of text and a table for the main content. It's been edited, exported to different formats, reimported and mucked up all over the place a few times over. The last version of it opens just fine in any version of Word, and looks good, but I can only imagine the leftover crud from several edits and imports/exports sitting around in the file.
So far, I've yet to come across another office suite that renders the documents the same way word does - although late builds of OO 1.x have come close. I downloaded the 1.91 preview version, on a FC3 system with the msfonts installed, did an almost-perfect import. One line that sits at the bottom of the document in word gets pushed to the next page in OO 1.91. Other than that, it's a faithful reproductoin of the special characters (bullets and a few accent marks) and hand-adjusted spacing in the table. The fonts all match and the lines break in the same place.
I think "opens Lou's resume pretty well" should be an advertised feature in any Word competitor.
No, I'm pretty sure the parent is correct. The oo people obviously are horrible UI programmers (being open source programmers and all) and this is really a genuine effort at an updated splash logo. In fact I'd go as far as to say that's probably what we'll being seeing in Feb or Mar. when it goes 2.0.
I commend the parent for catching this fault and letting the world know that all of those millions of lines of code are cheapened by a stupid mspaint splash logo in preview release. The open source world needs more UI experts like him to show us our faults and where we need to focus our attentions to "make it" in the real world.
What I would like to know is when does Microsoft Office get better OpenOffice support?
PJRC: Electronic Projects, 8051 Microcontroller Tools
Disclaimer: I am one of the community members of the Mac OS X OOo "team" and founder of the NeoOffice project
It will probably be a while before you can even see X11 support for 2.0. Eric just got the 2.0 X11 based code to *compile* for the first time yesterday and it won't even run as setup crashes.
Part of the problem is that OpenOffice.org really isn't a "team"...it's primarily Sun Microsystems. Sun has four priorities: Linux x86, Windows, Solaris, and Solaris x86. Sun pays no one to work on Mac OS X support. Since it isn't one of their priorities, they frequently code without keeping the special needs of Mac OS X in mind, doing stupid things like hard-coding shared library extensions to only be ".dll" or ".so", neither of which are used by Mac OS X. They can't claim ignorance since folks have been trying to write Mac OS X code for over three years now, but yet they still don't even keep simple compatibility needs like that in mind.
Getting true native support for OOo without X11 on Mac OS X is most likely not going to happen within the OpenOffice.org project. All of our native work has been going on in the NeoOffice/J project. It uses a mixture of Carbon and Java to run using ATSUI for native fonts and Quartz for native drawing and printing. We also use full GPL licensing so we can incorporate the good work of contributors who can't get their translations and patches into OOo due to licensing and politics.
The process of giving it Aqua widgets has already begun. The latest 1.1 Alpha patches use native Mac OS X menubars. Aquafication is slow, though, because our first priority is to make it functional first, then make it pretty second. It doesn't matter if it looks pretty if it crashes after 5 minutes!
For what it's worth, it's already taken over two years just to get NeoOffice/J to the point where the native Mac OS X support is functional. By functional I mean that it can copy and paste both formatted text and images with other Mac OS X applications, has correct fonts and font layouts, functions with most all of the Mac OS X printer drivers, launches properly from the finder, works with the scrollwheel on those funky mice some Mac users have, has an integrated WordPerfect filter, uses the Apple Installer, has automatic upgrade notification, automatically translates the interface based upon your preferred language in the System Preferences language pane, etc.
OpenOffice.org 2.0 X11 has no native non-X11 support in it, much less the level of integration with Mac that we've achieved with NeoOffice/J. It's taken two years of some really dedicated engineers (namely, Patrick) to get NeoJ up to that stage. Replicating all of that work within OOo will probably take nearly that long and perhaps longer if the experts aren't there to help.
NeoOffice/J is in fact OpenOffice.org 1.1.2, and is 97% identical on a source code level. It's even got bug fixes that aren't in the OOo GM (such as functional JDBC support). This week we're going to be taking NeoOffice/J to 1.1 Beta after all known crashing and deadlocks have been fixed. And...
NeoOffice/J 1.1 Beta will be based off of OpenOffice.org 1.1.3, which isn't even available for Mac OS X X11!
Just keep up to date on the latest Mac OS X porting news on trinity instead of the infrequently updated OOo pages. RSS feeds are available too.
And don't let all of the politics and scare tactics of the OpenOffice.org denziens scare you either. NeoOffice really is the 'official' place for Mac OS X native OpenOffice.org and is where all of us core developers work (Patrick, Dan, and Ed).
ed
First of all, I'm sure the OOo developers would LOVE to follow the Word format correctly. That is, if it were a standard format, which it isn't, or if it were documented at all, which it isn't.
...
Secondly, let's assume just for the sake of argument that you had full access to all required documentation, had direct access to the internal MS code that reads/writes the files, and access to the developers who designed the file spec in the first place. Given that, you should be able to create a pretty good import/export tool, no?
So Microsoft shouldn't have any problems with their own format, right? After all, it can't be that tricky, and they DO have all of the advantages listed above.
Ah, but have you ever tried to import older Word documents into the most recent version of Word? Or even worse, to try to save a newer Word file in an older file format? It doesn't usually crash, but the translation makes OOo's Word export look pretty good.
Now, I realize that I haven't directly answered your question. All that the above is trying to do is convey the underlying complexity of the problem, and the fact that MS itself can't even get it right.
To address the specific issue of broken compatability: Given that MS makes a great deal (most?) of its money from lock-in to its proprietary formats, I would say that they have a vested interest in protecting their monopoly, no?
Of course it isn't proveable (think anti-trust ramifications here), but would it not be convenient, given this vast complexity of code, if some change just so happened to break compatability with a competitor?
Especially when you realize that when MS-Word imports older documents (even from previous versions of MS-Word), they get run through an intermediate converter that changes them to RTF, and then the RTF is imported.
You wouldn't expect the Word 97 -> RTF converter to need to change with each new release of Office, would you?
No, of course not. Not unless they were fixing a bug. And for a company where interoperability itself is a bug