Re: [discuss] OO.o Macros with Python interpreter?
M. Fioretti wrote: Thanks for the prompt answer, I'll look at the links you provided. One thing to mention, maybe, is that I said Macro, not Add on. I thought you might have been thinking about .odt files, but wasn't sure. In any event, Python probably still comes closer to what you want than anything else I can think of. I was thinking to something I can embed into an .odt file and distribute (say a quiz system for training classes, or whatever strikes your fancy). In other words, assume I study what you told me, and manage to make the Python macro work on my (Linux) PC. Can I embed it in an OO.o file, and how many chances there are that if I send it by email to another (Windows) user he will be able to run it just as it did on my computer? (Never mind security for now, I need to understand the basic flow first). I can answer the second part of your paragrah: OOo itself comes with Python included. It is in the 'programs' directory. If you made an add-on with Python, it would install just fine on any computer. The addon would be a zip archive containing (1) one or more .py files for the actual code and (2) an XML file that tells OOo to add a menu entry and call your program when the user clicks on it. But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). If what you want *must* be in a .odt file I think you're stuck with StarBasic for now. May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Quoting M. Fioretti [EMAIL PROTECTED]: Greetings, What if I wanted to implement some OO.o macros with Python? What should I study, do, code, patch, download...? I suggest you to read Robert Vojta's blog and also subscribe to the dev@udk.openoffice.org list where the PyUNO guru -- Joerg is always helping. http://blog.vojta.name/archives/2005-06-02T11_51_04.html Rationale: poor end user (me), without any realistic possibility or skills to hack OO.o core code, not really eager to dig into StarBasic, has some complex Python text processing routines *already* written from other projects, by him and other guys. Hence, poor guy would love to use *those* Python scripts from within OO.o directly on the content of OO.o files. Instead of learning StarBasic and rewrite the same routines with it. So, is there a way for a normal end user, which has only the pre-built OO.o binaries, to add a Python interpreter to it and attach scripts to buttons, menus etc? TIA, Marco PS: Ditto with Perl, in case using it in OO.o is different than Python -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ It's always socially unacceptable to be right too soon. -- RAH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OSS in Brazil
Quoting Fbio Emilio Costa [EMAIL PROTECTED]: Hi! Em 05/06/05 08:30 Tony Pursell escreveu: I saw this last week on the BBC News 24 channel. Unfortunately, it didn't show any example screenshots of the OSS they are using. They only managed a screenshot of XP and a shot of the MS HQ in Brazil (a very impressive building - showing how much they have been profiting from a county which cannot afford their software). As Brazilian I could say for you: Lula's brazilian government is using Freedows (made by Cobra, a local IT business), a Linux Port with Windows layout. Other options (adopted by some of PC Conectado factories, like Semp Toshiba and Itautec) are Insigne Linux and Mandriva (although I didn't heard anyone using Mandriva). The packages are a more-or-less-common distribution: KDE, OOo, Firefox, Thunderbird, the GIMP, and so on. In the government I know that is very intense the use of Debian, and I believe that, as Cobra is partly owned by the Brazilian Government via Banco do Brasil (Brazil's Bank) - the Cobra's biggest isolated shareholder - Freedows are in a rush. -- Thanks! Fabio Emilio Costa Borda da Mata - MG - Brazil ICQ #:173799674 [EMAIL PROTECTED] Nick:SamWeasley Jabber: [EMAIL PROTECTED]MSN: [EMAIL PROTECTED] Yahoo! Messenger:hufflepuff0305 Linux User #328087 (counter.li.org) Orkut Profile: www.orkut.com/Profile.aspx?uid=16619557238254357700 Blog: www.livejournal.com/users/fabiocosta Wow this is really interesting stuff, do you have URL's talking more about the topic. Doesn't matter if it's in porguese. -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
D. Carrera wrote: But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). Why not, if I may ask? May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... Before answering gee, that's so far in the future, why bother?, keep in mind that OpenDocument is being advertised as *the* long term solution for governments, multinationals and so on. All organizations that have a huge inertia to switch, and before buying the whole FOSS thing still need to see or be told that there *is* a coherent, long term strategy behind. Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. Teacher writes on OO.o, students learn on KOffice. Or vice-versa. That's why I said embedded into the .odt file. Of course, if (in the conditions above) there is any other solution which has the same end result for the student/user is OK, but is there? Ciao, Marco F. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OPEN OFFICE BASE
Hi, or press just F4 in a writer or calc document to open the data source view. Best regards, Ocke dba.openoffice.org Daniel Carrera wrote: Base is a new component in the development release. If you want to try it out you will have to download the beta version. The beta is available from our website. Cheers, Daniel. [EMAIL PROTECTED] wrote: Hi, Discuss Have just downloaded 1.1.4 but Base does not appear in the Open Office Programme menu Please can you advise why it is not there? Thanks Tom Walsh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Sachsenfeld 4 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Example isn't another way to teach, it is the only way to teach. Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OSS in Brazil
Hi, http://news.bbc.co.uk/1/hi/business/4602325.stm :) khirano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Hi Marco, Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation 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: [discuss] OSS in Brazil
http://www.iht.com/articles/2005/03/29/business/sware.html I read this in March. So they have made it now :) Cheers, khirano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Quoting Laurent Godard [EMAIL PROTECTED]: Hi Marco, Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingnierie OpenOffice.org Indesko http://www.indesko.com Nuxeo CPS http://www.nuxeo.com - http://www.cps-project.org Livre Programmation OpenOffice.org, Eyrolles 2004 Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Microsoft's EU Proposal a Blow to Open Source
for all the idealism in the post, I will simply comment that MicroSoft would only benefit themselves. They aren't around to benefit anyone else. Spyglass model or otherwise, they make more profit lieing cheating and stealing then by excercising integrity. My two cents. Rigel On 6/6/05, Gary Edwards [EMAIL PROTECTED] wrote: eWeek has published a series of articles covering the recent anti trust settlement between Microsoft and the European Union. To me the most interesting piece is an article titled, Microsoft's EU Proposal a Blow to Open Source. The article can be found at: http://www.eweek.com/article2/0,1759,1824675,00.asp Under the current terms of the Microsoft proposal, the author of the article, Matthew Broersma has got it right. It's an enormous blow to Open Source. Measures imposed on Microsoft by the European Commission last year were meant to restore competition in the workgroup server market. Microsoft was forced to come up with a means of disclosing important protocols and interfaces that connect the MS desktop productivity environment to MS servers and MS devices. The plan Microsoft came up with is a RAND (Reasonable and Non Discriminatory) license for access to these communications and connectivity protocols and interfaces. Price and licensing restrictions effectively excludes Open Source access. Even though Open Source alternatives are the only meaningful competition left, the Microsoft juggernaut having crushed any and all profit oriented corporate efforts, the European Commission is nevertheless at a loss to do anything other than accept this measure of Redmond magnanimity. But fear not. There is a solution, which, as measure of our own magnanimity, i'll call the Spyglass Model of Fair Access and Licensing. The model attempts to provide some structure and meaning to the meaningless RAND. What's reasonable and non discriminatory to Microsoft turns out to be a catch-22 highway to oblivion for everyone else. To be reasonable we need to have a solid marker, reflecting the marketplace, against which access rights to communications essentials can be reasonably distributed. Let me try to explain. Clearly we need a solution to the problem of providing fair and equitable access to these critically important interfaces and protocols. Without access there can be no open market interoperability worth a competitive damn. Lucky for us that Microsoft has already come up with a solution that has worked very well for them in the past, and if applied to the current situation would preserve the competitiveness of open source alternatives. Let's call it the Spyglass Model. Remember Spyglass? Faced with the prospect of the Netscape Browser totally taking over the Internet, and having no expertise to write their own response, Microsoft turned to Mosaic Browser expert Spyglass. The deal was simple. Spyglass writes a competitive browser for Microsoft, and Microsoft pays them a percentage of every browser sold. A win win for everyone. Microsoft then proceeded to bolt the Spyglass browser into every Windows distro. Since there was no break down of the Windows bundle into specific charges for specific components like the browser, there was no requirement to reimburse Spyglass for Herculean effort in providing Microsoft with a competitive browser. Funny how MS Office was handled differently, but nevertheless managed to ship bundled with most distributions. What's good for the goose is good for the gander. I think the EU can solve the interoperability problems between MS desktops and competitive servers and services by following the Spyglass model and putting some structure to the RAND licensing model Microsoft has proposed. Let competitors needing totally open, clear and transparent access to these critically important protocols and interfaces pay Microsoft according to what they charge for components utilizing these interfaces in their distributions. Let the regulators audit Microsoft to make certain they provide all interfaces and protocols. It's been more than a year since Microsoft came to similar terms with the USA Courts regarding competitive access rights to the same interfaces and protocols. Since then only seven companies have come up with the booty to purchase MS RAND access rights. And they did so with no guarantee that the interfaces and protocols they were provided with represented the whole enchilada. For all these seven know, they could have purchased themselves into second class competitiveship for aeon's to come. The Microsoft way has long been to provide one set of protocols and interfaces to third parties, and reserve another, secret and enhanced set for themselves. Why should they give up a proven, battle tested business practice guaranteed to fill the coffers? The MS desktop productivity environment has a 93% plus market dominance. What server, device or Internet service doesn't need access to
Re: [discuss] OO.o Macros with Python interpreter?
Hi, Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? if written as a starbasic macro, it will remain in the file Nevertheless, OpenDocument Oasis standard do not deal with macros so IMHO .odt files handles more information (embedded images, macros ...) than the OpenDocument standard states. OpenDocument for me is /only/ the xml description of an office document but i may be false ... Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingnierie 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: [discuss] Re: HBS WK: Who will win Microsoft or Linux?
OSS has already replaced a number of commercial elements. Firefox for browsing, Thunderbird for email, OpenOffice for (guess what here) in my business, Linux for a file server ( soon the desktop). I don't get your commment. :-) Cheers, Alex Janssen Chuck wrote: Anthony Long wrote: I'm curious to know what people think about this article? http://hbsworkingknowledge.hbs.edu/item.jhtml?id=4834t=technology Cheers, Anthony There are four things in life that are guaranteed... 1) You will be born 2) You will die 3) You will pay taxes 4) OSS will _NEVER_ replace commercial software - 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]
[discuss] Re: How to standardize Spreadsheet formulas?
Hello Gary, will the formulas be stored as the string that I type in the spreadsheet application, or will the tree structure of the formula be analyzed and stored in a appropriate XML structure with different attributes for operator, operand. Will cell references be parseable and resolveable by XSLT? Regards Jörg Wartenberg PS: Unfortunatley I'am not a XML expert, but I hope my questions are reasonable for you too. Gary Edwards schrieb: Hi Marco, There has been much discussion at the OpenDocument TC regarding the OpenFormula Project, initiated by David Wheeler in October of 2004. This was a concern for the EU, and lucky for us David took up the challenge. Dr. Nathaniel Borenstein, one of the IBM representatives who recently joined the OpenDoc TC, is also very interested in the OpenFormula Project. David has posted many discussions of OpenFormula to the OASIS OpenDoc public comment list serve. Your might want to check these conversations out. He has also posted a rough draft of the OpenFormula spec. It is at: http://www.dwheeler.com/openformula/openformula.pdf or http://www.dwheeler.com/openformula/openformula.sxw Other stuff is at: http://www.dwheeler.com/openformula/ A sample clip of David's discussion: David Wheeler I believe that OpenDocument's release should NOT depend on the completeness of OpenFormula - send OpenDocument on to its next stage when you're ready! The only issue I have with OpenDocument related to formulas is that I think anim:formula and draw:formula should be changed to use ; as their function parameter separators. If the OpenDocument spec is changed to make ; the separator, then they become compatible with table:formula, and I think that'd be a good idea. --- David A. Wheeler / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Laurent Godard wrote. IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation The only answer I have to this is the same I gave to the KOffice developers when they made the very same remark a few days ago: 1) technically, you are 100% right, and I even agree, but 2) after years of advertising what is now OpenDocument as THE one, application-independent, truly open, durable solution etc... that frees your data from lock-in to any single SW provider (including free as in freedom ones)... ...end users are going to be mightily pissed when they start exchanging .odt files from/to OO.o and KOffice or whatever else and they don't always work in the same way. See the example I made of training material, possibly distributed via CD-Rom. Oh, and remember that end users include all those governments which, with great effort, are being carried to the notion of perpetually available data, regardless of the application: this is what OpenDocument gives you. This loses a *lot* of relevance if there is no defined path to standardize macros and spreadsheet formulas, and the will to follow it. 3) Therefore, the way I see it, OO.o, KOffice and whoever else will go OpenDocument publicly (which *is* a wonderful thing) have *already* committed to standardize those things too. They just haven't realized it yet, but the sooner the better. For PR, at least. Ciao, Marco F. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] HBS WK: Who will win Microsoft or Linux?
I would say that in a few years time Microsoft will be heavily indebted for its bare survival, on projects like OpenOffice.org, Mono, wine and ReactOS - because they're F/LOSS projects that do make use of the Win32API and DotNET - Microsoft will wind up being a retailer of a few high-cost development tools and a good part of their cash flow will be dependent on the people they have intimidated into paying for irrelevant and totally useless software patent licenses. Just my 0.02c - probaby heavily inflated. Wesley Parish On Tue, 07 Jun 2005 05:59, Anthony Long wrote: I'm curious to know what people think about this article? http://hbsworkingknowledge.hbs.edu/item.jhtml?id=4834t=technology Cheers, Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] Re: OO.o Macros with Python interpreter?
Marco Fioretti wrote: Laurent Godard wrote. IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation The only answer I have to this is the same I gave to the KOffice developers when they made the very same remark a few days ago: 1) technically, you are 100% right, and I even agree, but 2) after years of advertising what is now OpenDocument as THE one, application-independent, truly open, durable solution etc... that frees your data from lock-in to any single SW provider (including free as in freedom ones)... ...end users are going to be mightily pissed when they start exchanging .odt files from/to OO.o and KOffice or whatever else and they don't always work in the same way. Perhaps I am too learned, but I'd NEVER expect interoperability on OpenDocument to extend to macros or any programming function. OpenDocument attaches to its title: a document, a piece of paper. If you go to macros you are talking about an _application_ standarising on that has been much more difficult ever. For that several software makers MUST agree in a common API. Even within single companies like Microsoft or Adobe, different products use difefrent APIs, just because they were created by different people. It is rather impossible that an .odt file may contain a macro functional at OOo, KOffice or whatever. This is not the same as saying that a CONVERTER cannot be build. But that is a different approach. - Enrique - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). Why not, if I may ask? Uhhm... because no such functionality is implemented yet. May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Fair question, but you partly answered it yourself. I did? wow! ;-) OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... Ah. I am not aware of Python macros being part of the OpenDocument spec. Come to think of it, I don't know how OpenDocument deals with macros. Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. I very much doubt that this is possible. A macro always uses the OOo API, and this API has no connection with OpenDocument. Teacher writes on OO.o, students learn on KOffice. Or vice-versa. That's why I said embedded into the .odt file. Of course, if (in the conditions above) there is any other solution which has the same end result for the student/user is OK, but is there? I don't think there is. But ask Gary, he's the OpenDocument guru. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Alexandro Colorado wrote: Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. Not quite, but close ;-) OpenDocument can do a few things that sxw can't do; it's more general and powerful. But they are very close. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? The macro would be in the file, and would definitely be portable to another OOo2.x. But I'm pretty sure it won't be readily portable to KOffice. I don't think that macros are part of the OpenDocument specification. I guess it's similar to how OpenDocument allows you to embed an OLE object, but the recipient might not necessarily know what to do with it. Could you do me a favour? Prepare a .odt file with a macro in it (e.g. hello world) and send it to me. I'd be interested in seeing what it looks like inside. I can't do this myself, I haven't been able to install OOo1.9 on Ubuntu. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Daniel Carrera wrote: Come to think of it, I don't know how OpenDocument deals with macros. OpenDocument itself shouldn't deal with macros, but this is something that _should_ be standardized, or at least well known. This is the hole I'm trying to fill. I very much doubt that this is possible. A macro always uses the OOo API, and this API has no connection with OpenDocument. Eh eh... This is the same simplification as OpenDocument = OO.o. It would be more exact to say that the *interpreter* of a macro must be written for the application that calls it (OO.o or whatever) and today the only macros found in pre-OpenDocument files (.sxw, .sxc) are written in a language that was designed only for *StarOffice*, not for its file *format*. See my other reply. Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: OO.o Macros with Python interpreter?
Enrique wrote: If you go to macros you are talking about an _application_ standardising on that has been much more difficult ever. No, I'm talking of a _language_. You can write Python, Perl or many others and, with some obvious exceptions, those scripts will run on different platforms. For that several software makers MUST agree in a common API. Eh eh... this is one of the things it is necessary to expose. Even within single companies like Microsoft or Adobe, different products use different APIs, just because they were created by different people. Bingo! You are comparing closed source apps with open source ones. Different proprietary products *must* invent different APIs to lock in users. FOSS ones, we are told, need no such tricks to survive. It is rather impossible that an .odt file may contain a macro functional at OOo, KOffice or whatever. please let me know what you think of my reply to Daniel, where I talk of a set of python functions etc Thanks, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] GetStorage, name: No Content!
Following weekend thunderstorm had problems with lan and accessing internet, since mostly resolved. But when I try to open OpenOffice.org 1.1.4 I get an error message, OpenOffice.org cannot be started due to an error in accessing the OpenOffice .org configuration data. Please contact your system administrator. The following internal error has occurred: GetStorage, name: No Content! Unfortunately, I am the system administrator, now lost, lone and forlorn. Repair did not work. Would appreciate any help. Carl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: OO.o Macros with Python interpreter?
Hi there! [...] please let me know what you think of my reply to Daniel, where I talk of a set of python functions etc What I think is that you think about things that in reality are very hughe and complex as being small and simple things. When you say A set of python functions that just sounds like you are thinking an API for an Office Programm like OOo would only need well let´s say only a handful of functions to be exposed to someone wanting to write macros or extensions in Python or whatever language. The reality is much different: OOo exposes lots of special tiny details to the programmer enabeling a wide range of possibilities to modify documents and the user interface or to automate tasks. The OOo API can be called from different languages Basic, java, pyhton, C++, ... Please have a look at the reference manual at http://api.openoffice.org/docs/common/ref/com/sun/star/module-ix.html to see how big and complex the API really is. This is definitifly not something that can be redesigned and rewritten from scratch easily in a few man-weeks work (eg. it´s not doable in some summer code camp or something similar like you suggested). One would have to do it all again from scratch if a new API should be created which should be usable by more than one open source applications. Despite that the implementation of the API is interlocked with the implementation of the programs features, which means you would have to rewrite most if not all of that too. The Koffice API might eventually be not that complex but you can be sure it´s totally different. And thus it would not be easy to align those two. If those two office packages had almost zero history and - well lets say development would just have been started a few weeks ago on them or similar - things may be different, but after all why start two fresh projects than using the same API, you would be better of concentrating on finishing one using the API you would have designed. Having said all that I suppose if it´s just for the very very very simple tasks like inserting some text into a document etc. there might in theory be the possibility to create two versions of a small library, exposing the same API to the programmer using two different sets of the underlying more complex Application APIs insided. Portability would than be there but usability and options for such a lib would be very limited compared to using the applications current own APIs directly. Thanks, Marco Kind regards, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: As for macros, the issue is more tricky because a macro is a program that tells the application to do something. Well, not exactly, if I have understood it correctly. A macro is a small program written in some _language_. Uhhhm... what does that have to do with anything? Any program is written in a language. It is NOT the code _and_ its interpreter. The latter, yes, is definitely not portable. A macro is a set of instructions to do something. Those use the application's API. The application is the interpreter. This is what I'm thinking about: 1) Python interface for opendocument, ie set of function definitions that read/write odt files and their elements What you are thinking is a new API. OpenDocument is not an API. Look, a macro is not like a stand-alone program. It needs to interact with another program (the application) and must do so through the application's interfaces (API). It is conceivable that one could make a standard API for macros, but OpenDocument is not it. 3) Then, you and I write a macro in Python calling the library defined in 1) above on whatever platform and once... An example of why this is difficult: Now you'd be requiring every implementation of OpenDocument to include both a copy of Python and a compliant copy of said library. That's quite a bit to ask. 5) we can then send the .odt file to anybody with: any .odt program (OO.o, KOffice...) + Python + his own specific implementation of 1) above... I'm pretty sure that OpenDocument does not include an API for macros, much less one that includes Python bindings. I couldn't imagine that such a thing would be required for OpenDocument compliance. I have written Python above because it is already useable *today*, or so I understand, both in OO.o *and* KOffice, Not through the same APIs and not as part of the OpenDocument standard. Look, what you want is great, but OpenDocument isn't it. Any feedback on the flow above, from suggestions on how to implement it to (polite, please! ) strong criticism is welcome. Defining a common API between OOo and KOffice would be a challenge. Getting OASIS to adopt it as part of the file format would be a greater one. What you want is fantastic, but very very difficult. Before I forget: if this does make sense, why not add it to the list of google summer of code OO.o projects? Just in case somebody felt like doing it? I doubt this could be done in a summer. I doubt that even the spec for this new API could be agreed on in a summer. But I'm no expert. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: OO.o Macros with Python interpreter?
Marco Fioretti wrote: Even within single companies like Microsoft or Adobe, different products use different APIs, just because they were created by different people. Bingo! You are comparing closed source apps with open source ones. Different proprietary products *must* invent different APIs to lock in users. FOSS ones, we are told, need no such tricks to survive. For once in my life, I will defend Microsoft. I'm sorry Marco, but no. Using different APIs between Word and Front Page does not at all help Microsoft achieve lock-in. And to some extent makes it harder. But the simple fact is that they are different applications. It is rather impossible that an .odt file may contain a macro functional at OOo, KOffice or whatever. please let me know what you think of my reply to Daniel, where I talk of a set of python functions etc I agree with Bernd (on another post) in that you seem to miss the complexity of designing a new API and having it implemented accross several office applications. I honestly believe that if something like that happened, it would *kill* OpenDocument simply because it would be next to impossible to support by anyone. This wouldn't be the first time that an attempt at standarization gets killed because a committee decides to add eccessive complexity. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] HBS WK: Who will win Microsoft or Linux?
On Mon, 6 Jun 2005 [EMAIL PROTECTED] wrote: [...] You would think that a conservative institution like Harvard would wanna skew its results in Microsoft's favor. But I thought that their analysis was surprisingly not handicapped very much in Microsoft's favor. Perhaps that's the best they could do given the data. ;) -Lars Lars Nooden ([EMAIL PROTECTED]) Software patents harm all Net-based business, write your MEP: http://wwwdb.europarl.eu.int/ep6/owa/p_meps2.repartition?ilg=EN - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: OO.o Macros with Python interpreter?
Marco Fioretti wrote: Think Javascript applets controlling what you enter in a web form, runnable by all *decent* browsers, versus all the possible FireFox extensions that even make coffee for you. OpenDocument already include xforms which covers much (most?) of what people use Javascript for. But don't confuse the very limited functionality of Javascript with macros. In any event, a vastly simplified API is certainly vastly easier to get going, but it will be vastly less powerful. But it still won't achieve your goal of making macros app-independent. Macros have access to an API that is much bigger than Javascript. OpenDocument is much more complex than HTML. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] HBS WK: Who will win Microsoft or Linux?
On Tue, 2005-06-07 at 13:05 -0400, Lars D. Noodn wrote: On Mon, 6 Jun 2005 [EMAIL PROTECTED] wrote: [...] You would think that a conservative institution like Harvard would wanna skew its results in Microsoft's favor. But I thought that their analysis was surprisingly not handicapped very much in Microsoft's favor. Perhaps that's the best they could do given the data. ;) These professors are sincere, but they are ignorant of important Open Source drivers (l10n, foreign gov't support of domestic IT) and do not see the limitations of their field. To wit, **social** models about the adoption of innovation, not economic models, are more descriptive of the Open Source situation. Also, the premise of FLOSS vs MS misses what is so powerful about FLOSS. If FLOSS were dedicated to killing MS, it would lose. As is, the scope of FLOSS's objectives makes it much more powerful. At best we see almost 100% FLOSS in the globe with US being about 50% MS 50% FLOSS in the mid-term. US will be the only market to hold onto MS; even piracy wont hold ex-USA. Long term, MS will be negligible unless they start to market FLOSS products. -Sam -Lars Lars Nooden ([EMAIL PROTECTED]) Software patents harm all Net-based business, write your MEP: http://wwwdb.europarl.eu.int/ep6/owa/p_meps2.repartition?ilg=EN - 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: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. Yes, that's an interesting approach. Unfortunately the Open Document standard doesn't say anything about macros (or any other external content). So what you could achieve now (at best) is an OOo extension of the OD standard, but because we don't want to be Microsoftish, we should call this an OOo feature, not an Open Document feature. To realize your idea (what definitely is possible) *and* make it future-proof we miss the standardization. But OK, this is only a general remark because you emphasized the Open Document relation by yourself. Let's put this aside for the moment. [Personal estimation: In general our way to store macros inside packages is very open and easily portable so that it might have a good chance to enter the OD standard with only minor changes once people want to extend the standard for document macros. At least the conversion effort for you OOo documents should be limited.] Embedding arbitrary content into the packaged OO.o(!) file format is possible, using it needs a component that is able to handle this content. Our Scripting Framework uses this feature of the package file format to allow for embedding macros written in Java, BeanShell or JavaScript by storing script parcels inside the package and providing runtime components for them. There is also an integratation of Python/PyUNO into the Scripting Framework. Quoting Jörg Budischewski from dev@udk.openoffice.org: Subject: [udk-dev] FYI: Integration of python-scripts in Tools/Macro dialog available since OOo 1.9.m79 Date: Sat, 19 Feb 2005 21:56:57 +0100 From: Joerg Budischewski [EMAIL PROTECTED] Hi, since the above mentioned version, pyuno supports the office scripting framework in the upcoming OOo-2.0 release. The support is limited to the 'core' framework, meaning that execution and assigning of macros works fine, but editing and debugging macros is not integrated in OpenOffice.org's UI (simply because of the lack of development resources). Thus, this feature is targeted at more advanced script developers. Details about the integration can be found at http://udk.openoffice.org/python/scriptingframework/index.html In case you don't know pyuno, have a look at http://udk.openoffice.org/python/python-bridge.html Bye, Joerg Budischewski I can't say how good this integration works, but I have a lot of confidence in Jörg. :-) Lets's take that for granted, so all you have to do is placing your macro into the right place inside the package where the Scripting Component can find it. I think the links in the quote should show you the ropes. Now you can run your Python macros from the Run macro dialog or bind them to document events or buttons, put them into toolbars etc. like you can do with Basic Macros. Your Python macro can be plain Python code only and/or it can use the PyUNO bridge to access the OOo API (but I assume the latter is not what you want because it is not portable to other OD based applications as long as they don't support the particular API). Of course ATM there is no other application that can work with your macros, even if you don't make use of our API in them. Wether this solution fits to your needs is something you can only judge by sourself. 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: [discuss] OO.o Macros with Python interpreter?
Daniel Carrera wrote: I very much doubt that this is possible. A macro always uses the OOo API, and this API has no connection with OpenDocument. You can write a Python macro that doesn't use the OOo API, you can even write OOo Basic macros that don't use the API, only the Basic Runtime functions. Of course these macros don't do anything with the document. 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: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: A macro is a small program written in some _language_. It is NOT the code _and_ its interpreter. The latter, yes, is definitely not portable. But a large part of the language is also not portable, the API based part. Of course you can write macros without using this, but then these macros can't do anything on the document, only external work like copying/deleting/moving file, starting tools etc. This is what I'm thinking about: 1) Python interface for opendocument, ie set of function definitions that read/write odt files and their elements That sounds easier than it is. The best way to achieve that would be using XML based APIs of the document (like the SAX API) because they make use of the standardized format. Unfortunately they are much too complicated for the average end user. So another API needs to be provided, but this means: it has to be standardized and implemented. And there is still no guarantee that macros created in OOo will use only this standardized API because we still will have our current API (because we guarantee that macros written today also will run in the future), so users can (and will) use it. Before I forget: if this does make sense, why not add it to the list of google summer of code OO.o projects? Just in case somebody felt like doing it? That wouldn't fit. The Google projects last for 3 months, a new API more fits to 3 years. ;-) 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: [discuss] GetStorage, name: No Content!
On Tuesday 07 June 2005 16:33, Carl Shewmaker wrote: Following weekend thunderstorm had problems with lan and accessing internet, since mostly resolved. But when I try to open OpenOffice.org 1.1.4 I get an error message, OpenOffice.org cannot be started due to an error in accessing the OpenOffice .org configuration data. Please contact your system administrator. The following internal error has occurred: GetStorage, name: No Content! Unfortunately, I am the system administrator, now lost, lone and forlorn. Repair did not work. Have a look at : http://oooauthors.org/FAQs/General/FaqEntry.20041007a/view -- CPH : openoffice.org contributor Maybe your question has been answered already? http://user-faq.openoffice.org/#FAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] Why Microsoft Passed on OpenDoc XML
Stephen O'Grady of Redmonk, has an excellent commentary about MS XML and the OASIS OpenDocument XML. He quotes Erwin Tenhumberg http://blogs.sun.com/roller/page/dancer/20050601#microsoft_opens_office_file_formats to make his case. It's short but well worth reading. Especially since the blog was picked up by ZDnet, and further commented on by Bob Sutor of IBM. O'Grady Tecosystem: * **Microsoft Office Open XML Formats: We Already Got One* http://www.redmonk.com/sogrady/archives/000732.html ZDnet: *** Office 12: Why Microsoft passed on OpenDocument XML format *http://blogs.zdnet.com/Research/?p=202part=rsstag=feedsubj=zdblog* * Bob Sutor: ***Open standards, open source, open minds, open opportunities* http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=384
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: Eh eh... This is the same simplification as OpenDocument = OO.o. It would be more exact to say that the *interpreter* of a macro must be written for the application that calls it (OO.o or whatever) and today the only macros found in pre-OpenDocument files (.sxw, .sxc) are written in a language that was designed only for *StarOffice*, not for its file *format*. See my other reply. No, an interpreter will never be created for a format or even a particular API, theoretically it can work with any API you provide to it. I'm not sure if you understand the nature of a programming language for an application. The interpreter is only a very small part of it, you also need an inspection component and a language agnostic component technology that mediates between objects. Additionally you need an API that the inspection component can read, but this API basically is exchangeable. In OOo the basic interpreter takes a given object that is based on the UNO component technology, uses the so called introspection service to find the methods and properties it has and dynamically learns them. In the same way VBA takes objects based on the COM component technology and inspects them. All the found methods and properties can be used as object members in your macro and make them look as if they are part of the language. This way the macro language evolves automatically by adding new objects to your application or extending the function or property set of existing ones *without writing any line of code in your interpreter*. As an example, you have only one VBA interpreter, but it is able to execute macros for Calc as well as for Word, but you can also instantiate other COM objects (even OOo on Windows!) and directly use their COM based API in your VBA macro. The OOo Basic interpreter offers the same flexibility with all UNO based objects. As an example, adding the Base component in OOo2.0 gave you many grub for writing macros, but not a single line in OOo Basic had to be changed for this. In an extrem manifestation of this flexibility you can replace the current OOo API by something completely different and you can work with this new API without any change in your interpreter as long as you don't replace the introspection component and its API and you use the same component technology (Middleware). Of course an extreme API exchange like this is neither likely (because it's too much work) nor possible (because it's forbidden by our self-constraints concerning API compatibility), but as a thought experiment it can show you how things work. So creating a compatible interpreter for lets say KOffice will be only the very first step to macro interoperability. By using Python (as you correctly stated) you could even save this first step if you provided a binding from Python to your component technology (like OOo has in PyUNO). And this component technology is the key to everything. If you want to be future-proof and keep it open for additional macro languages in the future, your component technology should be language agnostic by supporting the language binding concept (as COM and UNO do), but at least it must be usable from your API implementation language (like C++ in KOffice or OOo) and your scripting language. A quick look to KDE.org it looks as KOffice has something like that, but somebody in the know should confirm. Of course this is only for KDE, Gnome has another component technology. I'm not an expert for this. If this was all in place, *then* you could start defining and standardizing an API and then implement it using the component technology. This implementation can wrap the current objects of the applications or in future times even replace them or at least make up the new parts. 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: [discuss] firewall; browse http:// webpages (skip login masks) then edit html
daniel heiserer wrote: I want to use html data (http:// URL) which is behind a login mask. With ordinary webpages I could paste an URL derived from mozilla browsing into the openoffice URL. then I could either edit the page and save it on my disk, export it to pdf or copy and paste data (e.g. tables (from home banking etc.)) to a spreadsheet. Unfortunately this is not possible if the html page is behind a login. Inserting the link one ends up in the login mask, which is now editable. Does that mean the login page doesn't work because the document is opened for editing? Does it work if you switch it into the read only mode? 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: [discuss] Re: OO.o Macros with Python interpreter?
Daniel Carrera wrote: For once in my life, I will defend Microsoft. Yes, you new employer. :-) I'm sorry Marco, but no. Using different APIs between Word and Front Page does not at all help Microsoft achieve lock-in. And to some extent makes it harder. But the simple fact is that they are different applications. Yes, it's not necessarily an intended lock-in if you use non-standardized APIs. It can be because it's impossible to treat two apps with the same API or just because until now nobody thought about it. I honestly believe that if something like that happened, it would *kill* OpenDocument simply because it would be next to impossible to support by anyone. This wouldn't be the first time that an attempt at standarization gets killed because a committee decides to add eccessive complexity. I don't know it that will happen. I don't see OpenDocument as the body that should work on an API standardization. A proposal like this shows that the idea of OpenDocument is not understood (IMHO). This format goes far beyond applications, simply spoken it's a medium to store data. Remember that many members of the OASIS TC had a completely different idea about what OpenDocument will be for them, and the agreed standard is the result of the least common denominator of all the ideas (that sounds worse than it is!). Adding macros to it of course will leave the common platform. I'm sure Gary Edwards (who was seen on this list lately) could give a useful comment here as a member of the OASIS TC. Macros are always bound to an application, they work on models how the application interpretes the file format. Even if you standardize this interpretation, that's beyond the scope of the format itself. But without further investigation I wouldn't preclude the possibility of a standardization to at least a small extent, but that should be seen separately to the OpenDocument effort. 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: [discuss] OO.o Macros with Python interpreter?
Mathias Bauer wrote: You can write a Python macro that doesn't use the OOo API, you can even write OOo Basic macros that don't use the API, only the Basic Runtime functions. Of course these macros don't do anything with the document. Okay, the point of a macro is to do something with some document or with the application. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: OO.o Macros with Python interpreter?
Ian Laurenson wrote: 2. For changing the document, an approach might be, for each call to the common scripting routine: * The file gets saved (temporary file?) * The file location gets passed to the script * The script manipulates the file contents, using common library routines (I am aware of such routines in Perl) * I think that the cursor location is included as part of the open document standard, so this too could be changed by the script * The revised file is saved on exit * Reload the file How would you implement the virtual keyboard macro with that approach? Or the reveal codes macro? I can see how your suggestion could cover a subset of macros though (e.g. Danny's drawing tools). And having a stand-alone Python library for manipulating OD files is a great idea. Maybe we'll just have to accept that a stand-alone library is as good as one can get. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] 2.0 Beta version Calc minor problem
Sorry for the delay in responding. This was noticed on the version 2.0 Beta in the Calc program. Mike - Original Message - From: Peter Kupfer OOo [EMAIL PROTECTED] To: discuss@openoffice.org Cc: [EMAIL PROTECTED] Sent: Friday, June 03, 2005 11:35 AM Subject: Re: [discuss] 2.0 Beta version Calc minor problem Michael Langenes wrote: To anyone who is involved in programming, I was editing a spreadsheet in Calc and went to 'Save As' to rename the file I was working on. Everything was in English like it was supposed to be for the English version I am using except two check boxes under the new filename box. The descriptions of the two check boxes were in German. Not knowing German, I didn't have any idea what they were for. Just thought someone might want to know if they haven't found it out already. As for a general comment, THIS OFFICE SUITE ROCKS! To all the programmers involved, you people are terrific! Thanks for a great software package! Mike L. Lake Mary, FL Which version where you using? -- Peter Kupfer -- Using OOo since 'OO4 -- [EMAIL PROTECTED] Want to help? http://www.oooauthors.org For OOo tips: http://openoffice.peschtra.com/tips/ooo_tips_tricks.html To order OOo: http://openoffice.peschtra.com/distro/ooo_distro.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] DRM in MS Office, was:sharing OOo among lawyers
On Wed, Apr 20, 2005 10:49:23 AM -0400, Lars D. Noodén ([EMAIL PROTECTED]) wrote: MSO XP on MS-Windows XP SP2 or MSO 2003 (which has DRM baked in) has the capability that every time a document is opened, created, edited, printed, copied, saved, or mailed that action can be tracked. Depending on the settings, the tracking either occurs at the MS-Pasport site, or on another designated MS-Server. Note that 2003, XP SP1, and 2000 SP3 grant third party access to the contents of the server (check the technical description or just read the license that came with) I'm sure it's not a good thing to allow third parties to keep up on internal communications Any URLs (possibly from Microsoft) where this is officially said and explained in more detail? TIA, Marco -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Sometimes when you fill a vacuum, it still sucks. -- Bill Joy, founder of Sun Microsystems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] Can not copy styles from a file to a template?
Hello discuss, In OOo 2.0, I can not copy a style from my currently openned document to my default template, in template manager. Why? Thanks! Best regards, MRZ2003 [EMAIL PROTECTED] 2005-06-08 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
