This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

Macros an obstacle to office suite compatibility

By Marco Fioretti on September 17, 2005 (8:00:00 AM)

Share    Print    Comments   

Macros are important in an office suite. They are the only realistic way for non-programmers to create interactive documents quickly or add special features to the application. While many open source office suites are embracing OpenDocument as a common file format, the lack of common macro language support will prevent meaningful file interchange.

In OpenOffice.org (OOo), the most popular free software office suite, macros are usually written in the StarBasic language. Today, however, StarBasic macros have a couple of problems. The first is the one I touched on in Fixing the problems with OpenOffice.org extensions: at least on GNU/Linux systems, macros should not be distributed inside self-executing OOo files because they don't integrate with a distribution's native package management.

The second issue is more general and, at least in the long term, more of a hassle for free software users. One of the features highlighted in the OOo 2.0 release is the use of the OpenDocument format as the default file format. The OpenDocument format is being adopted by StarOffice and KOffice as well, is recommended by the European Commission, and currently on its way to becoming an ISO standard.

OpenDocument's adoption as a native format by OOo, KOffice, and other office suites is a wonderful thing -- but it also creates a problem as far as macros are concerned. At some point OOo and KOffice users will exchange OpenDocument files that contain OOo macros that won't work in KOffice programs. Because the programs share a common file format, users will expect that the macros will work in either program. After all, the macros are part of the file, and users are told that one of the benefits to OOo and KOffice is that they utilize a common format. But there is no macro language specification in the OpenDocument specification, and everyone I've talked to agrees that there shouldn't be.

I first realized this would be a problem more than a year ago, and immediately asked what was being done to address the issue. Back then, the average answer was "hmm, you're right, we never thought of that, but nothing will probably happen right now." Today, with OpenDocument standardized and OOo 2.0 coming Real Soon Now, a solution is still missing.

What is a macro anyway?

From the end user point of view, macros today are used in OOo in two fundamental ways: they either extend the functionality of the whole program (on all the files it operates) or that of one specific document. This is similar to what happens with Web browsers. There are Firefox extensions, and there are JavaScript applets that run in Firefox as well as other browsers. The first are written for one specific browser, the second for a specific Web page. Users expect Web browsers to support JavaScript and HTML, but they don't expect Internet Explorer or Opera to support Firefox's extensions.

Most OOo macros that extend program functionality would be unneeded in other office suites, because other programs have their own ways of doing things. This category includes dictionaries, spelling checkers, word count, finding text in multiple files, and so on.

The other kind of macros are those which, for example, add buttons inside documents to check user input. Users will expect this kind of stuff to travel with the document, and be there no matter what program you open it with. A real-world example of this category would be an e-learning course based on OpenDocument questionnaires. Interactive documents of this kind should be fully usable across all OpenDocument-compliant programs.

StarBasic everywhere?

StarBasic is already established in StarOffice/OOo, has corporate backing today, and courses and books about it are available.

Generally speaking, OOo macros either use the OOo API or UNO (Universal Network Objects) dispatch calls. The first method gives developers full control and, being defined in Interface Description Language (IDL), would be accessible from a wide range of languages. A BASIC runtime should also be provided. The UNO method should be easier to implement after OOo 2.0 because a separate URE (UNO Runtime Environment) will be available.

From the outside, it could even seem that the simplest solution could be for KOffice to simply integrate the whole StarBasic interpreter from OOo, instead of writing a whole new one. However, even if there were no license problems, this would work only if the StarBasic interpreter code was modular enough to be easily ported, and if the developers committed to keep it that way.

To sum it all up, any of these solutions would require a lot of work.

In addition to this, at the API level the distinction between "program" and "document" macros is much more difficult to define and implement. Supporting only the latter would still require more or less the whole API. Nobody, starting from OOo developers, seriously recommends it.

What is the next step?

The most realistic solution seems to be to start preparing for a new alternative. Some KOffice developers, for example, have thought about integrating a Python interpreter. On the other hand, OOo 2.0 should support another easy way to implement simple logic (that is, our "document" macros) without any programming: the W3C XForms standard, which is not tied to any specific program. Why not go straight for XForms, and forget traditional macros altogether?

In the meantime, don't put too much emphasis on those StarBasic skills in your resume.

Marco Fioretti is the author of The Family Guide to Digital Freedom and contributes regularly to Linux.com and other IT magazines.

Share    Print    Comments   

Comments

on Macros an obstacle to office suite compatibility

Note: Comments are owned by the poster. We are not responsible for their content.

"lack of common macro language"

Posted by: Anonymous Coward on September 17, 2005 07:22 PM
As much as you're right with some of your points, lack of a unified macro language is hardly what hinders wider adoption of OpenOffice.org and the like (koffice, abiword, etc.). Why ? Because believe it or not, very very very much more users use Office applications without ever touching a macro.

