[dev] ODT file created through XSL transformation is corrupt
Hello I have developed a Java application that holds data in XML and prints this data into an OpenOffice.odt file using XSL transformation. Unfortunately, when I open the created file, the message The file 'xyz.odt' is corrupt and therefore cannot be opened. Should OpenOffice.org repair the file? pops up. If I choose repair, the document is displayed exactely as expected. If I unzip the created file, I don't see anything that could be corrupt. The astonishing thing is that I can unzip the created file and Zip it again and now, the document is displayed in the OpenOffice writer WITHOUT corruption message. When I compare both files, the allegedly corrupt one and the one after the unzip-zip procedure, I see that the content of both files looks exactly the same, e.g.: Nametypesizeratio path content.xml XML 9'69075% meta.xml XML915 61% mimetype File39 0% styles.xmlXML 19'711 88% manifest.xmlXML 1'88683%meta-inf\ However, if I compare the size of both files, I notice that the allegedly corrupt file has as size of 6'160 bytes whereas the file that opens without problems has a size of 6'215 bytes (difference of 55 bytes). (The disk size of both files is the same, 8'192 bytes). Does anybody has a hint what could be corrupt with the file created with XSLT? Is there a log file that I can consult to learn more about what exactely is corrupt with the file? Is there a mailing list better suited for this problem? I have OpenOffice.org 2.0.2 installed on Windows XP. The transformer I've created is based on the book OASIS OpenDocument Essentials by J.D.Eisenberg. Regards, Benno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ODT file created through XSL transformation is corrupt
Hi Benno, Luthiger Stoll Benno wrote: Hello I have developed a Java application that holds data in XML and prints this data into an OpenOffice.odt file using XSL transformation. Unfortunately, when I open the created file, the message The file 'xyz.odt' is corrupt and therefore cannot be opened. Should OpenOffice.org repair the file? pops up. If I choose repair, the document is displayed exactely as expected. If I unzip the created file, I don't see anything that could be corrupt. The astonishing thing is that I can unzip the created file and Zip it again and now, the document is displayed in the OpenOffice writer WITHOUT corruption message. When I compare both files, the allegedly corrupt one and the one after the unzip-zip procedure, I see that the content of both files looks exactly the same, e.g.: Nametypesizeratio path content.xml XML 9'69075% meta.xml XML915 61% mimetype File39 0% styles.xmlXML 19'711 88% manifest.xmlXML 1'88683%meta-inf\ However, if I compare the size of both files, I notice that the allegedly corrupt file has as size of 6'160 bytes whereas the file that opens without problems has a size of 6'215 bytes (difference of 55 bytes). (The disk size of both files is the same, 8'192 bytes). Does anybody has a hint what could be corrupt with the file created with XSLT? Is there a log file that I can consult to learn more about what exactely is corrupt with the file? Is there a mailing list better suited for this problem? Probably the [EMAIL PROTECTED] mailing list. But i assume that it is not a problem of the XSLT but from the zip tooling you are using. Juergen I have OpenOffice.org 2.0.2 installed on Windows XP. The transformer I've created is based on the book OASIS OpenDocument Essentials by J.D.Eisenberg. Regards, Benno - 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] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
Hi Matthias, So here the rule if everything is important nothing is important applies. Right! In result the project members must decide by themselves. Without any data backing up that 2 man years development time for improved automation support (plus QA etc.) will please more users than those who can become pleased by what we can do instead of this (improving usability, filters, performance etc.) I don't see it happen. That is really the point: how to assess what is (really) important for what purpose. Current users of OOo have a high interest in the latter, i.e., constantly improving the current OOo, filling felt gaps here and there; like Base now getting a great reporting facility (which is very important, needless to say). Of course macro recording would improve the usability for current OOo users as well, helping them automate their tasks (business process steps). However, my main-focus would be about unlocking MSO power end-users, who use macro recording (and then have someone else alter the generated code to suite more their particular needs, or quite a few times being able to edit the recorded code themselves in little corners and edges), which would be an ongoing and strategic goal. Of course there are many, interesting, worthwhile RFEs out there, which should (all) be implemented. However, that fact should not lead to the wrong conclusion that macro recording was not that important at all. Sorry, that wasn't the impression I wanted to create. This is true only in the meaning I wrote: if everything is important ... If we saw it as totally unimportant we wouldn't have tried it at all. Yes, I thought so (really!), but at the moment it seems to be the case that it is put on the back-burner, short of viable trails to achieve full macro recording with the scarce resources at hand. Both are independent, important development routes. Macro recording in this context is of strategic importance. In the past OOo/SO developers have appreciated that and implemented it (even if it was done in a way that today does not appear to be appropriate). IMHO the Dispatch API approach is a good one in case we wanted to target only the automaters and in fact this was our intention. Perhaps we should have created binary macros only, without showing any source code. In fact that was my proposal but that wasn't well received at that time. That would have explained much better that we never wanted to provide that real macro recorder that we think we can't deliver in a reasonable amount of time. Either one would be great, a binary solution, if well-thought out upfront would allow to write later programs that should be able to create source code from the binary representation in any of the languages that support interaction with OOo (i.e. while crafting the binary specs, also information should be recorded for the purpose to allow transcriptions later). (Speculation, of course!) It looks to me that at one point in time it was common knowledge among the developers that the macro recording should be done to allow replaying it via the dispatch interface was not optimal and should be eventually replaced. Not really, as I wrote, the original intention indeed was to create an automation tool, not a developing macros teacher. Yes, the automation tool would be paramount. However, thinking about allowing the recorded macro to be transcribed to a macro language later should not be ruled out, as it would allow for many applications of it (as can be seen with power end-users in the MSO world). This transcribing would probably be possible to members of the community, whereas the macro recording funcitonality itself is something which probably only the core developers would be able to master efficiently and completely. (snip) I'm afraid that reading and understanding your thoughts will require some time. But a first glance showed me that you think about intercepting calls (urp). As this will require UNO calls that could be bridged I'm not sure if I made myself clear enough. So before I dig into your ideas deeper (and I will really try to) please answer these question: Do you agree that my explanation on the wiki page made clear that whatever we do we can't build upon UNO and UNO APIs as this would require a complete rewrite of our glue code that currently does not use any UNO runtime or UNO API calls? In a 3-tear-model that would be the middle or basic interface level (BIL) or however you want to call it. Yes. (But again, I am not aware of the inner workings and architecture put in place, and have no knowledge about what would be still conceivable and what would not be conceivable at all.) So what we have is the level of pure C++ function calls. IMHO there is nothing you can record and play, you always need an object model to work on and that's UNO. But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code
Re: [dev] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
Rony G. Flatscher wrote: But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code would not be invocable via UNO? Of course: this is the Dispatch API! The UI elements use die Dispatch API to call a method in a UNO object implementing com.sun.star.frame.XDispatch. This is the only UNO based call involved. The implementation of this object only uses pure C++ calls inside, nothing based on UNO APIs, neither in-process nor remote (urp). But we are talking about recording the other API that an experienced OOo API developer would use to perform the same task. And this API would be a completely different one. If I have some time I will try to put some code snippets into the wiki that should demonstrate this. A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. The reverse mapping that we can do is what the current macro recorder does: all received dispatch() calls are recorded. Ceterum censeo, macro recording ... :) ... esse delendam? ;-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] ODT file created through XSL transformation is corrupt
Hi Juergen Does anybody has a hint what could be corrupt with the file created with XSLT? Is there a log file that I can consult to learn more about what exactely is corrupt with the file? Is there a mailing list better suited for this problem? Probably the [EMAIL PROTECTED] mailing list. But i assume that it is not a problem of the XSLT but from the zip tooling you are using. Hm, I guess you're right, but as far as I see I only use standard components. I'm using the classes in java.util.jar (java version 1.5.0_09) to create the entries in the Zip file and to produce the zipped filed. Are there examples of Java applications creating odt files using XSLT (besides of OASIS OpenDocument Essentials by J.D.Eisenberg)? Regards, Benno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
Mathias Bauer wrote: Rony G. Flatscher wrote: But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code would not be invocable via UNO? Of course: this is the Dispatch API! The UI elements use die Dispatch API to call a method in a UNO object implementing com.sun.star.frame.XDispatch. This is the only UNO based call involved. The implementation of this object only uses pure C++ calls inside, nothing based on UNO APIs, neither in-process nor remote (urp). But then, wouldn't this also mean that this Dispatch API is excercised by all OOo modules then, including Draw/Impress, or is it the case that for using that API some of the module-dependent (C++ implemented) UI elements still need to be programmed accordingly? But we are talking about recording the other API that an experienced OOo API developer would use to perform the same task. And this API would be a completely different one. Right. If I have some time I will try to put some code snippets into the wiki that should demonstrate this. Would be very interesting in any case, but your points seem to be already very clear. A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. The reverse mapping that we can do is what the current macro recorder does: all received dispatch() calls are recorded. Hmm, would it be conceivable then to come up with a static table of dispatchable user-actions with a sequence of UNO API invocations that would be needed to be excercised such that for recording purposes this list could be used in addition, recording the values of arguments and results and so on. Or with other words, for every dispatch have an independent, alternitve thread of creating UNO pseudo-code necessary to arrive at the same functionality, stating pre- (which UNO objects, methods, argument values) and post-conditions. Maybe even including branch statements, or with other words, small (commented) pseudo-code segments that could be used to map to a concrete language later on. Either being editable to correct or supply addtional code/information. Even if it is not perfect and may contain omissions or incomplete information it may generate UNO based code that needs a little bit of massaging, it would be so much more and a starting point that really may drive up productivity. (Obviously looking for a Pareto solution, i.e. 20% effort for covering 80% of the needed functionality, leaving the missing 20% to the UNO/OOo savvy programmers.) Power end-users would be able to create that skeleton then rather easily, needing UNO/OOo acquainted programmers to turn it to a running macro. Ceterum censeo, macro recording ... :) ... esse delendam? ;-) ... esse implementam ! :-P Regards, ---rony
Re: [dev] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
Rony G. Flatscher wrote: Mathias Bauer wrote: Rony G. Flatscher wrote: But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code would not be invocable via UNO? Of course: this is the Dispatch API! The UI elements use die Dispatch API to call a method in a UNO object implementing com.sun.star.frame.XDispatch. This is the only UNO based call involved. The implementation of this object only uses pure C++ calls inside, nothing based on UNO APIs, neither in-process nor remote (urp). But then, wouldn't this also mean that this Dispatch API is excercised by all OOo modules then, including Draw/Impress, or is it the case that for using that API some of the module-dependent (C++ implemented) UI elements still need to be programmed accordingly? The Dispatch API is the same in all modules - but this is a generic API and the real action lies in the command names and paramters. All objects have the same interface to receive commands but they differ in the commands they support and - in case of Draw/Impress - also in the degree of how good their implementation actually is. In Draw/Impress parameters are mostly not supported at all and they are essential for playing recorded macros. That's enough for calling the Dispatch API from the GUI (where usually no parameters are sent) but is a killer for playing macros using the API. Besides that: this is only the playing side, in Draw/Impress the recording side even looks worse (remember the rule set for recorder support I posted earlier). A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. The reverse mapping that we can do is what the current macro recorder does: all received dispatch() calls are recorded. Hmm, would it be conceivable then to come up with a static table of dispatchable user-actions with a sequence of UNO API invocations that would be needed to be excercised such that for recording purposes this list could be used in addition, recording the values of arguments and results and so on. Or with other words, for every dispatch have an independent, alternitve thread of creating UNO pseudo-code necessary to arrive at the same functionality, stating pre- (which UNO objects, methods, argument values) and post-conditions. Maybe even including branch statements, or with other words, small (commented) pseudo-code segments that could be used to map to a concrete language later on. Either being editable to correct or supply addtional code/information. You have described reimplement the glue code with other words. Yes, of course you can reimplement each and every dispatch call by using UNO API calls. You can do this in the glue code itself (thus replacing it) and record these calls or you can have a parallel implementation somewhere else as you described or Paolo Mantovani already did for some Calc dispatches. But it's a reimplementation in all cases! The difference only is that in your case the original code is not replaced but its effect on the document is achieved differently. This has an advantage (no regression risk as the original code is preserved) as well as a disadvantage (OOo's size will grow considerably). And it's time consuming in every case. Even if it is not perfect and may contain omissions or incomplete information it may generate UNO based code that needs a little bit of massaging, it would be so much more and a starting point that really may drive up productivity. (Obviously looking for a Pareto solution, i.e. 20% effort for covering 80% of the needed functionality, leaving the missing 20% to the UNO/OOo savvy programmers.) Power end-users would be able to create that skeleton then rather easily, needing UNO/OOo acquainted programmers to turn it to a running macro. Now we are at the point where we started: writing down the correct set of UNO API calls for each dispatch call will first force us to deliver the missing APIs and types and then will take years to implement the calls. We have thousands(!) of dispatch calls to implement. Some of them also depend on internal states. The command .uno:Delete e.g. must be implemented completely different depending on what is selected. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ODT file created through XSL transformation is corrupt
Luthiger Stoll Benno wrote: Hello I have developed a Java application that holds data in XML and prints this data into an OpenOffice.odt file using XSL transformation. Unfortunately, when I open the created file, the message The file 'xyz.odt' is corrupt and therefore cannot be opened. Should OpenOffice.org repair the file? pops up. If I choose repair, the document is displayed exactely as expected. If I unzip the created file, I don't see anything that could be corrupt. The astonishing thing is that I can unzip the created file and Zip it again and now, the document is displayed in the OpenOffice writer WITHOUT corruption message. When I compare both files, the allegedly corrupt one and the one after the unzip-zip procedure, I see that the content of both files looks exactly the same, e.g.: Nametypesizeratio path content.xml XML 9'69075% meta.xml XML915 61% mimetype File 39 0% styles.xmlXML 19'711 88% manifest.xmlXML 1'88683%meta-inf\ First I miss the mimetype stream. OOo will always complain if it can't detect the mimetype. I'm not sure if it insists on the stream but IIRC this is only the first try. There should be a fallback to what is written in the manifest.xml. Perhaps you can post it here (the one of your generated file). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
