Re: [dev] Re: [documentation-dev] creating Excel files
2006/7/5, Matt Needles [EMAIL PROTECTED]: On Tue, 2006-07-04 at 15:16 -0400, Dave Calkins wrote: 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? That format was introduced with Office 2003. OOo 2.x supports it. Do we have a license problem here? I browsed this story: http://www.eweek.com/article2/0,1759,1829355,00.asp And this: http://www.zdnet.com/5208-11048-0.html?forumID=1threadID=14384messageID=288763start=0 (I googled Office XML license) Is OOo really allowed to implement Microsoft's XML? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [documentation-dev] creating Excel files
Henrik Sundberg wrote: 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? That format was introduced with Office 2003. OOo 2.x supports it. Do we have a license problem here? I browsed this story: http://www.eweek.com/article2/0,1759,1829355,00.asp And this: http://www.zdnet.com/5208-11048-0.html?forumID=1threadID=14384messageID=288763start=0 (I googled Office XML license) Is OOo really allowed to implement Microsoft's XML? I'm no expert and am new to OOo, but since I'm already in the thread my impression was that the only requirement with using the MS format was noting that you did so. Seems pretty relaxed. I can't see anything in the LGPL license which would prevent giving credit to the file format being used. Dave - 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 15:16 -0400, Dave Calkins wrote: 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] That format was introduced with Office 2003. OOo 2.x supports it. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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] 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]
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] 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
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] 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]