As for corporate needs, in their case there are two things to be considered: 1) if someone would give them perfect macro covnersion tools, they probably wouldn't use it our of fear, 2) after the conversion they would be very slow to learn a new macro language, just like average people stick to specific apps and OSes out of habit.

#

Slightly beside the point

Posted by: Morten Juhl Johansen on September 17, 2005 08:08 PM
While this comment is true, it does not reflect on the issue that, although the Open Document Standard > <a href="http://en.wikipedia.org/wiki/Open_Document" title="wikipedia.org">http://en.wikipedia.org/wiki/Open_Document</a wikipedia.org> has been developed and approved, even with a functional template format, it has not addressed the macro issue. And this is unfortunate, since the open format and, as an effect, the platform-independence, is lost, if a program embeds its own macros in a file for distribution.
This article is not a question of hindering adoption of open source products - indeed, the same problem would be encountered by users of MS-Office, WordPerfect or whichever application would use the<nobr> <wbr></nobr>.odt format.
While the home user may not use macros, certain tasks in the corporate world rely on this functionality - in my experience, especially in spreadsheets.

#

From the author:"lack of common macro language"

Posted by: Anonymous Coward on September 18, 2005 01:22 AM
lack of a unified macro language is hardly what hinders wider adoption of OpenOffice.org and the like (koffice, abiword, etc.)... Because<nobr> <wbr></nobr>...[most users live] without ever touching a macro.


First of all, what is important is the worldwide adoption of OpenDocument. Not of this or that specific program. The whole point is exactly to
give end users the freedom to choose and change
their software.

In the second place, your remark is as true as (alas...) irrelevant from both the practical and PR point of view. If there is no macro compatibility OpenDocument will not even enter,in many cases, the "complete, mission-critical solutions" lists
in brochures and bids for government contracts.
I'm not saying I agree but, brainless as it may be, it's true.


