Disclaimer: I am one of the members of the Mac OS X OOo team and a founder of the NeoOffice project
OpenOffice.org X11 on the mac is effectively dead because it is horrendously understaffed. There are less then 5 people actively working on it. Not good for an 8 million line + application.
While Apple's developer documentation may be first class, OpenOffice.org X11 is not built using Apple-specific technologies. It is built from the command line and is using X11 with its own internal widget toolkit. Oh yeah, and takes 9 hours to compile on a dual G5 2GHz. That hurdle is a bit too high for just someone to stroll on in and casually check out the project.
OpenOffice.org is a large and thorny Unix application. There are very few Mac OS X programmers that actually have X11 and Unix skills and the patience to deal with something of its size. Most developers come to the project and are like "can I build it in XCode" or "can I use InterfaceBuilder", find out they can't and then leave. The lack of a sufficiently large pool of skilled volunteer programming experts effectively killed OOo on the Mac from the start.
The native work has effectively moved to the NeoOffice/J project, which is 95% code identical to OpenOffice.org and uses Carbon and Java instead of X11. It still doesn't use Apple development tools directly, but it does have two of the original developers of OOo Mac OS X working on it continuously.
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).
Wouldn't it be great if they listed them? They only say that it covers patents they may have in their schemas. Determining which patents they're referring to or which patents you're actually licensing from them is left as an exercise to the reader. It could be none, or it could be things like their patent for "Methods and Systems for Generating XML Documents" (USPTO 6675353).
If you want to figure out what patents are used, if any, you ve not only got to go through and read the schemas and search through and read any Microsoft assigned patent that could possibly pertain to XML. Given how broad claims of patents can be are, the patent may not even have the words "XML" in it.
And that's just to write a silly MS Office XML file filter.
It's a much smaller problem then the one that independent developers now face when working on OOo. Sun is the primary contributor to OOo and does volumes more work then the community. They now have patent protection with Microsoft so all of their code can use any MS patents they want, consciously or unconsciously. But the moment I "cvs checkout" that source, I'm open to liability for using Microsoft's patents without a license. Unless Sun divulges if any of their code uses patents (unlike that MS license agreement that doesn't even say what you're licensing), the only way for me to avoid getting sued is to actively read all of Sun's contributed code *and* all of Microsoft's software patents to make sure none of the Sun code infringes on *any* of Microsoft's software patents.
I doubt anyone has the time to do that. OOo is over 8 million lines large and it's nearly impossible to fully comprehend, much less cross-reference with software patents with overly broad claims.
In order to contribute code into OOo that gets committed and incorporated into the main product, you (or your company) must file a Joint Copyright Form (warning: PDF. No HTML version is available). It is essentially dual-copyright assignment. Both you and Sun have a copyright to your contributions, so Sun can continue to do whatever they want with your contributions including relicense them under different terms.
The work I've done in my projects outside of the OOo source code repository falls outside of the jurisdiction of the JCA. I and I alone own the copyright to that work and choose to license it as I wish.
So no, I can't get recompense for anything I've contributed back into the OOo source code repository itself since Sun owns it too. If I find any of my other outside code in the repository and I myself haven't committed it there, then it's a violation of coypright provided it's not compatible with SISSL licensing.
As OOo is LGPL licensed, the reverse isn't true...Sun can't do anything to me if I use the code in other outside projects, provided they're compliant with LGPL or SISSL licensing. Submarine patents, however, are a different story. Neither LGPL nor SISSL provide patent protection for derivative works.
Disclaimer: I am a Mac OS X community developer for OpenOffice.org and a founding member of NeoOffice
There is one obvious reason for this clause that I can think of off of the top of my head. Microsoft Office XP has a feature by which Office documents can be saved in an XML format. Obviously, this means that the information in the resulting Microsoft Office generated files is not as obfuscated as it is in a binary format (provided key information isn't just base64 encoded into elements). Microsoft knows this feature can negate the lock-in to.doc and other Office formats. So they were clever...
Obviously, OOo will want to be able to open these new Microsoft Office XML formatted files similar to its support for the.doc format...but Microsoft has prevented anyone from using their patented schema in a "free as in beer" environment. These clauses in TFA allow Sun a cop-out: Sun can freely write code and use it in OOo that uses the Microsoft Office XML schemas. In the Sun-branded OOo distributions (Linux-x86, Solaris, Solaris-x86, Windows only...they have a Sun logo on the startup screen) Sun is free to use the patented Office schemas as well. Because of this, Sun will most likely contribute the code to work with these schemas into the core source code of OOo.
Other companies make derivatives of OOo too (Red Hat, Novell/Ximian, BSDMall), individuals like myself, and even just translators non-Sun builds for mainline platforms who don't program at all. The Sun-MS agreement says that Sun's patent licensing for the Office Schemas does not apply to any OOo derivatives or builds that are done outside of Sun. Either all of these companies and individuals need to sign the Patent License Agreement with Sun or else they are open to lawsuits from Microsoft and potentially pay royalties to Microsoft in the future to use their schema.
It's really another clever way Microsoft has come up with to continue to ensure their file formats remain closely guarded and their own property.
As to whether a patent of an XML Schema can stand up in court, well, I know I personally as a single developer don't have the kind of money to challenge Microsoft on patent litigation if they sue me as an individual. Unfortunatley I have neither the time nor the skills to scrutinize all of Sun's contributions to OpenOffice.org's source code to see if they use Microsoft's patents in such a way that's legal for them, but not legal for me. I either must take my chances or stop being a non-Sun developer of OpenOffice.org. Unfortunately now any non-Sun entity working on OOo has to make that choice for themselves.
(Disclaimer: I'm the lead volunteer for OOo Mac OS X)
There is no Java in OpenOffice.org. It is just horribly inefficient C++. The only time Java is used in OOo Mac OS X is during the build process to validate some XML configuration documents; at runtime it doesn't need Java at all. That's why it's possible to run on DarwinPPC even though you can't compile it on DarwinPPC.
Remember, it wasn't written by Sun, but by Star Division. It was started back in the mid to early 1990s and was definitely back in the day before the AWT was anywhere near stable or cross platform. It may have even been started before Java, but I'm unsure of the timelines.
Just an FYI, the slow startup time isn't actually due to Java. It's still 98% C/C++, and the slow startup time is actually due to inefficiencies in "ucb" and writing out an initial temporary registry database. That step is written in C++ and takes about 3 seconds by itself. Another large chunk of time is spent loading the hundreds of megs of shared libraries, all of which are written in C++.
The parts of it that are Java are actually on par, if not faster then their X11 equivalents. Feel free to break out Shark and take a look for yourself:)
The first place to start would be to read through the official OOo 1.1.2 Installer FAQ which has answers to this as well as other support issues and questions. There are a number of other FAQs on trinity that can help you address problems.
All of us volunteers have put up extensive OOo support resources for Mac OS X users, and there are links to all of them on the "Support" section of our website and even in the README included with the installer itself! We spend a lot of time helping users get things working. If something doesn't work, why not try taking advantage of all the written documentation and live volunteer support? It seems that open source is no different then commercial apps...people still don't read the manuals;)
ed
(PS: the answer to your problem is that OOo is already installed by that point in the install process...you may just be missing one or two fonts, but it works just fine)
One thing that many programmers take for granted these days is that compilers produce correct code nearly all the time. They've gotten really good over the years and are really a testament to the quality of compiler engineers. Even so...
I've been a programmer for over a decade and I've always found the worst problems to debug are when the problems aren't in your code but in the compiler. Compilers are programs too and have their own bugs. They aren't always 100% accurate at generating correct machine code for your source. And until the compiler gets fixed in the next patch or rev, you may be stuck with broken code unless you switch compilers.
Sometimes disassembly of the problem code and inlining correct assembly can be the difference between shipping a product or missing a deadline because you've spent months sitting around for the next compiler version to fix your problem for you.
According to this ZDNN article Jonathan Schwartz says that they will be exactly addressing importing of Excel macros. I haven't seen any specification on it yet, but the people working on it may have preliminary stuff or discussions going on in the "sc" project. Generally, anything added into StarOffice that isn't encumbered by licensing or copyright restrictions makes its way into OOo...most all SO development is done right in the OOo CVS repository.
Counter to what the competitive points claim, Sun provides fee based support for the top-tier platforms (Linux-x86, Solaris, Win32) for OpenOffice.org, not just for StarOffice. It's right in the "Commercial Support and Training" portion of the OOo support homepage next to the Sun logo. There are also some other firms and independent consultants listed. Gee, not only can you get paid support from Sun, but price around your support needs as well! You'd think that if MS is trying to sell Office with support as a major bullet point they could at least have given the webpage a look!
While I can't speak for other places, on trinity where I host and answer OOo OS X support forums there's usually a Mac OOo expert answering questions within one day of asking. There are non-programmers who volunteer their time to help new people with installation, deployment, how-tos, etc. It seems unfair to belittle one-on-one expert help just because it's done for free:)
I sent Scott an open letter on behalf of NeoOffice.org nearly one month ago and haven't yet heard a response and no discussions are ongoing. It's really a straightforward request for myself and a few other OOo volunteers, and we can't even get publicly snubbed! I wonder what Eric Raymond and IBM have that we don't...
ed <---the ninth insignificant wonder of the world
Just because they're aware doesn't necessarily mean they take their own knowlege into account. Does Messenger support vertical text for Japanese (or AIM, or iChat for that matter...I honestly don't know)? Is the user interface assumed for these apps even usable for vertical text input and display? I know my IM text input line is at the bottom of the chat window and near assumes top to bottom text ordering.
It's easy for programmers who know no language aside from English or a Romance language to make these fundamental assumptions about language orientation. Nothing aside from changing the code or design of the program is going to help.
Mozilla still doesn't support the standard
At least Mozilla provides concerned governments or localization teams the source code to the program so they can try to fix the problem. The potential for full localization is present in OSS apps even if not yet fully realized.
Nah, my vocabulary is just ancient...after all, Adobe certaintly isn't god when it comes to terminology. I'm just a dumbass for not knowing any better;) The FM 5.5 manual is also insanely out of date. I think it was 1997-1998 or so when 5.5 came out.
Ironically, this all goes to show just how dynamic language can be too. A translation made today may be outdated 5 yrs from now (like my useless knowledge;)
Probably misunderstood terminology from my old FrameMaker days. I am not a Japanese speaker myself and am unfamiliar with what it is actually called in Japanese. From the FrameMaker 5.5 manual, page 93:
Rubi text is made up of small characters (usually kana) appearing above other text, called oyamoji. You can control the size of rubi text as well as how it is spaced and aligned with respect to its underlying oyamoji text. Your settings affect rubi text throughout a document.
While I never used it myself, I always was struck how FrameMaker offered more control over this type of text then every other application. I never saw anything like it in any other app (including OOo!).
ed
(offtopic, but I wish FrameMaker was OSS as well so I could run through and Carbonize it...)
Check out the Link Grammar Parser. I've found it pretty good at locating erroneous phrases, but it's not perfect and doesn't have the ability to make suggestions to correct grammar. Integrating it with OOo/Neo is one of my pet projects now that it has more compatible licensing.
Getting really good grammar checking in English is difficult enough and it's a shame that other "lesser" languages like Estonian don't have tools anywhere near the caliber of those for the English language. Even if MS made all of the rules of the system are made available for folks to work within, I'd put a bet on the fact that there's some language that just can't conform to those rules. To really work with languages it may be required to extend the underlying system, not simply conform to it. Not to mention debugging such development without some type of source code/symbols/dev tools would be hell...
Unfortunately MS fails to realize that simple translation may not be enough. Take Office v.X on the Mac for example. It's lack of full RTL and Unicode support means some languages can't be supported, even if just the interface is translated. Rubi for Japanese is another language feature that may require access to the source code itself. Not to mention other tasks like modifying their English grammar checker to support new languages...
Merely providing the ability to make a "Language Pack" and translate the strings on the screen does not provide enough access to really support foreign languages. Without full access to the source code, foreign languages will still remain second class citizens
The OpenOffice.org localization argument for serving niche markets has been around for a long time. A prime example of that is the Hebrew Office v. X incident. For me personally, however, I see OSS as a great way to provide competition in non-profitable markets such as office suites.
It's near impossible to try to form a cogent business plan around making office productivity software given the current state of the market. Microsoft has office suite dominance almost as large as Windows market share, and may even be more. Most every company has created some type of workflow based on Office and has legacy documents in Office formats that may stretch back for decades. With the advent of Visual Basic for Applications and Access, companies have also been writing custom business applications coded to work only with Office.
It's difficult to convince investors to pour money into a startup where you're competing directly against Microsoft, especially in a market where they've got the upper hand, established customer lock-in, and decades of software development. As an investor it's almost a sure bet that any money dumped in such a startup would be lost. It's near impossible to create a viable long-term self sustaining business with Microsoft as your competitor in a market they've already monopolized.
Open source software doesn't need to abide by the standard rules of business. It doesn't need to create a revenue stream and find investors. It doesn't need to worry about being underpriced by market dumping practices. As long as there are starving (or subsidized) programmers willing to work on it and eager users, OSS can produce competition in a market where convential businesses would most likely fail. This is one of OSS's greatest strengths.
Competition is at the core of evolution and innovation. It's comforting to know that OSS keeps open these avenues for competition when traditional capitalism fails. Hopefully this will help motivate both the OSS alternatives and Office to continue to improve and evolve.
Ack. the "uninteresting" in the first paragraph refers to my thesis, not the one I linked to. Apologies. Friggin inability to edit on/. is almost as frustrating as debugging PHP.
My obligitory Google searching turned up a rather unexpected thing...a PDF version of a Princeton undergraduate thesis (warning...336K PDF) on sampling in the recording industry. It's actually been an uninteresting read thus far (quite unlike my undergraduate thesis, that is, unless you like reading about graphical interfaces for Fortran namelists).
It starts off with an interesting history of the development of folk music in this country and how new words were put on standard melodies or lyrics were appropriated into new songs. Continues on to give an overview of the history of sampling. Best quote I've seen thus far: "the current system of copyright misrepresents the creation of music, considering it a purely original act rather then an event in a cultural tradition".
The thesis goes on to propose that fair use laws should be revised and a compulsatory licensing system put in place for sampling similar in structure to current "cover" style licensing to help avoid just the kinds of lawsuits while constructing a creative artistic environment. The application of copyright law in the US is so twisted these days that perhaps a system like this is needed. We really as a country should start some serious rethinking about how old concepts should apply to the modern world.
the rose-tinted goggles through which people view any statement from Novell/IBM/RedHat/Linus/etc. serve no purpose
Yeah, I was more referring to the propoganda that's been effluving out of all of these companies in the form of press releases citing more evidence. The/. press spin rantings would probably be nearly as effective as calling a Magic 8-ball to the witness stand.
Nice try. No court is going to interpret a contract based on what a very obviously biased community *wants* it to say.
I was also thinking about the other side's propoganda too. IIRC SCO made public claims last year that they have statements from former Novell executives at the time of the sale of Unix that indicated Novell intended to transfer all copyrights to SCO. I'm sure SCO has more of the same to back up their claims. What makes that type of argument different from Novell using $ echo? Neither are actually in the contract itself, but are rather supporting evidence for trying to interpret it "in context". I'm just curious to know if that style of defense actually counts in contract disputes.
Slashdot Mirror
Disclaimer: I am one of the members of the Mac OS X OOo team and a founder of the NeoOffice project
OpenOffice.org X11 on the mac is effectively dead because it is horrendously understaffed. There are less then 5 people actively working on it. Not good for an 8 million line + application.
While Apple's developer documentation may be first class, OpenOffice.org X11 is not built using Apple-specific technologies. It is built from the command line and is using X11 with its own internal widget toolkit. Oh yeah, and takes 9 hours to compile on a dual G5 2GHz. That hurdle is a bit too high for just someone to stroll on in and casually check out the project.
OpenOffice.org is a large and thorny Unix application. There are very few Mac OS X programmers that actually have X11 and Unix skills and the patience to deal with something of its size. Most developers come to the project and are like "can I build it in XCode" or "can I use InterfaceBuilder", find out they can't and then leave. The lack of a sufficiently large pool of skilled volunteer programming experts effectively killed OOo on the Mac from the start.
The native work has effectively moved to the NeoOffice/J project, which is 95% code identical to OpenOffice.org and uses Carbon and Java instead of X11. It still doesn't use Apple development tools directly, but it does have two of the original developers of OOo Mac OS X working on it continuously.
ed
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
Wouldn't it be great if they listed them? They only say that it covers patents they may have in their schemas. Determining which patents they're referring to or which patents you're actually licensing from them is left as an exercise to the reader. It could be none, or it could be things like their patent for "Methods and Systems for Generating XML Documents" (USPTO 6675353).
If you want to figure out what patents are used, if any, you ve not only got to go through and read the schemas and search through and read any Microsoft assigned patent that could possibly pertain to XML. Given how broad claims of patents can be are, the patent may not even have the words "XML" in it.
And that's just to write a silly MS Office XML file filter.
It's a much smaller problem then the one that independent developers now face when working on OOo. Sun is the primary contributor to OOo and does volumes more work then the community. They now have patent protection with Microsoft so all of their code can use any MS patents they want, consciously or unconsciously. But the moment I "cvs checkout" that source, I'm open to liability for using Microsoft's patents without a license. Unless Sun divulges if any of their code uses patents (unlike that MS license agreement that doesn't even say what you're licensing), the only way for me to avoid getting sued is to actively read all of Sun's contributed code *and* all of Microsoft's software patents to make sure none of the Sun code infringes on *any* of Microsoft's software patents.
I doubt anyone has the time to do that. OOo is over 8 million lines large and it's nearly impossible to fully comprehend, much less cross-reference with software patents with overly broad claims.
ed
In order to contribute code into OOo that gets committed and incorporated into the main product, you (or your company) must file a Joint Copyright Form (warning: PDF. No HTML version is available). It is essentially dual-copyright assignment. Both you and Sun have a copyright to your contributions, so Sun can continue to do whatever they want with your contributions including relicense them under different terms.
The work I've done in my projects outside of the OOo source code repository falls outside of the jurisdiction of the JCA. I and I alone own the copyright to that work and choose to license it as I wish.
So no, I can't get recompense for anything I've contributed back into the OOo source code repository itself since Sun owns it too. If I find any of my other outside code in the repository and I myself haven't committed it there, then it's a violation of coypright provided it's not compatible with SISSL licensing.
As OOo is LGPL licensed, the reverse isn't true...Sun can't do anything to me if I use the code in other outside projects, provided they're compliant with LGPL or SISSL licensing. Submarine patents, however, are a different story. Neither LGPL nor SISSL provide patent protection for derivative works.
ed
Disclaimer: I am a Mac OS X community developer for OpenOffice.org and a founding member of NeoOffice
.doc and other Office formats. So they were clever...
.doc format...but Microsoft has prevented anyone from using their patented schema in a "free as in beer" environment. These clauses in TFA allow Sun a cop-out: Sun can freely write code and use it in OOo that uses the Microsoft Office XML schemas. In the Sun-branded OOo distributions (Linux-x86, Solaris, Solaris-x86, Windows only...they have a Sun logo on the startup screen) Sun is free to use the patented Office schemas as well. Because of this, Sun will most likely contribute the code to work with these schemas into the core source code of OOo.
There is one obvious reason for this clause that I can think of off of the top of my head. Microsoft Office XP has a feature by which Office documents can be saved in an XML format. Obviously, this means that the information in the resulting Microsoft Office generated files is not as obfuscated as it is in a binary format (provided key information isn't just base64 encoded into elements). Microsoft knows this feature can negate the lock-in to
Microsoft has patented their XML schemas. In order to write software that uses these Microsoft Office XML schemas, you must sign a patent license with Microsoft.
Obviously, OOo will want to be able to open these new Microsoft Office XML formatted files similar to its support for the
Other companies make derivatives of OOo too (Red Hat, Novell/Ximian, BSDMall), individuals like myself, and even just translators non-Sun builds for mainline platforms who don't program at all. The Sun-MS agreement says that Sun's patent licensing for the Office Schemas does not apply to any OOo derivatives or builds that are done outside of Sun. Either all of these companies and individuals need to sign the Patent License Agreement with Sun or else they are open to lawsuits from Microsoft and potentially pay royalties to Microsoft in the future to use their schema.
It's really another clever way Microsoft has come up with to continue to ensure their file formats remain closely guarded and their own property.
As to whether a patent of an XML Schema can stand up in court, well, I know I personally as a single developer don't have the kind of money to challenge Microsoft on patent litigation if they sue me as an individual. Unfortunatley I have neither the time nor the skills to scrutinize all of Sun's contributions to OpenOffice.org's source code to see if they use Microsoft's patents in such a way that's legal for them, but not legal for me. I either must take my chances or stop being a non-Sun developer of OpenOffice.org. Unfortunately now any non-Sun entity working on OOo has to make that choice for themselves.
ed
(Disclaimer: I'm the lead volunteer for OOo Mac OS X)
There is no Java in OpenOffice.org. It is just horribly inefficient C++. The only time Java is used in OOo Mac OS X is during the build process to validate some XML configuration documents; at runtime it doesn't need Java at all. That's why it's possible to run on DarwinPPC even though you can't compile it on DarwinPPC.
Remember, it wasn't written by Sun, but by Star Division. It was started back in the mid to early 1990s and was definitely back in the day before the AWT was anywhere near stable or cross platform. It may have even been started before Java, but I'm unsure of the timelines.
ed
Just an FYI, the slow startup time isn't actually due to Java. It's still 98% C/C++, and the slow startup time is actually due to inefficiencies in "ucb" and writing out an initial temporary registry database. That step is written in C++ and takes about 3 seconds by itself. Another large chunk of time is spent loading the hundreds of megs of shared libraries, all of which are written in C++.
:)
The parts of it that are Java are actually on par, if not faster then their X11 equivalents. Feel free to break out Shark and take a look for yourself
ed
The first place to start would be to read through the official OOo 1.1.2 Installer FAQ which has answers to this as well as other support issues and questions. There are a number of other FAQs on trinity that can help you address problems.
;)
Also don't be afraid to post and browse through the online support forums where users exchange hints, tips, bug reports, and the like.
All of us volunteers have put up extensive OOo support resources for Mac OS X users, and there are links to all of them on the "Support" section of our website and even in the README included with the installer itself! We spend a lot of time helping users get things working. If something doesn't work, why not try taking advantage of all the written documentation and live volunteer support? It seems that open source is no different then commercial apps...people still don't read the manuals
ed
(PS: the answer to your problem is that OOo is already installed by that point in the install process...you may just be missing one or two fonts, but it works just fine)
"Your uncle molests collies".
But little did you know until now that they really understand your cries of 'you like that, don't you bitch'.
ed
One thing that many programmers take for granted these days is that compilers produce correct code nearly all the time. They've gotten really good over the years and are really a testament to the quality of compiler engineers. Even so...
I've been a programmer for over a decade and I've always found the worst problems to debug are when the problems aren't in your code but in the compiler. Compilers are programs too and have their own bugs. They aren't always 100% accurate at generating correct machine code for your source. And until the compiler gets fixed in the next patch or rev, you may be stuck with broken code unless you switch compilers.
Sometimes disassembly of the problem code and inlining correct assembly can be the difference between shipping a product or missing a deadline because you've spent months sitting around for the next compiler version to fix your problem for you.
ed
According to this ZDNN article Jonathan Schwartz says that they will be exactly addressing importing of Excel macros. I haven't seen any specification on it yet, but the people working on it may have preliminary stuff or discussions going on in the "sc" project. Generally, anything added into StarOffice that isn't encumbered by licensing or copyright restrictions makes its way into OOo...most all SO development is done right in the OOo CVS repository.
ed
Counter to what the competitive points claim, Sun provides fee based support for the top-tier platforms (Linux-x86, Solaris, Win32) for OpenOffice.org, not just for StarOffice. It's right in the "Commercial Support and Training" portion of the OOo support homepage next to the Sun logo. There are also some other firms and independent consultants listed. Gee, not only can you get paid support from Sun, but price around your support needs as well! You'd think that if MS is trying to sell Office with support as a major bullet point they could at least have given the webpage a look!
:)
While I can't speak for other places, on trinity where I host and answer OOo OS X support forums there's usually a Mac OOo expert answering questions within one day of asking. There are non-programmers who volunteer their time to help new people with installation, deployment, how-tos, etc. It seems unfair to belittle one-on-one expert help just because it's done for free
ed
I sent Scott an open letter on behalf of NeoOffice.org nearly one month ago and haven't yet heard a response and no discussions are ongoing. It's really a straightforward request for myself and a few other OOo volunteers, and we can't even get publicly snubbed! I wonder what Eric Raymond and IBM have that we don't...
ed <---the ninth insignificant wonder of the world
ed
Just because they're aware doesn't necessarily mean they take their own knowlege into account. Does Messenger support vertical text for Japanese (or AIM, or iChat for that matter...I honestly don't know)? Is the user interface assumed for these apps even usable for vertical text input and display? I know my IM text input line is at the bottom of the chat window and near assumes top to bottom text ordering.
It's easy for programmers who know no language aside from English or a Romance language to make these fundamental assumptions about language orientation. Nothing aside from changing the code or design of the program is going to help.
Mozilla still doesn't support the standard
At least Mozilla provides concerned governments or localization teams the source code to the program so they can try to fix the problem. The potential for full localization is present in OSS apps even if not yet fully realized.
ed
Ironically, this all goes to show just how dynamic language can be too. A translation made today may be outdated 5 yrs from now (like my useless knowledge ;)
ed
Rubi text is made up of small characters (usually kana) appearing above other text, called oyamoji. You can control the size of rubi text as well as how it is spaced and aligned with respect to its underlying oyamoji text. Your settings affect rubi text throughout a document.
While I never used it myself, I always was struck how FrameMaker offered more control over this type of text then every other application. I never saw anything like it in any other app (including OOo!).
ed
(offtopic, but I wish FrameMaker was OSS as well so I could run through and Carbonize it...)
Getting really good grammar checking in English is difficult enough and it's a shame that other "lesser" languages like Estonian don't have tools anywhere near the caliber of those for the English language. Even if MS made all of the rules of the system are made available for folks to work within, I'd put a bet on the fact that there's some language that just can't conform to those rules. To really work with languages it may be required to extend the underlying system, not simply conform to it. Not to mention debugging such development without some type of source code/symbols/dev tools would be hell...
ed
Unfortunately MS fails to realize that simple translation may not be enough. Take Office v.X on the Mac for example. It's lack of full RTL and Unicode support means some languages can't be supported, even if just the interface is translated. Rubi for Japanese is another language feature that may require access to the source code itself. Not to mention other tasks like modifying their English grammar checker to support new languages...
Merely providing the ability to make a "Language Pack" and translate the strings on the screen does not provide enough access to really support foreign languages. Without full access to the source code, foreign languages will still remain second class citizens
ed
"Made in East Fishkill, crafted in Cupertino"
ed
Disclaimer: I work on OpenOffice.org OS X
The OpenOffice.org localization argument for serving niche markets has been around for a long time. A prime example of that is the Hebrew Office v. X incident. For me personally, however, I see OSS as a great way to provide competition in non-profitable markets such as office suites.
It's near impossible to try to form a cogent business plan around making office productivity software given the current state of the market. Microsoft has office suite dominance almost as large as Windows market share, and may even be more. Most every company has created some type of workflow based on Office and has legacy documents in Office formats that may stretch back for decades. With the advent of Visual Basic for Applications and Access, companies have also been writing custom business applications coded to work only with Office.
It's difficult to convince investors to pour money into a startup where you're competing directly against Microsoft, especially in a market where they've got the upper hand, established customer lock-in, and decades of software development. As an investor it's almost a sure bet that any money dumped in such a startup would be lost. It's near impossible to create a viable long-term self sustaining business with Microsoft as your competitor in a market they've already monopolized.
Open source software doesn't need to abide by the standard rules of business. It doesn't need to create a revenue stream and find investors. It doesn't need to worry about being underpriced by market dumping practices. As long as there are starving (or subsidized) programmers willing to work on it and eager users, OSS can produce competition in a market where convential businesses would most likely fail. This is one of OSS's greatest strengths.
Competition is at the core of evolution and innovation. It's comforting to know that OSS keeps open these avenues for competition when traditional capitalism fails. Hopefully this will help motivate both the OSS alternatives and Office to continue to improve and evolve.
ed
Ack. the "uninteresting" in the first paragraph refers to my thesis, not the one I linked to. Apologies. Friggin inability to edit on /. is almost as frustrating as debugging PHP.
ed <--- bonehead
My obligitory Google searching turned up a rather unexpected thing...a PDF version of a Princeton undergraduate thesis (warning...336K PDF) on sampling in the recording industry. It's actually been an uninteresting read thus far (quite unlike my undergraduate thesis, that is, unless you like reading about graphical interfaces for Fortran namelists).
It starts off with an interesting history of the development of folk music in this country and how new words were put on standard melodies or lyrics were appropriated into new songs. Continues on to give an overview of the history of sampling. Best quote I've seen thus far: "the current system of copyright misrepresents the creation of music, considering it a purely original act rather then an event in a cultural tradition".
The thesis goes on to propose that fair use laws should be revised and a compulsatory licensing system put in place for sampling similar in structure to current "cover" style licensing to help avoid just the kinds of lawsuits while constructing a creative artistic environment. The application of copyright law in the US is so twisted these days that perhaps a system like this is needed. We really as a country should start some serious rethinking about how old concepts should apply to the modern world.
ed
Go 99 Tigers!
the rose-tinted goggles through which people view any statement from Novell/IBM/RedHat/Linus/etc. serve no purpose
/. press spin rantings would probably be nearly as effective as calling a Magic 8-ball to the witness stand.
Yeah, I was more referring to the propoganda that's been effluving out of all of these companies in the form of press releases citing more evidence. The
ed
Nice try. No court is going to interpret a contract based on what a very obviously biased community *wants* it to say.
I was also thinking about the other side's propoganda too. IIRC SCO made public claims last year that they have statements from former Novell executives at the time of the sale of Unix that indicated Novell intended to transfer all copyrights to SCO. I'm sure SCO has more of the same to back up their claims. What makes that type of argument different from Novell using $ echo? Neither are actually in the contract itself, but are rather supporting evidence for trying to interpret it "in context". I'm just curious to know if that style of defense actually counts in contract disputes.
ed