Re: [dev] openoffice eclipse plugin
Hi Georges, Le lundi 21 septembre 2009 à 16:00 -0500, George Foster a écrit : When I create a new project and attempt to point the sdk path to the correct directory I get an error saying: SDK version has to be at least 2.0.4. Is this a bug with the plugin? if not should I create one and if so is it planning on getting resolved. This is normally resolved in the dev update site, as I still haven't published a new release with the changes. Could you precise which update site you are using? -- Cédric Bosdonnat OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] devel packages
On 09/22/09 07:19, tora - Takamichi Akiyama wrote: Linux distributions come with additional packages for software engineers. A package 'kernel' is the one for runtime while '-devel' and '-headers' are for engineers and/or users to make small changes to the existing files. E.g. kernel-2.6.23.1-42.fc8 kernel-devel-2.6.23.1-42.fc8 kernel-headers-2.6.23.1-42.fc8 Likewise how about having such auxiliary packages for the OpenOfffice.org? E.g. ooobasis3.1-core04-3.1.0-9399.i586.rpm ooobasis3.1-core04-devel-3.1.0-9399.i586.rpm The files from the 'devel' package would be installed into /opt/openoffice.org/basis3.0/include/ and/or some relevant locations. IMO a package X-devel only makes sense if the base package X contains something that has an API for clients, and those clients typically need some additional files to interact with X through that API (C headers, link libraries, etc.). The only parts of OOo that would qualify here are the URE and the OOo UNO API. For the latter, there is already the SDK---which also covers support for the former. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Improving HTML-output after import from MS-Word
larrydlefever wrote: per http://svn.services.openoffice.org/opengrok/xref/DEV300_m59/sw/source/filter/html/htmlatr.cxx#1013 there seem to be certain rules regarding when a P tag is output when using Save as ... in Writer (I tried to translate the German here into English -- I need help with that, incidentally): Ein P wird nur geschrieben, wenn - wir in keiner OL/UL/DL sind, oder - der Absatz einer OL/UL nicht numeriert ist, oder - keine Styles exportiert werden und - ein unterer Abstand oder - eine Absatz-Ausrichtung existiert, ode - Styles exportiert werden und, - die Textkoerper-Vorlage geaendert wurde, oder - ein Benutzer-Format exportiert wird, oder - Absatz-Attribute existieren A P is written only if: - we're not in a list of any kind; or - the paragraph we're in is in an unordered list; or - no Styles are being exported and a (lower distance?) exists or a paragraph-adjustment exists; or - Styles are being exported and the text-body format/style? was changed; or - a User-defined format is being exported; or - paragraph-attributes exist I want to know if I'd need to hack that native code there, in order to get cleaner HTML-output than I'm currently getting from OpenOffice. Yes. Incidentally, I've also tried Exporting as XHTML, but the resultant output is even worse than that from Save as ...: stuff that should not appear in a list does so, etc. Could you create an issue with a sample document showing the problem and assign it to sus? I've tweaked the Java-example servlet for document-conversion, so it takes an MS-Word doc as upload and returns (really just the file:/// URL of) an HTML-document. I do like so in my code: // Setting the filter name propertyvalue[1] = new PropertyValue(); propertyvalue[1].Name = FilterName; propertyvalue[1].Value = HTML (StarWriter); ... which I believe means, effectively, Save as ..., rather than Export, the latter involving a different area of the OpenOffice codebase, if I'm not mistaken. Whether SaveAs or Export is chosen just depends on whether you use storeAsURL or storeToURL. The difference is only that in one case the document takes over the new location while in the other it doesn't. The GUI stuff around these two function also uses different filters in both areas, but that's a limitation you don't have when using the API. All filters suitable for SaveAs can be used for Export also (but not the other way around as only filters for formats that OOo can load will be accepted in storeAsURL). So, what's the best way to make the desired improvements in the HTML-output? As both filters (the C++ one for HTML as well as the xslt based one for XHTML) seem to fail for you, the best way probably is the one you are more familiar with. If you know something about xslt, perhaps hacking the xslt for XHTML is better, because the native filter not only requires good C++ knowledge but also getting familiar with an unpredictable amount of OOo code (what exactly you will need to know depends on where your journey will take you). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] devel packages
Stephan Bergmann wrote: IMO a package X-devel only makes sense if the base package X contains something that has an API for clients, and those clients typically need some additional files to interact with X through that API (C headers, link libraries, etc.). The only parts of OOo that would qualify here are the URE and the OOo UNO API. For the latter, there is already the SDK---which also covers support for the former. Indeed. There might be another use case. That is to instantly build desired shared library files without waiting for finishing with full build process or, at least, building the desired module on the way of full build. A set of 'devel' packages would help software engineers slightly modify source code of OpenOffice.org and build desired shared library files. Scenario A customer wants to have Calc with a single sheet at its startup. There might be several solutions. E.g delivering and installing template files to every PCs over their organization, remotely replacing one of or some of shared library files such as scmi.dll as a patch, and so on. It seems the initial number of empty sheets is defined here: http://svn.services.openoffice.org/ooo/trunk/sc/source/ui/view/tabvwsh4.cxx SCTAB nInitTabCount = 3; //! konfigurierbar !!! for (SCTAB i=1; inInitTabCount; i++) pDoc-MakeTable(i); Substituting 3 with 1 and building scmi.dll might bring desired results. SCTAB nInitTabCount = 1; //! Try it !!! To build the module 'sc' to get locally modified scmi.dll, several header files 'deliver-ed' into $SOLARVER/$INPATH/inc/ by other depending modules would be required. If they are available as a 'devel' package, steps would be surprisingly easier than ever. ./configure ... ./bootstrap source xxxEnv.Set.sh cd sc export SOLARINC= $SOLARINC -I/opt/openoffice.org/basis3.1/include export SOLARLIB= $SOLARLIB -L/opt/openoffice.org/basis3.1/program build The same concept could be applied to looking into problems with 'dmake debug=1,' fixing bugs, confirming the fix, etc. Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Improving HTML-output after import from MS-Word (again)
(my last try with this post was left pending for nearly 24 hours, without explanation; sorry if redundant) per http://svn.services.openoffice.org/opengrok/xref/DEV300_m59/sw/source/filter/html/htmlatr.cxx#1013 there seem to be certain rules regarding when a P tag is output when using Save as ... in Writer (I tried to translate the German here into English -- I need help with that, incidentally): Ein P wird nur geschrieben, wenn - wir in keiner OL/UL/DL sind, oder - der Absatz einer OL/UL nicht numeriert ist, oder - keine Styles exportiert werden und - ein unterer Abstand oder - eine Absatz-Ausrichtung existiert, ode - Styles exportiert werden und, - die Textkoerper-Vorlage geaendert wurde, oder - ein Benutzer-Format exportiert wird, oder - Absatz-Attribute existieren A P is written only if: - we're not in a list of any kind; or - the paragraph we're in is in an unordered list; or - no Styles are being exported and a (lower distance?) exists or a paragraph-adjustment exists; or - Styles are being exported and the text-body format/style? was changed; or - a User-defined format is being exported; or - paragraph-attributes exist I want to know if I'd need to hack that native code there, in order to get cleaner HTML-output than I'm currently getting from OpenOffice. the problem is double-spaced output where it should be single-spaced; plus the occasional other glitch seemingly having to do with p tags within certain HTML lists. -- View this message in context: http://www.nabble.com/Improving-HTML-output-after-import-from-MS-Word--%28again%29-tp25530876p25530876.html Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Improving HTML-output after import from MS-Word (again)
I noticed this reply to your message on the list (from mba). Seems like you did not get it? larrydlefever wrote: per http://svn.services.openoffice.org/opengrok/xref/DEV300_m59/sw/source/filter/html/htmlatr.cxx#1013 there seem to be certain rules regarding when a P tag is output when using Save as ... in Writer (I tried to translate the German here into English -- I need help with that, incidentally): Ein P wird nur geschrieben, wenn - wir in keiner OL/UL/DL sind, oder - der Absatz einer OL/UL nicht numeriert ist, oder - keine Styles exportiert werden und - ein unterer Abstand oder - eine Absatz-Ausrichtung existiert, ode - Styles exportiert werden und, - die Textkoerper-Vorlage geaendert wurde, oder - ein Benutzer-Format exportiert wird, oder - Absatz-Attribute existieren A P is written only if: - we're not in a list of any kind; or - the paragraph we're in is in an unordered list; or - no Styles are being exported and a (lower distance?) exists or a paragraph-adjustment exists; or - Styles are being exported and the text-body format/style? was changed; or - a User-defined format is being exported; or - paragraph-attributes exist I want to know if I'd need to hack that native code there, in order to get cleaner HTML-output than I'm currently getting from OpenOffice. Yes. Incidentally, I've also tried Exporting as XHTML, but the resultant output is even worse than that from Save as ...: stuff that should not appear in a list does so, etc. Could you create an issue with a sample document showing the problem and assign it to sus? I've tweaked the Java-example servlet for document-conversion, so it takes an MS-Word doc as upload and returns (really just the file:/// URL of) an HTML-document. I do like so in my code: // Setting the filter name propertyvalue[1] = new PropertyValue(); propertyvalue[1].Name = FilterName; propertyvalue[1].Value = HTML (StarWriter); ... which I believe means, effectively, Save as ..., rather than Export, the latter involving a different area of the OpenOffice codebase, if I'm not mistaken. Whether SaveAs or Export is chosen just depends on whether you use storeAsURL or storeToURL. The difference is only that in one case the document takes over the new location while in the other it doesn't. The GUI stuff around these two function also uses different filters in both areas, but that's a limitation you don't have when using the API. All filters suitable for SaveAs can be used for Export also (but not the other way around as only filters for formats that OOo can load will be accepted in storeAsURL). So, what's the best way to make the desired improvements in the HTML-output? As both filters (the C++ one for HTML as well as the xslt based one for XHTML) seem to fail for you, the best way probably is the one you are more familiar with. If you know something about xslt, perhaps hacking the xslt for XHTML is better, because the native filter not only requires good C++ knowledge but also getting familiar with an unpredictable amount of OOo code (what exactly you will need to know depends on where your journey will take you). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
