Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
Well, as it turns out my update to the timeline was grossly misquoted in a couple of places. The update was really just to put things in perspective as to what was really going on in the various projects as well as to reinforce the importance of the X11 work. It was never intended to "cancel" anything since, well, there wasn't really anything to cancel. The update was just stating how things really are within the project.
Today's article on eWeek has some much better reporting on the progress towards 2.0 X11 and other issues that had been raised by my update. I highly recommend giving it a read as it's a bit more informative then the old/. comments in that thread.
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
I happily noticed this myself earlier on in the week and was impressed to find the OpenOffice.org related section. Unfortunately there are some inaccuracies in the section, but I couldn't find any address to which corrections should be submitted.
Perhaps the most major omission is that the OpenOffice.org Mac OS X (X11) installer is not limited to 10.3 only. In fact, it supports both 10.2 and 10.3. For 10.2 users it also will automatically install XFree86 and a window manager if the system does not have XFree86 on it. Since Apple X11 is not redistributable under its license, 10.3 users are required ot manually install Apple X11. Ironically, that makes installation on 10.3 more inconvenient then 10.2!
On the trinity forums Smokey also noticed the file format "incompatibility" line in the article. It isn't actually true since OpenOffice.org is 100% compatible with StarOffice which, last I checked, is a commercial office suite even if it doesn't run on Mac OS X:)
Even with the little foibles, it's great to see support from Apple for X11 applications in general as well as a basic introduction that can help open up the entire world of X11 OSS applications for users, not just OpenOffice.org.
So by this post we have bona fide proof the export filters of Pages are not perfect and, thus, has confirmed the original intent of the thread, that compatibility with Word documents and other formats is troublesome. Amazing...offtopic topic rebuttals are rebutted by their own poster. Astounding.
ed <-- does this mean this whole thread is leaked by System.gc()?
Definitely I'm aware. There's a reason why some slack COO (or whatever title he has now) of Sun wouldn't open source the source code for the old Lighthouse suite of apps (Create and friends, I understand why FrameMaker couldn't be licensed even though I wish it was). And Schwartz is even COO or whatever other title of the week he has. Sun should own the Lighthouse source code from their buyout in the previous age of this world, but that code has just magically disappeared despite a number of folks asking if they could open source that instead of the non-native OOo code.
[tinfoilhat]Sun may very well be the new cloakroom wheeling-and-dealing Satan of our time![/tinfoilhat]
Disclaimer: I'm a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
I've seen this mentioned in a number of places now. I just watched the QuickTime feed of the keynote for the iWork section (starts at about 1hr 3 mins) and heard no mention of spreadsheets or "Cell" in that section. It goes straight from pages to the Mac mini. Did I just miss it?
Also of note: while it appears iLife is going to continue to be bundled with new Macs, it is unclear if iWork is going to be bundled at all. I don't think Keynote is presently bundled with any configs, but they just may not have yet updated the Apple store. It would truly honk for low-end Macs if the death of AppleWorks meant that users had to pay for software. Kinda funny since, after all, they include GraphicConverter but don't bother to preload a FOSS office suite;)
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
[quote]Pages' layout features look as if they surpass Word like Keynote surpasses PowerPoint.[/quote]
This does, however, get to the root of the problem of document compatibility which is, in my mind, one of the key requirements of the mixed-platform business environment. While I don't dispute that Pages may be better for documents with those types of layouts, I wouldn't expect that the Word export of those documents will be 100% compatible.
Case in point:
Make a 2 slide presentation in Keynote.
Use a "Cube" transition effect.
Save and export to PowerPoint
Open in PowerPoint for presentation. Notice how PowerPoint doesn't do the spinning Cube transition even though theoretically you saved it in the file.
While cool features make for a nice application and probably a more functional one, they don't make for seamless document compatibility. When editing and exchanging documents with the 90%+ of corporations that use and archive their content in Microsoft Office formats, these snafus can prove to be quite a challenge.
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
No, the new iWork is definitely not a replacement for the old AppleWorks/ClarisWorks suite. AppleWorks really did try to do a "kitchen sink" approach as well as give you the flexibilty to embed one type of document in another. I really suspect their decision to focus on word processing is very good from a market driven perspective.
Most people tend to want to be able to write simple letters on their computer. TextEdit could do this, of course, and for simple tasks I do know people who use it. The next class of users is advanced home and entry-level business personnel. Think of the kind of people that want to make a flyer advertising a store event or the people making a newsletter for their little league. These are the exact target audience for Pages.
Pages comes with 40 templates that are customizable in the sense you can add in your own graphics easily to creat new templates (I think...). This makes it easy to create newsletters, corporate letterhead, and the like. The transparency allows for easy watermarking of documents.
Pages will also probably be sufficient for opening most Word documents generated by these similar types of users, home or small business users who have Word pre-installed on their Windows box and use the DOC format to e-mail their newsletters as attachments. In that respect it's great to have a similar pre-installed option available on the Mac that can support that market segment.
Whether they will target spreadsheets and database connectivity in the future is still up for speculation. After all, even Claris killed its own standalone spreadsheet application (Resolve) by selling it off to C&G. For users who want an integrated suite full featured spreadsheets, charting, macros, database connectivity and the like, there's only a few remainingplayers in the Mac market: Microsoft Office, NeoOffice/J (OpenOffice.org, but without the X11), ThinkFree, and Mariner. I don't think Apple's about to compete with Microsoft Office anytime soon as they use Office to help sell the platform. The death of AppleWorks now leaves us open source guys as one of the remaining strongest office suite competitors on the platform.
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
If Keynote is any indicator, they will most likely not support OpenOffice.org or OASIS formats. There is also no OASIS or XML option in the screenshots of their filter sheet. While it's unclear from the limited info on the website, Pages may save either in RTF or in its own internal format. If it's internal, Apple most likely will open up this file format over time.
When Keynote first came out its file format was "secret" unless you wanted to reverse engineer the XML. A month or two after the software came out they did publish the Keynote schema for their documents. So they are using an open file format for Keynote, even if Keynote is the only application that uses it.
I spec'd a Keynote filter for OOo/NeoOffice a long time ago but no one has taken up the task of implementing or revising that specification. Being able to import Keynote formatted documents just isn't really a commonly requested feature (definitely much less so then Aqua user interface) so I haven't spent my own time on it.
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
Just the fact that you can import and export doesn't exactly mean it's 100% compatible. Heck, even Office v.X/2004 isn't 100% compatible with Windows Office generated files. One of the strengths of OpenOffice.org and NeoOffice is the accuracy of their import and export filters.
I wouldn't suspect Pages would be successful converting Word documents that have embedded Excel spreadsheets and charts those that go trapesing off to do database queries with macros. I suspect Pages would convert them to tatters.
While Pages may be sufficient for doing the basics of letter writing and entry-level document preparation, many of the more complex business level documents still will require Microsoft Office or an equivalent alternative. Office may be bloatware, but that doesn't prevent people from finding a way to use all of those features and then complaining when they don't work in another product. That makes true document compatibility a difficult task that can't fully be addrsesed by a word processing application alone.
FWIW, one of the primary reasons that neither OOo, NeoOffice/J, nor AbiWord have grammar checkers is that no good open source grammar checker tools exist yet. Just about any grammar checker worth its salt is completely closed source. There are some options available, though...
The Link Grammar Parser is one that I've actually been keen on integrating with NeoOffice/J for quite some time. I have ideas on how to do so but have not yet had time to devote to it. I had been waiting for an OSS license for a couple of years for it, but unfortunately I think their new license was incompatible with GPL and can't be used in OOo or NeoOffice/J. Aside from that parser, I don't really know of any other good OSS grammar projects for English, much less all the foreign languages that need to be supported too!
If you have knowledge of any other OSS grammar engines (or contacts for acquiring and freeing source code for a defunct grammar checker like Correct Grammarplease contact me!
Unfortunately that file format hasn't been reverse engineered yet. We're not focusing on doing the reverse file format engineering ourselves. We just don't have the resources (two programmers!) to focus on the old Mac file formats, or even the new Mac file formats like Keynote. I wrote some design specs to get developers started if you're curious, but I haven't had the time to do engineering for those features.
The only "old school" Mac app that has had its format engineered is the old Mac WordPerfect, thanks to the OOo WordPerfect filter team. They integrated their code into NeoOffice/J and now we can sort of open the old Novell/Corel WordPerfect 3.5 formatted files. Note this still doesn't give you "show codes", just the files. I think the old MacLink Plus may have had a Word 5.1 to WP translator, though, so that might be a way to get at your legacy docs even if it is convoluted as all hell.
At one point in antiquity, both J and C were prototypes. C was really a hack to explore technologies, but J was engineered a bit more carefully. The idea was eventually that OOo X11 would yield to the short-term solution of J to the long term solution of C.
Unfortunately, Cocoa was just too difficult to fit to the OOo event model. While I hacked and struggled with Cocoa until he smote my ruin upon the mountainside, the Java+Carbon of J the amazing engineering of Patrick and his testing crew was triumphant and created a stable, functional app. When it comes down to it, redoing all that work in Cocoa is just reinventing the wheel for no tangible benefit aside from pure geek thrills. Even if done, the result still wouldn't be using ObjC, Interface Builder, or any of the other tools that make Cocoa so scrumptious. It'd be the penultimate Cocoa hack job. Doing OOo in Cocoa is kind of like trying to ram a square peg into a round hole. Cocoa suffers from the fatal flaw of all framework technologies; they really don't work well for building apps that are not engineered to conform to the framework design.
Frustrated with Cocoa, the decision I came to was to shelve C for a while and go join Patrick and help him bring Aqua into J, stop splitting our efforts, and combine to make a kickass app. Thus the Aqua menus were born with the other widgets to come. Eventually when J is finished, I am hoping to find time to take the "core" parts of J out and wrap them into a framework that can then be embedded into Cocoa apps, similar to the Gecko engine. That's a long way off yet...
For more of my own logic read a more detailed discussion about why J is the best engineering choice for now.
Don't forget that OpenOffice.org itself is huge, and it is a C++ application. It's actually a beautiful example of how horridly slow C++ can get, both running and compiling. NeoOffice/J is just OpenOffice.org with some extensions.
I did a line count analysis a while back in response to some FUD spreading, but it's probably still roughly accurate. On a source code level, less then 2% of NeoOffice/J is actually Java. 98% of the code is straight from OpenOffice.org. And not all of the NeoOffice/J code is in Java, so the actual figure is probably less then that.
On a binary level, the size of the combined JAR files for NeoOffice/J and OpenOffice.org are only 3.7 MB of the application's 317 MB footprint. And those JAR files include the support OOo has for Java applets, DocBook filters, and the like. The "Java" magic NeoOffice/J adds to OpenOffice.org is essentially contained in a single file "vcl.jar", which is 70k. I'm sure someone can do those percentages themselves as I left my RPN calculator at home;)
We're not a non-profit but we're also not a commercial entity either. We're a group of volunteers who are doing this and hosting the project. For two years we didn't have any type of donate page or the like and just encouraged people to contribute by answering questions in forums, testing, or developing. Funny enough, there are still people who don't want to contribute in those ways. This started a fairly vigorous discussion as to whether we should give those people another vehicle for helping out. You can check out the user community debate back in November as to how things wound up the way they are now and where they will hopefully be going.
To organize as a non-profit in the state of California requires filing paperwork, meeting minimum tax requirements, and other state and federal requirements. We're not expecting to see a lot of monetary donations, so instead of shelling out all that capital to set up a new corporate entity and lose money we don't have (!) we just reused one of the S-corps we already had set up.
We couldn't just take money directly as that opens us up to personal legal liability, a bad thing for us Americans with our predatory legal system. We also can't afford to do it personally due to tax reasons. Right now we're only hoping to get enough to pay for bandwidth and hosting costs. If people actually do start donating enough though we've already decided we'll go through all the hassle of setting up a non-profit entity. It's unfortunately not worth that much hassle for just a few hundred dollars in donations;)
Still, I'd rather encourage people to donate time, support, and hopefully code instead. It's much more useful then money. Unfortunately time and code are more then most people are able or willing to give:(
While the link in the story is to the English download pages, the site itself has the download instructions, FAQ, and other pages available in Dutch, French, German, Italian, and Japanese. You can use the language links at the top of the page or link to the language-agnostic download link which will redirect you automatically to the correct language based upon your browser user-info string.
Disclaimer: I am on the OOo Mac OS X team and a founder of NeoOffice. The opinions expressed here are personal and don't reflect official positions of either organization, Apple, Sun, or my employer.
People have definitely been wondering why Apple hasn't supported or started their own engineering work on OOo themselves. In my own opinion, I think the real reason why they haven't is pure politics. For better or for worse, the Apple platform really does need Microsoft Office. Think of how many Apple marketing materials include references to Office. It even makes it into their technical pieces with phrases along the lines of 'I can run my Unix chemical structure modeling software and still use Powerpoint on the same box!'. I also personally have many switcher friends who really require being able to do work in Office on their home machine for business, and probably they would not have been able to switch without it. Office is a crucial piece of software to have available for the viabilty of the platform.
If Apple started very public support for OOo (e.g. by firing off lots of engineering resources at it), it could easily jeopardize the continued development of Microsoft Office for OS X now that there's no agreement in place. Don't forget how quickly Adobe dropping Premiere after FCP was released. There's precedent from Microsoft as well with the release of Safari having been cited as one of the primary motivators for dropping Internet Explorer OS X development (a horrid shame as, yes, there are still a few web sties that require VBScript).
So although there may be many good logical arguments for why there should be support for a project like OOo, or even an enhanced business oriented AppleWorks derivative, there's always that one good motivator for not doing so...the continued existance of Microsoft Office for Mac OS X. Given its current positioning as bullet 8 on their top 10 reasons to switch, I highly doubt that Apple would make any type of moves that would jeopardize Office.
It's not that the boxes are slow...the compilers and linkers that we have to use just suck, especially as to maintain 10.2 compatiblity requires using 10.2 dev tools that don't have most of the recent optimizations Apple's been doing in their compilers..
The native theming work was actually pioneered in NeoOffice/C Flaming Yeti back in 2002. Dan, who helped me get the intial widget stuff in, moved on to be one of the primary architects of the Native Widget Framework that does the theming in 2.0.
While NeoOffice/C was way to hacked to make the transition into a maintainable project, NeoOffice/J is actually using portions of that framework for the Aqua menus. We 'backported' 2.0 into 1.1.x to do the most requested native widget (and arguably the most complex) menus. Having it in the official 2.0 sources helps us because it means we won't have to hack to make the infrastructure ourselves:)
Thanks for the well wishes:) The good thing is that the patches are mostly to sections of code that are moderately stable. Most of the source tarball winds up being the new Carbon and Java code that's replacing the X11 code. As long as we can keep up with changes to the interfaces things will be good. The worst one for Patrick was adding right-to-left and vertical text support, but beyond that I can't imagine any other drastic unanticipated changes to how OOo expects to draw lines;)
ed
Well, he's not got any plans for 2.0 Mac OS X either and there are certainly no paid engineers working on native OS X support for OpenOffice.org. It's a shame when folks have to start talking smack citing their own vaporware, and this is even free software;)
As to "do the work all over again", Neo/J isn't engineered that way. It's actually only over a meg tarball in size. It's so small that the source is actually included in the installer dimages. The way it works is that Neo/J first automatically downloads and builds OpenOffice.org X11. After that, it replaces the X11 components with its own. The X11 dependent components are actually quite small when compared to the largesse of OOo.
Read further along for great comments like the disinformation in this which omits our 2.0 plans. There's other ones like this where the project is described as "harmful and destractive" to OpenOffice.org. And this was all in response to a user just saying he enjoyed NeoJ.
If responses like those are not politics and scare tactics, I don't know what is.
(and yes, we do have patches that we've relicensed and submitted that do not get committed back into OOo, such as UTF8 filename support).
Disclaimer: I am a member of the OOo Mac OS X "team" and a founder of the project.
NeoOffice/J isn't a prototype anymore. It got so good and stable that we decided to make it an official project. We just haven't changed the slogans and copy yet. NeoOffice/J 1.1 is going to be going beta this week, based off of OpenOffice.org 1.1.3 (not even available for Mac OS X X11). It will contain Aqua menus, too.
After we work out all the bugs and get NeoOffice/J 1.1 to final release, we're going to plow ahead with scrollbars and buttons and whathaveyou for a 1.5 release. We'll also be starting on the native work for 2.0 sometime next year, but that will take some effort, considering OOo 2.0 isn't finalized yet.
Our goal is to put out a final NeoOffice/J that is stable, well tested, polished, but most importantly, fully functional. It's generally our opinion that it's more important to be bug-free then pretty. It doesn't matter if it's got pretty blue buttons if it crashes after typing 5 words, and there are definitely testers and users who agree;)
Although there's no "recommended requirements" section for it, 512 is definitely preferable. OOo X11 itself groans at running in 256, and using native windowing instead requires us to do some backing store tricks because some silly person decided that Quartz shouldn't have XOR drawing. The abstract drawing layer of OOo requires that XOR and isn't designed for any platforms that lack it.
ed
Slashdot Mirror
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
/. comments in that thread.
Well, as it turns out my update to the timeline was grossly misquoted in a couple of places. The update was really just to put things in perspective as to what was really going on in the various projects as well as to reinforce the importance of the X11 work. It was never intended to "cancel" anything since, well, there wasn't really anything to cancel. The update was just stating how things really are within the project.
Today's article on eWeek has some much better reporting on the progress towards 2.0 X11 and other issues that had been raised by my update. I highly recommend giving it a read as it's a bit more informative then the old
ed
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
:)
I happily noticed this myself earlier on in the week and was impressed to find the OpenOffice.org related section. Unfortunately there are some inaccuracies in the section, but I couldn't find any address to which corrections should be submitted.
Perhaps the most major omission is that the OpenOffice.org Mac OS X (X11) installer is not limited to 10.3 only. In fact, it supports both 10.2 and 10.3. For 10.2 users it also will automatically install XFree86 and a window manager if the system does not have XFree86 on it. Since Apple X11 is not redistributable under its license, 10.3 users are required ot manually install Apple X11. Ironically, that makes installation on 10.3 more inconvenient then 10.2!
On the trinity forums Smokey also noticed the file format "incompatibility" line in the article. It isn't actually true since OpenOffice.org is 100% compatible with StarOffice which, last I checked, is a commercial office suite even if it doesn't run on Mac OS X
Even with the little foibles, it's great to see support from Apple for X11 applications in general as well as a basic introduction that can help open up the entire world of X11 OSS applications for users, not just OpenOffice.org.
ed
So by this post we have bona fide proof the export filters of Pages are not perfect and, thus, has confirmed the original intent of the thread, that compatibility with Word documents and other formats is troublesome. Amazing...offtopic topic rebuttals are rebutted by their own poster. Astounding.
ed <-- does this mean this whole thread is leaked by System.gc()?
Definitely I'm aware. There's a reason why some slack COO (or whatever title he has now) of Sun wouldn't open source the source code for the old Lighthouse suite of apps (Create and friends, I understand why FrameMaker couldn't be licensed even though I wish it was). And Schwartz is even COO or whatever other title of the week he has. Sun should own the Lighthouse source code from their buyout in the previous age of this world, but that code has just magically disappeared despite a number of folks asking if they could open source that instead of the non-native OOo code.
[tinfoilhat]Sun may very well be the new cloakroom wheeling-and-dealing Satan of our time![/tinfoilhat]
ed
Disclaimer: I'm a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
;)
I've seen this mentioned in a number of places now. I just watched the QuickTime feed of the keynote for the iWork section (starts at about 1hr 3 mins) and heard no mention of spreadsheets or "Cell" in that section. It goes straight from pages to the Mac mini. Did I just miss it?
Also of note: while it appears iLife is going to continue to be bundled with new Macs, it is unclear if iWork is going to be bundled at all. I don't think Keynote is presently bundled with any configs, but they just may not have yet updated the Apple store. It would truly honk for low-end Macs if the death of AppleWorks meant that users had to pay for software. Kinda funny since, after all, they include GraphicConverter but don't bother to preload a FOSS office suite
ed
[quote]Pages' layout features look as if they surpass Word like Keynote surpasses PowerPoint.[/quote]
This does, however, get to the root of the problem of document compatibility which is, in my mind, one of the key requirements of the mixed-platform business environment. While I don't dispute that Pages may be better for documents with those types of layouts, I wouldn't expect that the Word export of those documents will be 100% compatible.
Case in point:
While cool features make for a nice application and probably a more functional one, they don't make for seamless document compatibility. When editing and exchanging documents with the 90%+ of corporations that use and archive their content in Microsoft Office formats, these snafus can prove to be quite a challenge.
ed
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
No, the new iWork is definitely not a replacement for the old AppleWorks/ClarisWorks suite. AppleWorks really did try to do a "kitchen sink" approach as well as give you the flexibilty to embed one type of document in another. I really suspect their decision to focus on word processing is very good from a market driven perspective.
Most people tend to want to be able to write simple letters on their computer. TextEdit could do this, of course, and for simple tasks I do know people who use it. The next class of users is advanced home and entry-level business personnel. Think of the kind of people that want to make a flyer advertising a store event or the people making a newsletter for their little league. These are the exact target audience for Pages.
Pages comes with 40 templates that are customizable in the sense you can add in your own graphics easily to creat new templates (I think...). This makes it easy to create newsletters, corporate letterhead, and the like. The transparency allows for easy watermarking of documents.
Pages will also probably be sufficient for opening most Word documents generated by these similar types of users, home or small business users who have Word pre-installed on their Windows box and use the DOC format to e-mail their newsletters as attachments. In that respect it's great to have a similar pre-installed option available on the Mac that can support that market segment.
Whether they will target spreadsheets and database connectivity in the future is still up for speculation. After all, even Claris killed its own standalone spreadsheet application (Resolve) by selling it off to C&G. For users who want an integrated suite full featured spreadsheets, charting, macros, database connectivity and the like, there's only a few remainingplayers in the Mac market: Microsoft Office, NeoOffice/J (OpenOffice.org, but without the X11), ThinkFree, and Mariner. I don't think Apple's about to compete with Microsoft Office anytime soon as they use Office to help sell the platform. The death of AppleWorks now leaves us open source guys as one of the remaining strongest office suite competitors on the platform.
ed
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project
If Keynote is any indicator, they will most likely not support OpenOffice.org or OASIS formats. There is also no OASIS or XML option in the screenshots of their filter sheet. While it's unclear from the limited info on the website, Pages may save either in RTF or in its own internal format. If it's internal, Apple most likely will open up this file format over time.
When Keynote first came out its file format was "secret" unless you wanted to reverse engineer the XML. A month or two after the software came out they did publish the Keynote schema for their documents. So they are using an open file format for Keynote, even if Keynote is the only application that uses it.
I spec'd a Keynote filter for OOo/NeoOffice a long time ago but no one has taken up the task of implementing or revising that specification. Being able to import Keynote formatted documents just isn't really a commonly requested feature (definitely much less so then Aqua user interface) so I haven't spent my own time on it.
ed
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
Just the fact that you can import and export doesn't exactly mean it's 100% compatible. Heck, even Office v.X/2004 isn't 100% compatible with Windows Office generated files. One of the strengths of OpenOffice.org and NeoOffice is the accuracy of their import and export filters.
I wouldn't suspect Pages would be successful converting Word documents that have embedded Excel spreadsheets and charts those that go trapesing off to do database queries with macros. I suspect Pages would convert them to tatters.
While Pages may be sufficient for doing the basics of letter writing and entry-level document preparation, many of the more complex business level documents still will require Microsoft Office or an equivalent alternative. Office may be bloatware, but that doesn't prevent people from finding a way to use all of those features and then complaining when they don't work in another product. That makes true document compatibility a difficult task that can't fully be addrsesed by a word processing application alone.
ed
FWIW, one of the primary reasons that neither OOo, NeoOffice/J, nor AbiWord have grammar checkers is that no good open source grammar checker tools exist yet. Just about any grammar checker worth its salt is completely closed source. There are some options available, though...
The Link Grammar Parser is one that I've actually been keen on integrating with NeoOffice/J for quite some time. I have ideas on how to do so but have not yet had time to devote to it. I had been waiting for an OSS license for a couple of years for it, but unfortunately I think their new license was incompatible with GPL and can't be used in OOo or NeoOffice/J. Aside from that parser, I don't really know of any other good OSS grammar projects for English, much less all the foreign languages that need to be supported too!
If you have knowledge of any other OSS grammar engines (or contacts for acquiring and freeing source code for a defunct grammar checker like Correct Grammar please contact me!
ed
Although it's not on the main download page yet, we also do have a torrent available for the main installer:
1 .1_Beta.torrent
http://trinity.neooffice.org/torrents/NeoOfficeJ-
There are only a couple of seeders right now, but if the mirrors slow to a crawl the torrent may be a better choice.
ed
Screw that. I'm sick of being a single coder eating ramen and Diet Coke. I'll just take the juicy steak and some insertion.
ed
Unfortunately that file format hasn't been reverse engineered yet. We're not focusing on doing the reverse file format engineering ourselves. We just don't have the resources (two programmers!) to focus on the old Mac file formats, or even the new Mac file formats like Keynote. I wrote some design specs to get developers started if you're curious, but I haven't had the time to do engineering for those features.
The only "old school" Mac app that has had its format engineered is the old Mac WordPerfect, thanks to the OOo WordPerfect filter team. They integrated their code into NeoOffice/J and now we can sort of open the old Novell/Corel WordPerfect 3.5 formatted files. Note this still doesn't give you "show codes", just the files. I think the old MacLink Plus may have had a Word 5.1 to WP translator, though, so that might be a way to get at your legacy docs even if it is convoluted as all hell.
ed
At one point in antiquity, both J and C were prototypes. C was really a hack to explore technologies, but J was engineered a bit more carefully. The idea was eventually that OOo X11 would yield to the short-term solution of J to the long term solution of C.
Unfortunately, Cocoa was just too difficult to fit to the OOo event model. While I hacked and struggled with Cocoa until he smote my ruin upon the mountainside, the Java+Carbon of J the amazing engineering of Patrick and his testing crew was triumphant and created a stable, functional app. When it comes down to it, redoing all that work in Cocoa is just reinventing the wheel for no tangible benefit aside from pure geek thrills. Even if done, the result still wouldn't be using ObjC, Interface Builder, or any of the other tools that make Cocoa so scrumptious. It'd be the penultimate Cocoa hack job. Doing OOo in Cocoa is kind of like trying to ram a square peg into a round hole. Cocoa suffers from the fatal flaw of all framework technologies; they really don't work well for building apps that are not engineered to conform to the framework design.
Frustrated with Cocoa, the decision I came to was to shelve C for a while and go join Patrick and help him bring Aqua into J, stop splitting our efforts, and combine to make a kickass app. Thus the Aqua menus were born with the other widgets to come. Eventually when J is finished, I am hoping to find time to take the "core" parts of J out and wrap them into a framework that can then be embedded into Cocoa apps, similar to the Gecko engine. That's a long way off yet...
For more of my own logic read a more detailed discussion about why J is the best engineering choice for now.
ed
Don't forget that OpenOffice.org itself is huge, and it is a C++ application. It's actually a beautiful example of how horridly slow C++ can get, both running and compiling. NeoOffice/J is just OpenOffice.org with some extensions.
;)
I did a line count analysis a while back in response to some FUD spreading, but it's probably still roughly accurate. On a source code level, less then 2% of NeoOffice/J is actually Java. 98% of the code is straight from OpenOffice.org. And not all of the NeoOffice/J code is in Java, so the actual figure is probably less then that.
On a binary level, the size of the combined JAR files for NeoOffice/J and OpenOffice.org are only 3.7 MB of the application's 317 MB footprint. And those JAR files include the support OOo has for Java applets, DocBook filters, and the like. The "Java" magic NeoOffice/J adds to OpenOffice.org is essentially contained in a single file "vcl.jar", which is 70k. I'm sure someone can do those percentages themselves as I left my RPN calculator at home
ed
We're not a non-profit but we're also not a commercial entity either. We're a group of volunteers who are doing this and hosting the project. For two years we didn't have any type of donate page or the like and just encouraged people to contribute by answering questions in forums, testing, or developing. Funny enough, there are still people who don't want to contribute in those ways. This started a fairly vigorous discussion as to whether we should give those people another vehicle for helping out. You can check out the user community debate back in November as to how things wound up the way they are now and where they will hopefully be going.
;)
:(
To organize as a non-profit in the state of California requires filing paperwork, meeting minimum tax requirements, and other state and federal requirements. We're not expecting to see a lot of monetary donations, so instead of shelling out all that capital to set up a new corporate entity and lose money we don't have (!) we just reused one of the S-corps we already had set up.
We couldn't just take money directly as that opens us up to personal legal liability, a bad thing for us Americans with our predatory legal system. We also can't afford to do it personally due to tax reasons. Right now we're only hoping to get enough to pay for bandwidth and hosting costs. If people actually do start donating enough though we've already decided we'll go through all the hassle of setting up a non-profit entity. It's unfortunately not worth that much hassle for just a few hundred dollars in donations
Still, I'd rather encourage people to donate time, support, and hopefully code instead. It's much more useful then money. Unfortunately time and code are more then most people are able or willing to give
ed
While the link in the story is to the English download pages, the site itself has the download instructions, FAQ, and other pages available in Dutch, French, German, Italian, and Japanese. You can use the language links at the top of the page or link to the language-agnostic download link which will redirect you automatically to the correct language based upon your browser user-info string.
ed
Disclaimer: I am on the OOo Mac OS X team and a founder of NeoOffice. The opinions expressed here are personal and don't reflect official positions of either organization, Apple, Sun, or my employer.
People have definitely been wondering why Apple hasn't supported or started their own engineering work on OOo themselves. In my own opinion, I think the real reason why they haven't is pure politics. For better or for worse, the Apple platform really does need Microsoft Office. Think of how many Apple marketing materials include references to Office. It even makes it into their technical pieces with phrases along the lines of 'I can run my Unix chemical structure modeling software and still use Powerpoint on the same box!'. I also personally have many switcher friends who really require being able to do work in Office on their home machine for business, and probably they would not have been able to switch without it. Office is a crucial piece of software to have available for the viabilty of the platform.
If Apple started very public support for OOo (e.g. by firing off lots of engineering resources at it), it could easily jeopardize the continued development of Microsoft Office for OS X now that there's no agreement in place. Don't forget how quickly Adobe dropping Premiere after FCP was released. There's precedent from Microsoft as well with the release of Safari having been cited as one of the primary motivators for dropping Internet Explorer OS X development (a horrid shame as, yes, there are still a few web sties that require VBScript).
So although there may be many good logical arguments for why there should be support for a project like OOo, or even an enhanced business oriented AppleWorks derivative, there's always that one good motivator for not doing so...the continued existance of Microsoft Office for Mac OS X. Given its current positioning as bullet 8 on their top 10 reasons to switch, I highly doubt that Apple would make any type of moves that would jeopardize Office.
ed
BTW: pyobjc rocks!
It's not that the boxes are slow...the compilers and linkers that we have to use just suck, especially as to maintain 10.2 compatiblity requires using 10.2 dev tools that don't have most of the recent optimizations Apple's been doing in their compilers..
ed
The native theming work was actually pioneered in NeoOffice/C Flaming Yeti back in 2002. Dan, who helped me get the intial widget stuff in, moved on to be one of the primary architects of the Native Widget Framework that does the theming in 2.0.
:)
While NeoOffice/C was way to hacked to make the transition into a maintainable project, NeoOffice/J is actually using portions of that framework for the Aqua menus. We 'backported' 2.0 into 1.1.x to do the most requested native widget (and arguably the most complex) menus. Having it in the official 2.0 sources helps us because it means we won't have to hack to make the infrastructure ourselves
ed
Thanks for the well wishes :) The good thing is that the patches are mostly to sections of code that are moderately stable. Most of the source tarball winds up being the new Carbon and Java code that's replacing the X11 code. As long as we can keep up with changes to the interfaces things will be good. The worst one for Patrick was adding right-to-left and vertical text support, but beyond that I can't imagine any other drastic unanticipated changes to how OOo expects to draw lines ;)
ed
Well, he's not got any plans for 2.0 Mac OS X either and there are certainly no paid engineers working on native OS X support for OpenOffice.org. It's a shame when folks have to start talking smack citing their own vaporware, and this is even free software ;)
As to "do the work all over again", Neo/J isn't engineered that way. It's actually only over a meg tarball in size. It's so small that the source is actually included in the installer dimages. The way it works is that Neo/J first automatically downloads and builds OpenOffice.org X11. After that, it replaces the X11 components with its own. The X11 dependent components are actually quite small when compared to the largesse of OOo.
ed
Read further along for great comments like the disinformation in this which omits our 2.0 plans. There's other ones like this where the project is described as "harmful and destractive" to OpenOffice.org. And this was all in response to a user just saying he enjoyed NeoJ.
If responses like those are not politics and scare tactics, I don't know what is.
(and yes, we do have patches that we've relicensed and submitted that do not get committed back into OOo, such as UTF8 filename support).
ed
Disclaimer: I am a member of the OOo Mac OS X "team" and a founder of the project.
;)
NeoOffice/J isn't a prototype anymore. It got so good and stable that we decided to make it an official project. We just haven't changed the slogans and copy yet. NeoOffice/J 1.1 is going to be going beta this week, based off of OpenOffice.org 1.1.3 (not even available for Mac OS X X11). It will contain Aqua menus, too.
After we work out all the bugs and get NeoOffice/J 1.1 to final release, we're going to plow ahead with scrollbars and buttons and whathaveyou for a 1.5 release. We'll also be starting on the native work for 2.0 sometime next year, but that will take some effort, considering OOo 2.0 isn't finalized yet.
Our goal is to put out a final NeoOffice/J that is stable, well tested, polished, but most importantly, fully functional. It's generally our opinion that it's more important to be bug-free then pretty. It doesn't matter if it's got pretty blue buttons if it crashes after typing 5 words, and there are definitely testers and users who agree
ed
Although there's no "recommended requirements" section for it, 512 is definitely preferable. OOo X11 itself groans at running in 256, and using native windowing instead requires us to do some backing store tricks because some silly person decided that Quartz shouldn't have XOR drawing. The abstract drawing layer of OOo requires that XOR and isn't designed for any platforms that lack it. ed