Apart from that, it would be bad PR to not inform users in advance (even if 99.99% of them won't use macros) that macros won't be portable, and it would backfire.

As for corporate needs, in their case there are two things to be considered

I'm not sure things would be as you say, but even in that case, it remains the fact that a macro solution would be considered by potential corporate users. One without them wouldn't even enter the door...


Thanks for your time,


Marco

#

How many use Macros in Word and Excel?

Posted by: Prototerm on September 17, 2005 09:41 PM
I've been using Microsoft Word and Excel in a corporate environment for over 15 years on both Windows and Mac, and the only Macros I've come across have all been malware. I have yet to see a single legitimate macro used, never mind one that is so vital it would, by itself, prevent a switch to Open Office. IMO, there are other issues preventing Open Office from being adopted company-wide.

I also question whether macros can be easily written by non-programmers, since it involves writing Visual Basic code (at least in Word and Excel). As a programmer, if I'm going to automate something in Word or Excel, I'm going to write a program (probably in Delphi or C#), and use COM to operate the program. It's faster, and more powerful.

#

Re:How many use Macros in Word and Excel?

Posted by: Anonymous Coward on September 17, 2005 11:28 PM
I've used MS Excel for 15 years in a corporate environment and (ugh) Word for 5. We have macros to automatically fill in addresses, job names, and the like. I could, and usually do, do without those. However, Excel would lose a siginificant amount of its usefulness for me if I could not write macro functions for my engineering calculations. I've stored these in add-ins.

I use OOo at home, and find it pretty easy to port from VB to StarBasic, if I only have to do it once. But it becomes a pain if I try to carry documents back and forth, because OOo often detects the macro functions and prepends a "NAME!" error to the function name in the cell, even though I've added the same function to OOo.

The author stated "Most OOo macros that extend program functionality would be unneeded in other office suites, because other programs have their own ways of doing things." However, I don't think he's thinking of the way I use macros, to extend the functinoality of the spreadsheet programs by adding functions that I would need in any of the office suites I might use.

So, I think macros and portability of them are important.

I've also written spreadsheet macros that help me add and manipulate data from different spreadsheets and from AutoCAD. Sure there are other "better" ways of doing that, but I'm not a programmer, and using the VB or StarBasic provided within the program is easier and much faster. From a practical standpoint, good enough often proves better than best.

#

From the author

Posted by: Anonymous Coward on September 18, 2005 01:07 AM
The author stated "Most OOo macros that extend program functionality would be unneeded in other office suites, because other programs have their own ways of doing things." However, I don't think he's thinking of the way I use macros


Yes, I am (partly). What you call "to extend the functionality of the spreadsheets... in any of the office suites I might use" is what I called "in-document" or Javascript-like macros. Of course, the distinction can be blurry in some cases, and all kind of macros can be abused...


Thanks for your comments,

Marco

#

Re:How many use Macros in Word and Excel?

Posted by: dukeinlondon on September 18, 2005 05:28 AM
You've never worked in a bank then. There are hundreds of macros, written by a bewildering variety of people. And most are completely outside of IT's radar.

Not everyone does it though and that's why a migration is virtually impossible and in my work environment that would make displacing excel just not even worth considering.

It's a lot less true of Word, and writer would stand a much better chance. There are not so many documents out there that are so complex that they can't be opened by Writer.

#

macro's vs documents

Posted by: cono on September 18, 2005 02:31 AM
I think macro's are mostly used within one environment/office. Results of the hard work - i.e. documents/data - are exchanged, thanks to OpenDocument.

#

I've Been Saying For Years That Macros Are Bad

Posted by: Anonymous Coward on September 18, 2005 03:34 AM
They should only be used for very limited, short-term purposes.

Offices or persons who build up entire "applications" using macros - and contrary to some posters, this is very common in both Excel and Word - are just houses built on sand.

This is like building mission-critical apps in some obscure unsupported programming language developed by one guy or one company that subsequently goes out of business (which IS what will happen to Microsoft sooner or later.)

Mission-critical company applications should only be developed in standards-based languages and development environments. That means any of the well-known current languages - C, C++, Java, JavaScript, Perl, Python, Ruby, shells, etc.

Macros should be limited to automating basic repetitive interactive operations done within the context of the specific office suite function.

#

And -

Posted by: Morten Juhl Johansen on September 18, 2005 04:13 AM
While I do not entirely disagree, this does not really address the problem

#

You probably can't explain this to the OOO devs

Posted by: Anonymous Coward on September 18, 2005 10:45 AM
From the outside, it could even seem that the simplest solution could be for KOffice to simply integrate the whole StarBasic interpreter from OOo, instead of writing a whole new one. However, even if there were no license problems, this would work only if the StarBasic interpreter code was modular enough to be easily ported, and if the developers committed to keep it that way.

I argued with dcarrea last month about the need for OOO to be more modular. The response every time was along the lines of "it makes no sense for Writer and Calc and the rest to be separate apps!" That wasn't what I was talking about then and it isn't what you are talking about now. To the current OOO dev team OOO is an (capital letters please) Application that implements an Office Suite.

But yes, this is the sort of thing I was talking about. OOO needs to be able to function as a set of components that can be used by unrelated applications in perhaps unexpected ways. MS Office can be used this way and is in fact treated as an API by a entire host of developers. Even if OOO can't function as a replacement API for such applications, equivalent things should be possible. Insurance rating and tax applications are two such uses. There are a multitude of others.

And no, I don't mean load up the entire suite and then have the app be an awkward window in a Calc spreadsheet. I mean being able to do things like fire up applications that look like native KDE or Gnome apps that call into OOO libraries.

This incidentally would solve the "KOffice confronted with an OOO macro" problem since KOffice could use OOO as a backend to execute the macro and display it's output seamlessly. Look at the way Xine is separated into library and ui components that other apps can transparently use. THAT is what I mean by modularizing OOO.

#

Re:You probably can't explain this to the OOO devs

Posted by: Anonymous Coward on September 20, 2005 01:35 AM
Sounds right to me. I use Office like that sometimes, sometimes I just use Excel as a front-end for data collection and display, sometimes I do full-scale development in Access. VBA is easy to write, the IDE is very pleasant to work in, debugging is fine (much nicer than what VMS was offering in the 90's) -- why move, except for those nagging ethical imperitives<nobr> <wbr></nobr>.... can't move until my employer won't get hurt by lost time and productivity. I need to be able to translate or wrap the legacy workbooks and databases before I can even start to work for a move to OOO, although there's serious executive interest already for moving away from MS.

#

Companies where I have worked do NOT use macros

Posted by: Anonymous Coward on September 21, 2005 08:55 PM
None of the companies, where I have worked in the last few years, used macros in MS Office.

In fact, a couple of those companies (one of them being a Top500 company) had officially FORBIDDEN the use of macros in office documents.

Those companies are smart, because they have avoided virus problems, compatibility problems (even between different versions of MS Office), and lock-in problems.

#

Re:Companies where I have worked do NOT use macros

Posted by: Anonymous Coward on September 21, 2005 10:46 PM
Why oh why do people say "top500" or "top100" etc instead of naming the bloody company?

#

Re:Companies where I have worked do NOT use macros

Posted by: Anonymous Coward on September 22, 2005 01:12 AM
> Why oh why do people say "top500" or "top100" etc instead of naming the bloody company?

A. Confidentiality agreements.

B. Why would we want to help Microsoft, by telling them which companies are slipping out of their grasp?

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya