[dev] Re: [documentation-dev] creating Excel files
Hi Dave, Dave Calkins [EMAIL PROTECTED] schrieb: I'm developing a commercial app which generates large data sets. We have a need to be able to create Excel files containing the data along with charts, images, etc. I was thinking a good option might be to re-use the relevant OpenOffice.org code to do the Excel file format writing and thought I'd check to see if anyone else had taken this approach before and how it worked out. I think this question belongs to dev@openoffice.org, because you'll find there the developers, who are working on the code. I guess, that they might help you better than we can do here. On this list, we're developing the documentation for the endusers. I'm forwarding your email to the above mentioned list, please check it for answers to your question. Thanks :-) Sigrid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [documentation-dev] creating Excel files
Looks like I posted to the wrong area. oops! If anyone can provide any advice wrt creating Excel files using OpenOffice.org, I'd appreciate it. You can see my original post in the below. I'd like to be able to export to an Excel file from my app which will be running in a shop floor environment on a machine which would not have MS Office or Open Office installed. Would it be feasible to re-use the Excel file writing code from OpenOffice? I downloaded the OO SDK and was scanning the developer's guide, however, it seems to be coming from the approach of connecting to a running OO instance as opposed to re-using OO code in your own app (on a machine which wouldn't have OO installed). Thanks :-) Sigrid Kronenberger wrote: Hi Dave, Dave Calkins [EMAIL PROTECTED] schrieb: I'm developing a commercial app which generates large data sets. We have a need to be able to create Excel files containing the data along with charts, images, etc. I was thinking a good option might be to re-use the relevant OpenOffice.org code to do the Excel file format writing and thought I'd check to see if anyone else had taken this approach before and how it worked out. I think this question belongs to dev@openoffice.org, because you'll find there the developers, who are working on the code. I guess, that they might help you better than we can do here. On this list, we're developing the documentation for the endusers. I'm forwarding your email to the above mentioned list, please check it for answers to your question. Thanks :-) Sigrid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Laurent Godard wrote: Hi, saying it's easy is easy ;-), i know that it is possible to extract data and create for example a PDF. But the output isn't comparable to what we have at the moment. Show me a working and satisfying solution and we can discuss it. Juergen, you know such a solution is not yet set up and i think anything won't be done until a decision is made about freeing this document a working solution will probably have influence on the decision. We talk here about a huge project and we don't make a decision based on some gut feeling. Juergen i said easy, well, replace by doable provided we can work on the content and have the I/O specification of the document Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] workspace handling
On Tue, 2006-07-04 at 04:52 +0200, Stefan Taxhet wrote: I'm a little worried about how long it's taking my workspaces to go anywhere Oops, they were still active? I found xalanupgrade and fpicker6 and moved those to the new area. Excellent, thanks for finding them :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Jurgen a working solution will probably have influence on the decision. We talk here about a huge project and we don't make a decision based on some gut feeling. sure !! but you may admit that the problem is a 'cricular reference' :-) Btw, i may find some volunteers setting up a prototype but i may need the desired output format Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingénierie OpenOffice.org Indesko http://www.indesko.com Nuxeo CPS http://www.nuxeo.com - http://www.cps-project.org Livre Programmation OpenOffice.org, Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [SOLVED] Changing the default Java for OOo from command line
Hi Joachim, OK. I used: -%- export UNO_JAVA_JFW_ENV_CLASSPATH=/usr/lib/openoffice/program/classes/j urt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program /classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openo ffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar UNO_JAVA_JFW_ENV_CLASSPATH can be set to true which indicates that CLASSPATH is used. because this does not work I found a workaround. Before installing the UNO package, I correct the /usr/lib/openoffice/share/config/javavendors.xml to following: -%- ?xml version=1.0 encoding=UTF-8? javaSelection xmlns=http://openoffice.org/2004/java/framework/1.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; updated2004-01-30/updated vendorInfos vendor name=Sun Microsystems Inc. minVersion1.5.0/minVersion /vendor /vendorInfos plugins library vendor=Sun Microsystems Inc.sunjavaplugin.so/library /plugins /javaSelection -%- Thus OOo selects automatically the Sun JRE even if the user used another JRE before :-). Joachim, without your hints I would not have found this workaround! Thanks for your time and help. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [SOLVED] Linux: Deploying a UNO Package for all users on PC
Hi Matthias and Steffen, just add --shared-Option as described: must have been blind... I read this often before. Sorry but thanks a lot! Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Dave Calkins wrote: I'd like to be able to export to an Excel file from my app which will be running in a shop floor environment on a machine which would not have MS Office or Open Office installed. Why don't you just install OOo and control it using the API? Would it be feasible to re-use the Excel file writing code from OpenOffice? I downloaded the OO SDK and was scanning the developer's guide, however, it seems to be coming from the approach of connecting to a running OO instance as opposed to re-using OO code in your own app (on a machine which wouldn't have OO installed). If you really want to use parts of our source, there's a bit of an overview of the Excel filter classes at http://sc.openoffice.org/servlets/ProjectDocumentList under Source Code Documentation. It's not completely up to date, but it might help to get started. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] eLæring interaktiv kurs i OpenOffice
Hallo OpenOffice utviklere Vi har utviklet kurs i OpenOffice for skoleverket og for private brukere. Det er allerede tatt i bruk i Stord kommune og vi forsøker nå å få inpass i andre kommuner i Norge. Omdere vil (vi ønsker selvsakt det sterkt ) så må dere gjerne legge linken til disse kursene ut på nettsiden. BOKMAL: http://www.c-m.no/projects/openoffice/bokmal/interface.html NYNORSK: http://www.c-m.no/projects/openoffice/nynorsk/interface.html ENGLISH http://www.c-m.no/projects/openoffice/english/interface.html Vi håper at vi kan samarbeide med dere om det er mulig, ta gjerne kontakt med meg. Vennlig hilsen Håkon Frode Særsten Chiron Media www.c-m.no [EMAIL PROTECTED] 90064375
Re: [dev] [SOLVED] Changing the default Java for OOo from command line
Good to know that it works for you now. By the way I filed issue 66769 to investigate the use of bootstrap variables with unopkg -Joachim Tobias Krais wrote: Hi Joachim, OK. I used: -%- export UNO_JAVA_JFW_ENV_CLASSPATH=/usr/lib/openoffice/program/classes/j urt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program /classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openo ffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar UNO_JAVA_JFW_ENV_CLASSPATH can be set to true which indicates that CLASSPATH is used. because this does not work I found a workaround. Before installing the UNO package, I correct the /usr/lib/openoffice/share/config/javavendors.xml to following: -%- ?xml version=1.0 encoding=UTF-8? javaSelection xmlns=http://openoffice.org/2004/java/framework/1.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; updated2004-01-30/updated vendorInfos vendor name=Sun Microsystems Inc. minVersion1.5.0/minVersion /vendor /vendorInfos plugins library vendor=Sun Microsystems Inc.sunjavaplugin.so/library /plugins /javaSelection -%- Thus OOo selects automatically the Sun JRE even if the user used another JRE before :-). Joachim, without your hints I would not have found this workaround! Thanks for your time and help. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [SOLVED] Changing the default Java for OOo from command line
Hi Joachim, Good to know that it works for you now. By the way I filed issue 66769 to investigate the use of bootstrap variables with unopkg thanks a lot! I voted for it and attached the link to this thread. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Niklas Nebel wrote: Dave Calkins wrote: I'd like to be able to export to an Excel file from my app which will be running in a shop floor environment on a machine which would not have MS Office or Open Office installed. Why don't you just install OOo and control it using the API? I don't have control over the machines on which our app is running, so the only thing I know for sure is that they'll have our app installed. Also, the machines on the shop floor running our app don't have a need for a full office suite, since they're collecting/generating the data and only want to be able to export to Excel for review later on other machines. Having them install OOo would probably be overkill. Of course, there's the option of including the OOo installation within our app's installation, but that would probably really grow the size of our installer. For similar reasons we wanted to avoid the MS Office automation interfaces. Using them would require having the MS Office SW installed on the machine where our app was running and we couldn't ensure that either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. My hope was to be able to only include the code necessary to save the Excel file format. Then our installer doesn't grow very much, we're not asking them to install other software on the machines and/or we're not adding a lot of SW to the machines which isn't needed and wouldn't be used. Would it be feasible to re-use the Excel file writing code from OpenOffice? I downloaded the OO SDK and was scanning the developer's guide, however, it seems to be coming from the approach of connecting to a running OO instance as opposed to re-using OO code in your own app (on a machine which wouldn't have OO installed). If you really want to use parts of our source, there's a bit of an overview of the Excel filter classes at http://sc.openoffice.org/servlets/ProjectDocumentList under Source Code Documentation. It's not completely up to date, but it might help to get started. Thanks, I'll start there and see what I can find. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Dave Calkins schrieb: Niklas Nebel wrote: Dave Calkins wrote: I'd like to be able to export to an Excel file from my app which will be running in a shop floor environment on a machine which would not have MS Office or Open Office installed. Why don't you just install OOo and control it using the API? I don't have control over the machines on which our app is running, so the only thing I know for sure is that they'll have our app installed. Also, the machines on the shop floor running our app don't have a need for a full office suite, since they're collecting/generating the data and only want to be able to export to Excel for review later on other machines. Having them install OOo would probably be overkill. Of course, there's the option of including the OOo installation within our app's installation, but that would probably really grow the size of our installer. For similar reasons we wanted to avoid the MS Office automation interfaces. Using them would require having the MS Office SW installed on the machine where our app was running and we couldn't ensure that either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Tom Schindl wrote: either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Thanks for the pointer. I'll definitely take a look at that as well. The downside there is that its Java and we're using C++, so we'd need to do JNI or run a VM process and use RMI or something. Then that also requires including the Java runtime with our installer. Anyway, worth looking into and keeping on the list of possibilities. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] workspace handling
Martin, Could you shed some light on this? What's the current policy for nominating / holding back childworkspaces? In 'releases' you announced a 'code freeze' date, but that's not reached yet. http://wiki.services.openoffice.org/wiki/OOoRelease204 Rüdiger Jens-Heiner Rechtien wrote: Hi Caolan, you are not alone with this, check for instance encupfix01, soldep1, perftest03, hr33 and a few others. QA was very busy with OOo-2.0.3, so I think that's understandable. As for the approved but not yet nominated CWSs, that's mostly due to warnings01 which just due to sheer size hold up everything for a few weeks. BTW, it helps if you prod MH a bit if a CWSs is approved but not nominated :-) Heiner Caolan McNamara wrote: I'm a little worried about how long it's taking my workspaces to go anywhere, and I'm wondering if this is normal both for external and internal workspaces, i.e. today is Jul 3 and I've 4 unintegrated workspaces which are out my hands. xalanupgrade ready for qa since May 5 = 59 days unchanged fpicker6 ready for qa since May 24 = 40 days unchanged targetedaot approved since Jun 12 = 21 days unchanged bfsixtyfour approved since Jun 15 = 18 days unchanged And interestingly, since some of those workspaces were created, I've just realized that according to http://ooomisc.services.openoffice.org/pub/OpenOffice.org/cws/upload/readme.txt the cws upload site has moved, and the original installsets for some of these workspaces have apparently disappeared in the meanwhile :-( C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Do you really need to get xls why not PDF? Do people have to change things afterwards? Tom Dave Calkins schrieb: Tom Schindl wrote: either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Thanks for the pointer. I'll definitely take a look at that as well. The downside there is that its Java and we're using C++, so we'd need to do JNI or run a VM process and use RMI or something. Then that also requires including the Java runtime with our installer. Anyway, worth looking into and keeping on the list of possibilities. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[dev] Suggestion to simplify OpenOffice_Dev installations
Hi all, I would like to suggest some modifications for the OpenOffice_Dev installations sets. As far as I know the OpenOffice_Dev target was introduced to create Builds that can be installed in parallel to a normal OpenOffice version for testing and developing purposes. But there are still some limitations: 1) You only can have one OpenOffice_Dev installation at a time, so if you want to check another developer snapshot you will need to deinstall (or upgrade) the previous one. 2) The different installations may conflict in the user installation directory as this is shared. So you might get strange bugs. 3) For linux and solaris you need some additional scripts to get the thing installed. I would like to suggest to get rid of these problems of the OpenOffice_Dev Installtions completely: 1) Do not do any system registration at all 2) Don't share the user installation with any other installed OpenOffice version (change path in bootstrap.ini to: UserInstallation=$ORIGIN/../UserInstallation) 3) Make it possible to just unzip and start the Office without installation procedure at all. And be able to get rid of this version completely just by deleting the directory. Of course some features are then not testable within the developer snapshots (installer,systemintegration,update of user installation directory) but the mass of other features could be checked much easier I think. Are there any concerns here? Are there any features that depend on system registration or native installer, that absolutely need to be testable in each developer snapshot? Thanks, Ingrid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
On Tue, 2006-07-04 at 18:20 +0200, Tom Schindl wrote: Do you really need to get xls why not PDF? Do people have to change things afterwards? Tom Dave Calkins schrieb: Tom Schindl wrote: either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Thanks for the pointer. I'll definitely take a look at that as well. The downside there is that its Java and we're using C++, so we'd need to do JNI or run a VM process and use RMI or something. Then that also requires including the Java runtime with our installer. Anyway, worth looking into and keeping on the list of possibilities. Dave If I were doing this, to avoid trying to produce a binary file in a format that is not documented outside of Redmond, I would try producing a file using the new Office XML format. That might be easier, too. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Suggestion to simplify OpenOffice_Dev installations
Hi Ingrid, *, On Tue, Jul 04, 2006 at 07:55:04PM +0200, Ingrid Halama wrote: [...] But there are still some limitations: 1) You only can have one OpenOffice_Dev installation at a time, so if you want to check another developer snapshot you will need to deinstall (or upgrade) the previous one. You could use the --prefix option to install it into a different diretcory, along with another dev-build. 2) The different installations may conflict in the user installation directory as this is shared. So you might get strange bugs. the dev-builds have a different user-installation than the stable one. If you get bugs, then great! Better find those in a developer build than in the stable version. If you want different directories for each dev-build, you need to modify bootstraprc. 3) For linux and solaris you need some additional scripts to get the thing installed. The scripts are just meant to ease the task, they are not necessary. You can as well simply do a for i in *.rpm ; do rpm2cpio $i | cpio -idmv ; done and then move the directory where you would like it. Or you can use the --prefix option to install into a different directory, without the need to remove the older version. I would like to suggest to get rid of these problems of the OpenOffice_Dev Installtions completely: 1) Do not do any system registration at all If you don't install one of the desktop-integration packages, then OOo won't do any system-stuff - everything is in the one single directory. 2) Don't share the user installation with any other installed OpenOffice version (change path in bootstrap.ini to: UserInstallation=$ORIGIN/../UserInstallation) And how would you then find the bugs in the configuration data? 3) Make it possible to just unzip and start the Office without installation procedure at all. And be able to get rid of this version completely just by deleting the directory. see above. (rpm2cpio) [...] ciao Christian -- NP: Paradise Lost - Joys Of The Emptiness - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Yes, our users definitely want the Excel generation. Now that you mention it, I wouldn't be surprised if PDF generation was in the future as well, but we definitely need to generate Excel as an option. My guess is that the file is generated and then further down the pipeline on a different machine someone will be doing edits to the file. Tom Schindl wrote: Do you really need to get xls why not PDF? Do people have to change things afterwards? Tom Dave Calkins schrieb: Tom Schindl wrote: either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Thanks for the pointer. I'll definitely take a look at that as well. The downside there is that its Java and we're using C++, so we'd need to do JNI or run a VM process and use RMI or something. Then that also requires including the Java runtime with our installer. Anyway, worth looking into and keeping on the list of possibilities. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Matt Needles wrote: On Tue, 2006-07-04 at 18:20 +0200, Tom Schindl wrote: Do you really need to get xls why not PDF? Do people have to change things afterwards? Tom Dave Calkins schrieb: Tom Schindl wrote: either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Thanks for the pointer. I'll definitely take a look at that as well. The downside there is that its Java and we're using C++, so we'd need to do JNI or run a VM process and use RMI or something. Then that also requires including the Java runtime with our installer. Anyway, worth looking into and keeping on the list of possibilities. Dave If I were doing this, to avoid trying to produce a binary file in a format that is not documented outside of Redmond, I would try producing a file using the new Office XML format. That might be easier, too. I didn't think the new format opened in older versions of office. I don't think we want to require our customers to have Office 2007. Does OOo support the new format? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Tom Schindl wrote: Dave Calkins schrieb: Niklas Nebel wrote: Dave Calkins wrote: I'd like to be able to export to an Excel file from my app which will be running in a shop floor environment on a machine which would not have MS Office or Open Office installed. Why don't you just install OOo and control it using the API? I don't have control over the machines on which our app is running, so the only thing I know for sure is that they'll have our app installed. Also, the machines on the shop floor running our app don't have a need for a full office suite, since they're collecting/generating the data and only want to be able to export to Excel for review later on other machines. Having them install OOo would probably be overkill. Of course, there's the option of including the OOo installation within our app's installation, but that would probably really grow the size of our installer. For similar reasons we wanted to avoid the MS Office automation interfaces. Using them would require having the MS Office SW installed on the machine where our app was running and we couldn't ensure that either. Which is why we're looking for something to let us directly write the binary file format and OOo seemed liked a good possibility. Did you thought about jakarta-POI? Another alternative is jExcelApi. I have recently tried compiling it with gcj and found that it works well, so you can still use native code rather than installing Java. I haven't tried the same with jakarta-POI David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
