Re: [dev] formula settings recognition
Hi, Please file an issue with a sample document and a description what you were actually doing. That way we can have a look at it and see what happens. And please add me (tl) as CC to the issue. Thanks, Thomas Matthew L. Avizinis wrote: Greetz, I think I've not been quite clear enough. The settings work fine when I set them for each equation when using the dialogs. There's no problem there. The problem is when I _generate_ the files. The options I provide in each given math object's settings.xml file do not seem to be adhered to. I was merely pointing out that when I /do/ use the dialogs the changes are saved to that file correctly. What I am not understanding however, is why the settings I'm providing for each equation when I generate the files are not read in as I would expect. Is there some other file where there is a link or association that has to specifically tell the equation to use those settings instead of the default? I hope that is a little better. Happy Holidays and peace to you, Matthew Avizinis Gleim Publications, Inc. Thomas Lange wrote: Hi, Matthew L. Avizinis wrote: Hello all, I am working on a project in which I generate Writer text files each of which may include one or more formula objects. There are apparently two basic files for each formula, a content and settings file. The formulae are rendered correctly except that custom settings I include in the settings.xml file don't seem to be followed, e.g. font-size, margins. When I change these values by means of the dialog boxes after opening a file, they are indeed changed for each formula individually and saved in each object's settings.xml file. So what is it that I'm missing? What is the correct method/reference to get a formula to properly use its settings.xml file when it is loaded/rendered? Any pertinent suggestions are very welcome. You need to press the Default button in the dialog otherwise the settings apply only to the current formula. Also at some point there was a bug over a short period of times in the developer builds. But it got fixed already. Thus if you're using OOo 1.0.x or OOo 2.0 everything should be fine when you press the Default button. Regards, Thomas - 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] Encrypted Basic modules can't be modified?
Hi Jürgen, thx for the fast answer, Peter Jürgen Schmidt schrieb: Hi Peter, Peter Eberlein wrote: Hi, can somebody reproduce the three following bugs: 1. Create a new basic library and encrypt it with a password. 2. Close the office and restart it. 3. Modify the macro in your encrypted module, push the save-button and close the office. 4. Restart the office. Changes are not saved. i can't reproduce this behaviour on a m143, seems to be fixed in OO.o2.0.1 It doesn't matter, if the library was created in the shared or in the user folder. Read only status of the script.xlb is false of course. Next: 1. Restart the office 2. Make a typo in the password dialog while opening your library. 3. Basic module is shown, but without any content. 4. You can't access your library until you have restarted your whole office. i can reproduce this behaviour, pleases submit an issue. I have no workaround in place. But the issue is important and we have to fix it asap. Done, issue 59247 Next: 1. Try to delete the password (replacing by an empty string). You will get a general input- output error. The new password () will not be saved. 2. Try another password. It will not be saved. i can't reproduce this behaviour on a m143, seems to be fixed in OO.o2.0.1 Juergen I deployed a lot of macros to the users and have to change them now. So what? Any workaround? OpenOffice 2.0 and WinNT SP6 Regards Peter - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [discuss] Incubator for vba macros
Jörg Wartenberg wrote: Hi Jürgen, would it be possible to implement this Wrapper API in StarBasic? I'am of course it is, you can implement it as a Basic library and can deploy this new library as a UNO package. But we should combine our efforts. Too many different approaches would totally confuse the end user. Juergen thinking about something like small StarBasic include files for each VBA function. This would allow the user, to read the code behind the wrapper API. (This wrapper code could be collapsed in the default view of the StarBasic IDE, to maintain readability). If the user want modify the imported VBA code, he has already UNO API code to start from. Regards Jörg Jürgen Schmidt schrieb: Hi, i agree 100% with Laurent, it means a second API and that of course is probably not what we want. But the question is how we can address all the VBA programmers to migrate to OpenOffice and it's complete different API model. Does it make sense to have a migration layer on top of the existing API for exactly the VBA and Basic programmers in general? I am not sure, the main API focus will be still on the UNO API and we will go forward with this approach. The VBA wrapper API is implemented in UNO as well and makes use of the existing API. That means it would be one abstaction layer higher and of course one indirection more which means slower than the normal API. From my point of view this kind of wrapper API should be used for migration only and everything else should use the existing UNO API. It can be designed as an extension package and people who want use it can install this package optionally for example. I am flexible when we think we need it i am willing to support it. But of course the VBA API is not better than our existing API (far from it), it has only the advantage that it is well known, has great IDE support (MS Dev Studio), is well documented (thousands of books) and many many people use it. I personally believe that we will never reach a 100% roundtrip with macros and i would concentrate on the existing API and improvements in this area. Some of our existing APIs should be redesigned or improved by using the UNO ease of use features and a lot of other things can be done to simplify the development of our existing API. so no vote from my side, no +1 and no -1, only the offering to support the project on the level of the existing API. Juergen Laurent Godard wrote: Hi Noel Thanks for your proposal and your presentation I'm aware that VBA macros are a problem on a migration and something has to be done. So you're proposal is welcomed Nevertheless, I'm afraid that using VBA paradigm inside OOo will more hurt than solve the problem. VBA has 2 parts : the language and the objects I'm not talking about the syntax here. Some compatibility efforts have been done in this directon and can be improved. The problem, imho, is on the API level Giving VBA support as you propose is implementing a new API for objects. You will then have two ways for defining objects : the OOo API one, The MS VBA one. It will be more difficult to understand things as these two objects, will have difference : a VBA cell is different tha an OOo one. How does this interact ? Is a VBA macro allowed to mix both API ? Is python script allowed to use VBA objects and OOo objects ? Are VBA macros only restricted to MS File format (i see no technical reasons for this) For me, at the end, it will be the end of any scripting language except VBA one. Forget OOoBasic, python, Beanshell or javascript. VBA is widely spread due to MS file format domination. Many people do know how to create VBA macros and then it will end with a big proportion of this language. A lot of documentation exists and we will be asked more and more to implement VBA subtilities But, VBA is not free ! OOo Project has no influence on its specification and it can be changed without any warning (look at the difference between MsOffice versions) Moreover, what about legal issues ? Are we sure there are any patent on this ? Are we allowed to implement an interpreter ? Noel, I'm really enthousiastic by you project in a technical point of view. But, i have to say -1 for the resons i gave, unless we build some policies like (only proposal, ideas not worked) - restrict vba to ms office file format (not opendocument or addons) - translate the VBA source code to OOo API to only have to deal with one model So -1 for me But totally open to discussion Regards Laurent - 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] - To unsubscribe, e-mail: [EMAIL
[dev] gcj registration time error with gcc 4.1 workaround
I got a dread no mapping from java to c++ error on registering java
components with gcj. It seems to be this tiny little regression in gnu
classpath.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
A silly little probable workaround for jurt shown inline here.
Index: com/sun/star/lib/util/UrlToFileMapper.java
===
RCS file: /cvs/udk/jurt/com/sun/star/lib/util/UrlToFileMapper.java,v
retrieving revision 1.3
diff -u -p -u -r1.3 UrlToFileMapper.java
--- openoffice.org.orig/jurt/com/sun/star/lib/util/UrlToFileMapper.java
7 Sep 2005 19:05:37 - 1.3
+++ openoffice.org/jurt/com/sun/star/lib/util/UrlToFileMapper.java
13 Dec 2005 11:34:14 -
@@ -95,6 +95,14 @@ public class UrlToFileMapper {
// the URI constructor might throw
java.net.URISyntaxException (in
// Java 1.5, URL.toURI might be used instead).
String encodedUrl = encode(url.toString());
+
+
+String mytest = encodedUrl.substring(0, 6);
+if (mytest.equals(file:.)) {
+String ans = encodedUrl.substring(5,
encodedUrl.length());
+return new File(ans);
+}
+
try {
Object uri = uriConstructor.newInstance(
new Object[] { encodedUrl });
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Bug with large tables / cells spanning more than one page
Bug is easily reproduced like this: open new doc create table with for instance 3 columns and 5 rows paste some text that makes the cell expand to over half the page into cell (col 0, row 0) and cell (col 0,row 1) This should split the cell (0,1) over the first and the second page, but instead the table is corrupted and weird looking. Ole-Kr. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [discuss] Re: [dev] Re: [discuss] Incubator for vba macros
Hi Jurgen, On Tue, 2005-12-13 at 09:24 +0100, Jürgen Schmidt wrote: I am flexible when we think we need it i am willing to support it. But of course the VBA API is not better than our existing API (far from it), Of course - there is no argument as to which API is 'better' per-se; personally I only learned the StarBasic API by reading the http://documentation.openoffice.org/HOW_TO/various_topics/VbaStarBasicXref.pdf Vba to Starbasic cross-reference guide (which was much appreciated incidentally). it has only the advantage that it is well known, has great IDE support (MS Dev Studio), is well documented (thousands of books) and many many people use it. You forgot the macro recorder; most of the VBA macros we analyse show serious signs of being macro record/cut/paste/adapt; almost no flow control, nothing complex in them :-). But sure - no-one is proposing that people start writing new macros using the VBA object model vs. OO.o. I personally believe that we will never reach a 100% roundtrip with macros and i would concentrate on the existing API and improvements in this area. Some of our existing APIs should be redesigned or improved by using the UNO ease of use features and a lot of other things can be done to simplify the development of our existing API. Of course that is valuable work - but outside the remit of the proposed incubator - which is really an interoperability project: yes, almost certainly we will never reach 100% compatibility - lets face it that would implicitely involve 100% feature parity with MS Office since ~all features are exposed to VBA - which seems unlikely. However - I'm certain that we can provide something extremely useful to lots of people, that will help them migrate to OO.o. so no vote from my side, no +1 and no -1, only the offering to support the project on the level of the existing API. Well - it's encouraging that you're not opposed :-) thanks for your input insight - much appreciated, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [discuss] Re: [dev] Re: [discuss] Incubator for vba macros
On Tue, 2005-12-13 at 12:10 +, Michael Meeks wrote: Hi Jurgen, On Tue, 2005-12-13 at 09:24 +0100, Jürgen Schmidt wrote: I am flexible when we think we need it i am willing to support it. But of course the VBA API is not better than our existing API (far from it), Of course - there is no argument as to which API is 'better' per-se; personally I only learned the StarBasic API by reading the http://documentation.openoffice.org/HOW_TO/various_topics/VbaStarBasicXref.pdf Vba to Starbasic cross-reference guide (which was much appreciated incidentally). Thanks. I was about to mention the existence of this document. [snipped] -- PLEASE KEEP MESSAGES ON THE LIST. OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] rel-column-width
Seasons Greetings to all, I am sending this to both lists because I'm not sure which group this issue really belongs to since it has xml Writer format properties but is also a development issue I think. If most of you folks who are regulars here monitor both lists just let me know and I'll send any further messages to one list or the other. Another question please In a table (#1) I've generated, the following is created by Writer when I File | Save: style:table-column-properties style:column-width=51.01mm style:rel-column-width=65535*/ and in a table (#2) I get: style:table-column-properties style:column-width=50.01mm style:rel-column-width=32767*/ and in a third (#3) this: style:table-column-properties style:column-width=50.01mm style:rel-column-width=32768*/ I did not generate the */style/:rel-column-width*,* *only the style:column-width property. * *So how is this number calculated? What is it /rel/ative to? I'm assuming it's called that because it's the column width relative to something. The values are all different even though the style:column-width is the same. I could find no documentation on this element in the odt spec or anywhere else for that matter. Can anyone provide some knowledge transfer please? It would be much appreciated. If anyone is interested, what I'm doing is, from xml data via several xslt stylesheets generating all the individual files needed by an OpenOffice Writer document dependent on what objects are in it, e.g. formulae, images, tables, etc. Then using the java zip class in a rhino javascript extension function (I'm using the Xalan xslt processor), I zip the files together to produce a Writer document. It works quite well, except that a few areas seem murky such as with equation settings (which I mentioned in another e-mail) and the issue I describe here. Peace to you, Matthew L. Avizinis Gleim Publications, Inc.
Re: [dev] Help in building OpenOffice version 2.0
On 12/13/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi!
Am Kenny from the Open Swahili Localization Project (
www.kilinux.udsm.ac.tz)
I faced the following problem during the Building process of OpenOffice
2.0
I use a computer with FEDORA CORE 4 and i have download jdk1.5.0_06 and
configure the doconfigure file by specifying the following line about
with-java as follows
--with-jdk-home=/usr/java/jdk1.5.0_06
After running again the
./doconfigure ./doconfigure 21 | tee -a logs/kilinux20051213
The following errors appears during the compilation of 74 source file
Try to pass through the lines below to see clear what was going on during
the compailation
compile:
Compiling 74 source files to
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/classes
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:137:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
this.superClassName = Type.getInternalName( superClass );
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:185:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
interfaceNames[i]=Type.getInternalName(
interfaces[i] );
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:362:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.or
g.objectweb.asm match
Type.getType(Object.class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:363:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
new Type [] {
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:364:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(String.class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:365:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(Object [].class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:366:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(Interpreter.class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:367:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(CallStack.class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:368:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(SimpleNode.class),
^
/kilinux/ooo2-build/ooo_3/linux-build-ooo2/build/ooo680-m3/beanshell/unxlngi6.pro/misc/build/BeanShell/src/bsh/ClassGeneratorUtil.java:369:
reference to Type is ambiguous, both class java.lang.reflect.Type in
java.lang.reflect and class bsh.org.objectweb.asm.Type in
bsh.org.objectweb.asm match
Type.getType(Boolean.TYPE)
^
[dev] P2P Project
Everyone! The P2P project needs you :-) See http://distribution.openoffice.org/p2p/ Deepankar Datta, who helped to put the project into shape and who initially created and maintained the Web pages, no longer has the time to manage the project. Adrian Mcneil and Mike Niblett (who does the tech stuff) continue the effort. But we need someone who is willing to dive in and make it theirs. So, what's required? * A couple of hours a week * Some (the more the better) knowledge of P2P clients, policies, ethics * Basic skills with creating and in maintaining Web pages * Interest in the field This is an important project, as it complements our existing archipelago of volunteer mirrors and showcases the distribution coolness and advantages of open-source software. If you are interested, send a note (not a CV! :-) ) to me (louis at openoffice.org) and cc Adrian Mcneil (adrian.mcneil at gmail.com). Cheers Louis Distribution Project Lead http://distribution.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] scripted multiplatform .doc to .html conversion
Kirk Israel wrote: Sorry, I'm not being willfully dense here...I understand that if I'm doing this through the API, there has to be an instance of OOo running, but are you saying that the segment of the source responsible for reading in Doc (and the other segment, reseponsible for spitting out HTML) is so tightly coupled with the rest of the system as a whole that extracting those two segments isn't feasible, that saying aha, THIS is the conversion function wouldn't get you anywhere, because it depends on so much other stuff working to run? I think you have a misconception how document conversion in OOo works. There is no direct translation between input and output format, input filters always convert the input format into a representation in memory (the core of a document) and the output filter converts this into the output format. If you think about this a little bit you will see that anything else doesn't make sense, at the end OOo is an application and not a conversion service: why should there be code that directly translates from e.g. doc to html? OOo itself doesn't need such code. So it will never make sense to isolate the filter code, you always also need the code of the document core also. Theoretically it is possible to take the code of the filters and the core and make it a smaller package but until now nobody needed something like this so very badly that he started the work to create such an environment. You will need a kind of an application anyway and you will need UNO and its bootstrapping, you will need some of the services in OOo used by the filters etc. So it's possible but quite some work to do and all you earn from the work to make it happen would be that you safe some MB on disk. Is that worth the effort? BTW: you don't need an *installed* version of OOo on your machine, it's enough to have a runnable *copy* (though in this case you have to create each UNO connection manually because your system doesn't provide a hint where the OOo installation is). Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] scripted multiplatform .doc to .html conversion
Mathias, thank you for your feedback...I have a few responses. I think you have a misconception how document conversion in OOo works. There is no direct translation between input and output format, input filters always convert the input format into a representation in memory (the core of a document) and the output filter converts this into the output format. If you think about this a little bit you will see that anything else doesn't make sense, at the end OOo is an application and not a conversion service: why should there be code that directly translates from e.g. doc to html? OOo itself doesn't need such code. I assumed that it would be a doc to internal unmarshalling followed by a internal to HTML unmarshalling, for obvious reasons (like need 2n filters rather n!)...I guess I was envisioning a small(ish) bit of code that would do something like (in pseudojava) Document doc = OOoUtils.getDocument(HTML_CONVERTER,somefile.html); OOoUtils.writeDocument(DOC_CONVERTER,doc,output.doc); maybe with some Input/Output Streams or services instead, but that's the general jist. So it will never make sense to isolate the filter code, you always also need the code of the document core also. Theoretically it is possible to take the code of the filters and the core and make it a smaller package but until now nobody needed something like this so very badly that he started the work to create such an environment. You will need a kind of an application anyway and you will need UNO and its bootstrapping, you will need some of the services in OOo used by the filters etc. I see what you're getting at, the conversion process isn't self-contained but dependent on a series of services, strucutres, and what not. Just by reading some recent archives of this list, I'd say this kind of scripting is fairly sought after...but maybe the people who want to cherrypick the functionality aren't the same kind of people willing to put in the work to make it an isolated tool. So it's possible but quite some work to do and all you earn from the work to make it happen would be that you safe some MB on disk. Is that worth the effort? Quite possibly not...I think it was a desire for more easily embedding installation of just the conversion stuff rather than having OOo be a seperate install. If you could easily embed just a few filters and some supporting classes at the source code level into a larger project, that would make it more transparent to the user. BTW: you don't need an *installed* version of OOo on your machine, it's enough to have a runnable *copy* (though in this case you have to create each UNO connection manually because your system doesn't provide a hint where the OOo installation is). Aha, good to know. Best regards, Mathias Thank you! Kirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
