Posted: Wed Feb 06, 2008 7:53 pm Post subject: Adding OpenOffice.org performance to NeoOffice
Now that Sun's engineers are only 90 days away from their OOo 3.0 Beta release, I have started wondering if there are any Mac-specific code that Sun has developed that Ed and I might be able to easily backport into NeoOffice before our NeoOffice 3.0 EAP later this year.
I have not done any performance comparison yet, but I have downloaded one of Maho's recent OOo Aqua builds that he posts to the OOo Mac porting list every week or so and I am curious if anyone has found some operations or document types in the latest builds where OOo Aqua clearly is faster than NeoOffice.
If you have, please share the specific cases that you find are faster in OOo Aqua and Ed and I will take a look to see if there is something there that we can backport now. The worst that can happen is that we cannot easily backport it and we will have to wait until this summer's NeoOffice 3.0 EAP.
Now that a new OOo Aqua build is available, I thought it would be a good idea to bump this thread as I am still interested in identifying any obvious performance gains that we can incorporate from the OOo code.
The latest OOo Aqua build is available from the following URL:
Is there an overview for the different Milestones?
I have not found any on their site. All that I know is for the milestone in my link, they purposely put that particular build out for testing by listing it on version tracker. Other than that I suspect that most changes between each weekly milestone is mostly general OpenOffice.org changes.
mat wrote:
And btw: What are your plans for NeoOffice 3.0? how will it be diffent from OOo 3.0?
I won't list small differences as it is unfair of me to compare feature sets against two unreleased products, but what I can say is that NeoOffice 3.0 will have a few very big differences:
1. Stability and performance - The OpenOffice.org native code is new and has been used in day-to-day use by very few people. For software, this usually means that there is the risk of many undiscovered bugs or performance bottlenecks. Our code has been used in day-to-day use by hundreds of thousands of users for several years now so nearly all of the crashing, hanging, and really slow operations have been found and fixed. For this reason, NeoOffice 3.0 and likely any successive releases will use our existing code as we have already put a huge investment of time to make it work as smoothly and reliably as it does today.
2. Support - It is true that implementing the Aqua code in OpenOffice.org is hard and takes a lot of time. But that is, in my experience, actually the easiest part of the process. The harder process, and one that I think we do very well at, is user support. By allocating a substantial amount of our time to direct user support and bug fixing, we are able to fix severe bugs in most cases in the same day and put the fix in a test patch so that users can have access to the fix immediately. Maybe OpenOffice.org will change their support model, but so far that level of support response is not available from OpenOffice.org unless you build the code yourself.
3. Mac OS X features - The list is too lengthy to list here, but NeoOffice has made many changes to the OpenOffice.org code to implement features that only work on Mac OS X. OpenOffice.org 3.0 promises to implement some that we have already had in production such as native spellchecking and QuickTime video support. However, at this time it appears that many of our existing features such as menus available when no documents are open, import images from scanners and cameras, grammar checking on Leopard, etc. will not be available in OpenOffice.org 3.0.
4. Non-Sun OpenOffice.org enhancements - OpenOffice.org 3.0 will only support importing of MS Office 2007/2008 files whereas NeoOffice 2.2.3 already supports both import and export. In addition, we will continue to include other open source code that adds significant improvements to OpenOffice.org such as the ooo-build project and the odf-converter project.
Patrick
Last edited by pluby on Sat Mar 29, 2008 10:48 am; edited 1 time in total
maybe you should mention this on the homepage when OOo 3 is closer to release.
(From an End-User point of view this is not so clear, since most see Neo as OOo with an Aqua interface and nothing more)
btw: I've just tried the Beta/Alpha from OOo3 and the .docx importer in Neo is better than the one in OOo3.
Edit:
Quote:
4. Non-Sun OpenOffice.org enhancements - OpenOffice.org 3.0 will only support importing of MS Office 2007/2008 files whereas NeoOffice 3.0 will support both import and export. In addition, we will continue to include other open source code that adds significant improvements to OpenOffice.org such as the ooo-build project and the odf-converter project.
You did include code from odf-converter?
From their page, it looks like a .net application.
how did you include this in Neo?
The reason for my asking is, that I'm looking for a simple Batch convert from .docx to .odt, and a simple command line tool (that works on a Mac) would be the best.
for more on the mono project. You can also pull our anoncvs sources and do a "make build.odf-converter_patches" to do a checkout and an odf-converter build with our fixes for the hangs in the various XSLTs.
You did include code from odf-converter?
From their page, it looks like a .net application.
how did you include this in Neo?
The reason for my asking is, that I'm looking for a simple Batch convert from .docx to .odt, and a simple command line tool (that works on a Mac) would be the best.
odf-converter is written in the C# language so we used Novell's open source Mono C# interpreter and, using the Mono compiler, compile the odf-converter code into the following command line executable:
/Applications/NeoOffice.app/Contents/OdfConverter
Then, NeoOffice uses code written by the ooo-build project to execute this command to convert between OpenOffice.org's ODF format and Microsoft's OpenXML format.
More info about this command line tool is available here.
You can execute the command directly, but be aware that if you copy it outside of the above location, you will need to also copy various *.dylib files as well.
I tried out the current OOo 3.0 build on PowerPC earlier this week. It has a bit to go on the printing front. The first page of a 3-page document included parts of the tool bar areas on the printed page, although the subsequent pages printed correctly.
Curiously, it appears to tie up the system while it prepares all pages for printing before presenting the native print dialog where you can select a print range... Imagine having a 100 page document but only wanting to print a single page from the document. I haven't looked for their bug report system etc.
Actually, I'm not at all sure that I have the energy (nor my employers support) to spend additional time on supporting OOo alongside NeoOffice. I wonder how many other seasoned NeoOffice supporters may feel the same way? I do hope that the OOo development team are closely following your developments so that users are not obliged to participate in re-inventing the cycle of bug identification and bug fixing that we've already passed. _________________ Ray Saunders
World Scout Bureau
Actually, I'm not at all sure that I have the energy (nor my employers support) to spend additional time on supporting OOo alongside NeoOffice. I wonder how many other seasoned NeoOffice supporters may feel the same way? I do hope that the OOo development team are closely following your developments so that users are not obliged to participate in re-inventing the cycle of bug identification and bug fixing that we've already passed.
I agree. There is a wealth of information in Bugzilla particularly in the current OOo Aqua problem areas of printing, text layout, and font handling. These three areas took a lot of effort to get through particularly when non-European languages are in a document so I hope that Sun Microsystem's engineers are looking at our bug reporting system and seeing if they encounter those difficult bugs that we fixed long ago.
I can definitely assure them that there is no GPL materials in Bugzilla. There are descriptions of bugs and sample documents and/or steps to reproduce the bug, but none of NeoOffice's GPL code is ever posted in Bugzilla so there should be no risk to OOo getting GPL contamination by looking at our past bugs.
odf-converter is written in the C# language so we used Novell's open source Mono C# interpreter and, using the Mono compiler, compile the odf-converter code into the following command line executable:
/Applications/NeoOffice.app/Contents/OdfConverter
Then, NeoOffice uses code written by the ooo-build project to execute this command to convert between OpenOffice.org's ODF format and Microsoft's OpenXML format.
More info about this command line tool is available here.
You can execute the command directly, but be aware that if you copy it outside of the above location, you will need to also copy various *.dylib files as well.
Patrick
Actually, I was considering compiling the converter myself with Mono, but my last experience with Mono wasnt that great, so I didnt try it.
thanks for including this in neooffice!
just one question: which version of OdfConverter did you include? 1.1 (which was released this month)?
Update: I've just tried calling it directly, and it constantly fails. Opening the file in NeoOffice works fine, so I guess, I've done it wrong...
at (wrapper managed-to-native) CleverAge.OdfConverter.OdfZipUtils.ZipLib.unzClose (intptr) <0x00004>
at (wrapper managed-to-native) CleverAge.OdfConverter.OdfZipUtils.ZipLib.unzClose (intptr) <0xffffffff>
at CleverAge.OdfConverter.OdfZipUtils.ZlibZipReader.Close () <0x0001e>
at CleverAge.OdfConverter.OdfConverterLib.ZipResolver.Dispose (bool) <0x00025>
at CleverAge.OdfConverter.OdfConverterLib.ZipResolver.Dispose () <0x00012>
at CleverAge.OdfConverter.OdfConverterLib.AbstractConverter._Transform (string,string) <0x00283>
at CleverAge.OdfConverter.OdfConverterLib.AbstractConverter.Transform (string,string) <0x00085>
at CleverAge.OdfConverter.CommandLineTool.OdfConverter.ConvertFile (string,string,CleverAge.OdfConverter.CommandLineTool.Direction) <0x0015f>
at CleverAge.OdfConverter.CommandLineTool.OdfConverter.ProceedSingleFile (string,string,CleverAge.OdfConverter.CommandLineTool.Direction) <0x00067>
at CleverAge.OdfConverter.CommandLineTool.OdfConverter.Proceed () <0x000cf>
at CleverAge.OdfConverter.CommandLineTool.OdfConverter.Main (string[]) <0x00130>
at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff>
Abort trap
We are using odf-converter release 1.1 plus a few patches for non-Windows platforms.
If the file opens in NeoOffice, there are probably a few environment variables that need to be set. Here is the list that NeoOffice sets before invoking OdfConverter. You will probably need to do the same in your Terminal shell:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
