Posted
by
michaelon Saturday September 01, 2001 @04:20PM
from the my-money-is-on-koffice dept.

Cowculator writes: "Sun Microsystems will release the beta version of StarOffice 6.0 in October, with the development version already available. This ZDNet article has some more details, including a link to the development version..." Other submitters sent in notes about Gobe Productive and Hancom Office 2.0, not to mention KOffice and the Gnome office applications. As far as I know all of these are lacking the single most important thing, a robust and complete set of import filters for Word, Wordperfect, Excel, Powerpoint, etc.

Word processors dating back to the DOS days can read Rich Text Format. If you're sending it to a windows newbie who panicks when it doesn't say ".doc", tell him to open it anyway -- word will understand it.

HTML + CSS support all of the above, including (AFAICT) everything static that MS-Word can do. Doesn't support StarWriter's greater ability with tables, though, or passing spreadsheet formulae, or MS-Office's reknowned virus SDK (AKA macros). StarWriter does export actual believable XML, which is a start, and infinitely better than the botch that MS-Office adds to its HTML exports.

Of course, if people weren't so much in love with pointless `futzing' to get the layout `right,' we could use one of the Unix press standards liky LyX that have been around and stable for decades... I can't begin to imagine the horror which a Word plugin to export this would have to go through...

I think the ultimate solution is World Domination. When MS-Office is no longer relevant, we can forget about supporting it as a special format. Until then, there must be some emulation.

Actually, the last few versions of the MS RTF Spec do support tables and objects, but each version supports them a little differently. RTF is almost as much of a moving target as the.DOC file format itself. To find a "portable subset" of RTF (portable across versions of Word as well as alternative word processors) you woud need to drop back to Word 95 or so and reverse-engineer (with the spec in hand of course) from there. You also have to watch out as new versions of Word introduce new keywords to do old things (like numbered lists, Word 2000).

Bzzt! Thanks for playing. I see someone else has marked your comment as flamebait, but I think you're simply misinformed. The reality is that RTF is a Microsoft-created format and, at least when I looked at the RTF specs for Word 6, Word 95 and Word 97, tracked Word feature for feature save for embedded objects (although I believe it may have supported specifying links to external files).

Let's face it. The main reason programs "need" import/export filters for Word documents is because of user assumption--i.e., that everyone can read Word documents. They shouldn't need anything more than the openly-documented RTF. In practice, you'd better have a pretty good import filter for Word's native format--but in practice you really only need to be able to export RTF documents.

Incidentally, out of the 'alternative' office apps mentioned in this little article blurb, Gobe Productive 2.0 had the least trouble dealing with Word documents for me--although others have reported less success. The Linux (and Windows) versions of Productive will be of version 3.0.

Remember when Office 97 came out? There was a big scandal because MS promised that it read/wrote MS Office 95 formats perfectly.

Truth was Word 97's "Word 95 Export" was nothing more than an RTF export. Office SR1 fixed this. It caused a great deal of headaches in the company I worked for at the time. Quite a bit of formatting was lost when the people with Office 97 saved Office 95 docs.

Well, why should they have to learn a new program just to read your document? Why not let them use their favorite word processor/editor/browser/news reader/Napster client to read your data? If you write in a format that's universally understood, there is no problem.

I think it's important to state that both important *and* exporting are as important as each other. Being able to send word-compable documents to business colleagues is every bit as important as viewing incoming ones properly.

As far as MS changing the formats to force incompatability goes (which they will undoubtedly continue to do, as per normal course of business), the one thing the industry has working in their advantage, is that they end up creating incompatability for their earlier products, as well. That's why we see as "Save-as Word95/97" option in Office. They create their own incompatabilities in the process. That works to the advantage of the industry, against this monopolistic behaviour.

Anytime someone saves something in the latest office format, they break Word 95, 97, as much as they'd break StarOffice. And StarOffice has historically tracked the import formats closely enough (at least for Word) to keep up with the previous gen of office products. If they fall behind a couple of revs, the race will be over.

I should also point out that the link to the "StarOffice source code" is a link to a very old verison of OpenOffice.org. Those seeking StarOffice source code should go here to get the latest build [openoffice.org].

I've acually used StarOffice 5.2 (for Linux) to read a large MS-Word 2000 file and write a Word 97 file that didn't crash MS-Word 97 (which was something that MS-Word 2000 couldn't do with this file, even in (and see below) RTF). So you could say that StarOffice exports Office files better than MS Office itself does.

I'm not being flip just curious, At work i just downloaded and installed 5.2 because I was curious how it would live in a microsoft 95 environment.

Don't laugh, I have to use the same software the rest of the company uses. We don't suffer from version itus, but lately it has become more of a pain to deal with newer file formats that peolple tend to send documents in. FWIW, all the machines run word version 7? on Windows 95.

So to test the conversion capabilities in a rather unofficial and quick manner I created a.doc file and.xls under Microsoft Office XP. The files were saved in several formats from XP native.doc and.xls and then backwords in several of the preceding versions format.

Star Office opened every file with out a problem. It then was able to save the file in a format that our existing MS office products could handle.

I havn't used the product enough to tell if it can replace our existing installed base but I got the go-ahead for a short term usability test. ie. I get to use it as my primary Office Suite for the next month or so in an evaluation mode..

If it works out we will have saved approx 40x300=$12,000 in upgrade fees.

There seems to be a lot of focus on import/export filters, which is an important feature, but not the make/break feature. Other than the few gorilla anti-MS users out there, most corporations establish standards and force ppl to use a particular software. With few exceptions, most documents any office drone has to work with come from in-house.

XML is little use if it's along the lines of
<msword2003>
<encodedbody>
<CDATA[[
klgfwe;lgn;4wp39 orweo;info;we23oih23hgolwerngfwoe;rlig
ew;rokwe;lrkjnwelk;rj
wperitjwelrkt
]]>
</encodebody>
<msword2003>

Which is perfectly valid XML. XML is not a magic panacea that fixes all ills. It's way, way overrated - you still need a description of what the hell the tags actually mean. (And, with MS, usually another 3rd party document describing the differences between what they say they mean and what they actually mean)

(And XML is just an annoyingly verbose form of certain Lisp S-Expressions, anyway. )

No, XML is not a complete definition of a format by any means, and just because it's XML doesn't make it immediately compatible or even legible. But reverse engineering in XML is infinitely easier than reverse engineering something encoding a propietary format.

I'd think that the whole point of an exercise like this was not to ape all of Microsoft's features but to produce a compatible alternative. Without file compatibility these remain purely academic exercises. Besides, haven't all versions of Office since 2000 used an XML derivative for file storage?

...is StarOffice, in my opinion. If these guys can prevent MS from having the only application suite that can properly handle their monopoly-induced standard file formats, then there is *choice* in the industry. If StarOffice fails, then it's MSWord, MSExcel, and PowerPoint, for the forseeable future that will dominate business communications.

I think StarOffice got off to a wonderful start. I'm very concerned about their progress. The next major version will really be a turning point in the industry one way or the other. If it's solid, and it rocks, with great compatability, then there is a great alternative to office. If it's buggy, or doesn't work well with office formats (especially Excel, where it's the weakest), then MS will win. And I'm going off to live on a deserted south pacific island.

Sigh... If I had to bet, it's depressing where I'd probably put my money... Sun's dropped the ball a few times lately.

Tip to the folks working on it: cool object oriented design is neat, but it's usability, stability, and compatability that will make StarOffice a success. Don't try to do things beyond MS Office, just match it on all fronts! Anything else is an esoteric waste of time.

Tip to the folks working on it: cool object oriented design is neat, but it's usability, stability, and compatability that will make StarOffice a success. Don't try to do things beyond MS Office, just match it on all fronts! Anything else is an esoteric waste of time.

Don't even try to match it on all fronts, IMHO. As much as MS would have it otherwise, most Office users are only using a very small subset of the functionality available.

If you can support bulletproof import/export of simple Word documents, with basic things like the formatting, cross-references, tables and so on working reliably, you've got 99% of the portability problems solved. The big issue is the number of documents that already exist in Word format, which people will continue to need to read/edit in whatever new format they're stored. Most of those documents don't use super-advanced VBA scripts, half a million text boxes and WordArt.

Now, if you can go one better, and fix the terminally annoying bugs in Word -- cross-references not updating properly and woefully broken bullets and numbering spring to mind -- then you've also got a technically superior product that solves real problems that MS Word doesn't. Add in the silly omissions -- genuine three-part headers and footers, as used by many, many business documents, for example -- and you're clearly winning.

Of course, similar arguments apply to other Office applications, particularly Excel and Access. I'm simply highlighting Word because the issues are likely to be more widely understood.

If you can support bulletproof import/export of simple Word documents, with basic things like the formatting, cross-references, tables and so on working reliably, you've got 99% of the portability problems solved.

Did you say tables? Do you have the slightnest notion how hard it is to implement table support for one format? And transparent dual-format support is at least an order of magnitude harder.

Yes, I said tables. However hard they are to support, they are basic to many users, and not supporting them is not an acceptable solution.

I'm unconvinced by your arguments about how hard they are to support, though. What is so difficult? If your native format supports arrayed data and things like a range of options for borders and the possibility of header rows -- all routine things in pretty much all serious table implementations in word processors -- then reading from another file format shouldn't be that difficult. Why the big challenge? Why the "order of magnitude" difference when you need to support more than one source format?

"As much as MS would have it otherwise, most Office users are only using a very small subset of the functionality available."

Joel Spolksy (former MS employee) [joelonsoftware.com] has a great article on why this doesn't make sense - everyone who's tried to do this has failed because even if most poeple use 5% of the features they all use a different 5%, so if you do that you'll get to about 5% of the users.

but don't you see? you just proved the joe-sixpack-only-needs-M$ arguement.......therein lies the challange for Linux in the corporate world... What is the compelling "feature" that you will give the end user that M$ has not... pleeeeze don't give me the "stability" rant...???

Um... What's wrong with that argument? The alternatives do need a compelling reason for corporates to change. They aren't going to change just because the alternative comes from a group of enthusiastic people. They're going to change because you give them a reason.

Now, here's the kicker. That reason is generally reckoned to be a 10-fold increase in usefulness (be it extra functionality, improved performance, better usability or whatever) or a 10-fold decrease in cost (note that this includes all the support costs, any retraining necessary, and so on, as well as the "package price"). The alternative office suites in question potentially offer both of these things, but they have to make their case to "da management", just as any other package would.

This is actually where MS may be shooting themselves in the foot. They, too, must convince management that Office XP is worth the upgrade. Right about now, they're manifestly failing to do so; unlike the previous "vapour" upgrades, I don't think the IT world is falling for it this time. Certainly my employer isn't, nor are those of any of my friends. The name "Microsoft" on the box is no longer a sufficient reason to upgrade, in the face of licensing conditions that amount to writing a blank cheque and a widely reported lack of much improvement in the actual products (again, the MS classic of introducing a "new look" is no longer enough).

For the first time in several years, I think companies are regarding Microsoft upgrades with justified scepticism. As they consider the alternatives, or indeed whether they actually need to upgrade at all, some will switch to Linux-based solutions if they're up to the job. The question is, are they?

The magic incantation, my friend, is price. Right now Joe SixPack probably isn't paying for his copy of Word, but the new versions of MS Office aren't going to allow for casual piracy. That leaves Joe SixPack with a choice. Stick with what he has forever (not likely), pay more for a copy of MS Office than he paid for his entire computer (my last computer cost $400 and they almost certainly are going to get even more inexpensive), or take a look at Sun's free Star Office. I wouldn't be surprised if OEMs started getting serious about shipping StarOffice on their machines by default. After all, it is probably terribly frustrating to work so hard building machines only to see the software folks make all of the profit. StarOffice is an easy way to differentiate low end boxes from the competition, and the price is definitely right.

Most people are going to find that Star Office is good enough for their needs, even if they share files with MS Office users, and it is a lot less expensive than MS Office. Contrary to popular belief it wasn't Linux's stability or security that has driven it's acceptance in the enterprise, it has been Linux's price. StarOffice is likewise prepped for much wider use.

Funny - I've pulled the plug on my Win98 machine more than once, and Word was able to recover my files from its autobackup system. Just reload Word and it says " (RECOVERED)" or something similar to that (can't remember specifics). Win98 and Office 97. I bet O2000 and OXP have this as well.

Dude, StarOffice sucks. There is no other way to say it. Why does my Office Suite need it's own start button and desktop? WTF were they thinking?

Apparently, it doesn't use the standard Windows Open/Save dialogs, so you get some confusing thing instead. There is no file tree! If I'm six directories deep and I want to save something on the desktop, I have to click "up", "up", "up" six times. If I want to save to a network drive, I have to go up to the desktop, then my computer, then the network drive. Why don't they use the regular Windows popdown which shows all your network drives, etc?

I could go on and on about all the shit that's wrong with it. I wish they would just hire ONE interface designer to work with the 100 programmers. PLEASE. This is not hard, this is stuff anyone can observe in the first 5 minutes of using it.

According to this article, the integrated desktop and probably the start button will be gone in version 6.0.
quote
OpenOffice, and its predecessor StarOffice, are integrated office packages and include a word processor, web browser, and spreadsheet tools. In fact, StarOffice 5.2 contained just about everything a desktop user could need, including an integrated desktop. But with the adoption of desktop environments such as GNOME and KDE, future releases of StarOffice and OpenOffice will no longer carry the integrated desktop.

...is StarOffice, in my opinion. If these guys can prevent MS from having the only application suite that can properly handle their monopoly-induced standard file formats, then there is *choice* in the industry. If StarOffice fails, then it's MSWord, MSExcel, and PowerPoint, for the forseeable future that will dominate business communications.

I don't know about StarOffice being the only worthy competitor here. Particularly when you argue, correctly, that we need more choice in the industry. But that's quibbling.

...it's usability, stability, and compatability that will make a success.

Right. When people claim Microsoft's dominance in the industry is due to their OS monopoly, I think they are missing an important point. People buy Microsoft to run applications. Microsoft applications. Until competitors can read/write Microsoft binary files without problems, nothing will change.

Therefore, the proper remedy (IMHO) to impose on Microsoft, as punishment for their abuse of monopoly power, is to make it easier for competitors to compete with Microsoft on their own turf. Microsoft should be compelled to openly publish the specifications for all binary data formats they use. Publishing API's is insufficient. Worse, misguided. Using MS API's implies, of course, that you are using Microsoft products. Some punishment. No, the remedy must make it possible for competitors to avoid the enormous time and expense, not to mention possible legal entanglements, of reverse engineering Microsoft binary data.

Then instead of asking "How well does StarOffice (et al.) import/export MS files?", we can ask "Does StarOffice provide the features I would like in an Office suite?". That would be progress.

Gobe is greatness.. I wonder how good it will be on linux. If they can make it as good or better than the BeOS version, It will take over as the best linux office suite. I think the BeOS version already beats MS office in almost every category besides userbase...

Complete filters don't do too much good if the program doesn't support all the features. Footnotes, for example, are missing from some of these.

Filters are certainly important, but we won't have truly won the battle for open standards until proprietary closed formats like Office are no longer the de-facto format that everyone expects. I want these programs to stand on their own merit.

Office suites are commodity software that everyone needs, and Open Source offerings in this area are increasingly impressive. So I think there's hope.

It's true that you'll never convince someone to switch away from Word if the feature they need isn't supported. The problem is that

MS can add features indefinitely and let open-source developers play catch-up.

It leads to open-source bloatware. The whole monolithic application thing is a disaster. It would be much better to have functionality like spell checking, etc., split off into separate applications.

The problem with open-source bloatware seems to be even more severe than with closed-source bloatware. Look at how slow Mozilla is compared to IE. (Okay, YMMV, let's not start a flamewar -- that's just what I found recently when I compared performances on my system.) And complexity is the enemy of open-source projects -- it raises the barrier to entry for people who want to contribute.

I also don't know what you do about lusers who send one-page text e-mails as Word attachments. Even if a certain version of Star Office can read Word 98, it'll be broken when Word 2004 comes out. Are the same lusers really going to be clueful enough to realize they need to convert back to Word 98 before they send it?

Probably a better solution is to convince everyone who currently e-mails Word attachments to start e-mailing PDF attachments. It could still be used inappropriately, but at least everyone could read it with open-source software.

Probably a better solution is to convince everyone who currently e-mails Word attachments to start e-mailing PDF attachments. It could still be used inappropriately, but at least everyone could read it with open-source software

Until Adobe adds an incompatible feature to PDF and has people sent to prison for reverse engineering it...

The lack of import filters is regrettable, but hardly surprising - as soon as they do work properly, Microsoft will make bloody sure to change the format again.

The other factor is that even if the word/excel/powerpoint import is working, people act all surprised if their embedded Viso drawings/ autofcad dxfs etc don't work. It's pretty silly to expect them to work too, unless you've got some magical linux version of autocad (come home to unix autocad!) or visio installed. KDE's KParts framework is as capable as OLE on windows (although I wish they hadn't dropped CORBA), but it can't embed applications that don't exist.

Export filters are pretty irrelevant for the majority of word or excel documents -

MS Word will silently load files saved as.html or.rtf anyway - even if you rename the extension to.doc. So the poor lusers don't even know it's not MS word format...

Excel loads CSV fine, even CSV with embedded formulae in standard enough infix notation. Once again, this covers a large number of cases, although it's not as transparent as just renaming a.rtf to.doc , and "pretty graph" style applications need something more powerful.

Powerpoint is more problematic - although I've noticed that the flashier and more advanced the powerpoint presentation, the less likely it is that it's saying anything useful.:-)

The lack of import filters is regrettable, but hardly surprising - as soon as they do work properly, Microsoft will make bloody sure to change the format again.

Bingo. Which presents another opportunity to reiterate an unoriginal idea that I really like. Compel Microsoft to publish specifications for all binary data formats (on disk and on the wire) as punishment for their abuse of monopoly power. This would put the competition on even footing. Instead of the competition wasting time reverse engineering (and contending with the the DMCA), they could compete on the merits (gasp) of their product(s). Please, please, god, make this come true.

Open API's are no substitute. "OK, you win then, we'll open our API's. Shucks." Later, backstage: "He he, they fell for it. Use OUR API's. Of course, to use our API's they'll have to write software for OUR products! Whoo hoo! Dopes!"

It's obviously pretty essential for users to be able to transfer between the office suites in question and MS Office, if the others are to gain any kind of mainstream acceptance. However, most MS Office users don't actually use something like 90% of the functionality. It's the other 10% that's important.

Further, the only really important Microsoft Office applications are Word, Excel and Access. There isn't the same volume of existing data that must be readily accessible for the other applications.

Now, suppose you could get a solid intermediate format covering those basics (something XML-based, perhaps) adopted as some sort of standard by the free software/open source guys, and have all these office suites using it. It then just needs someone to write a single filter for, say, MS Word docs, to convert to and from the intermediate format, and then all the other Office suites can do it.

I can't believe no-one's thought of or attempted this before, but I don't know of any actual examples. Does anyone else? It must be technically possible; at least, if it's not, you haven't got a hope of converting to the format used by any individual free/open source office suite either.

>>Further, the only really important Microsoft Office applications are Word, Excel and Access.

Actually I'd say, for most businesses this is the order: Outlook, Word, Excel, Powerpoint. For more some, (without a decent IT staff) Acess would be after word. Do you wonder why people don't leave outlook after numerous virus attacks? It's that useful, that's why.

Fair point about Outlook. I'm not convinced about Powerpoint, though. I know a lot of people who have Powerpoint installed, but very few who regularly use it, and even fewer who need to keep their presentations for more than a few weeks. In contrast, Word docs and Access databases might be needed going back many years.

Depends on your shop. Where I work, Powerpoint is *everything*. It's a consulting firm which likes to deliver its 6-figure-plus reports to clients in Powerpoint form. They have people who are really good at some Powerpoint design formats, and can get quite a bit onto a page if they want to. Personally, I prefer the linear style of Word with a (very) few pictures, but I'm the exception there.

Outlook, on the other hand, isn't even installed. They use Notes for mail (which is execrable, but safe from viruses) and groupware functions (where it has potential).

For me to jettison 'doze and use Linux would require real two-way filters into and out of PPT, Word and Excel. I haven't found AbiWord to be very good at it. Gnumeric isn't complete either. And even different versions of Powerpoint (which really sucks) aren't compatible with each other; at work, it's all Office 97, and no talk about "upgrades". I suspect that's the most common version nowadays; we exchange a lot of stuff with clients using Office 97 formats.

I think you give people too much credit. They use it because it's the default.

Most people don't even change their home page so how are they going to figure out what other email programs are out there, download/buy it, install it and configure it to download mail from their isp?

And in a business then it's even harder because someone has to go around to each computer and install a new email program and set it up. Then he/she has to teach users how it works. And there are _always_ problems with new software so that is more work...

If Eudora was the default instead of Outlook it would be just as popular.

absolutely noone uses Access in any serious way. It's nasty, buggy and has a really bad habit of corrupting data if you look at it funny. Besides, if you give me an access database, I can have it in a Mysql database and a web frontent thrown together faster than the training to use the new software would be done.
Access, is super trivial to convert to a real Database.. The advantage is that Access is basically primitive and based on 1980's database ideas.

I understand what you're saying, but you miss my point. It's still a format produced by one of the bodies behind one of the office suites. What I was thinking of was a common format, worked out between the various different interested parties, with the intention of supporting the useful common subset of functionality.

just saying "it's XML" doesn't naturally guarantee compatability. It just makes parsing the file. Working out what that means, and translating into the different structure of a foriegn application, is still distinctly non-trivial.

99% of people don't even have a clue that there is a world outside MS Office. I have problems receiving email attachments from these folks, because they have no idea that not everyone uses Outlook/Exchange.

They've never seen any other mail clients, and don't understand why people outside the company can't read their HTML mail with embedded OLE objects and attached vCard files. I play games with them... they send me Rich Text email, I change it to plain text and send it back. Their client is set to send Rich Text by default, so it gets changed back. Then if I reply again, I change it back to plain text. They must wonder what the hell is going on.

Many people could get by just fine with an "alternative" office suite, if they didn't have to exchange files with the computer illiterate.

Personnaly I don't like to see every two days in my mailbox those "where is the Desktop?", "it was better before!", "Companies need professional Scheduling management tools!" postings.

My biggest concern (having implemented Star Schedule server for 30
people so far in a 50-employee company) is that no regard at all has
been given to the groupware functionality in OpenOffice. I have very few
gripes with Star Schedule, but will need to explain why the newest
verions of Star Office cannot be used with the Schedule Server.

If someone were to start a project to make a newer better groupware tool
for open office (or some other open-source cross-platform tool), I would
find a way to contribute (as I think quite a few others would).

I must say.. I recently switched to using StarOffice even in windows, just for consistency.

Everyone says 'it's not the same as office'. no. It's not. And it doesnt' have every last feature, but it has it's own unique features, and is a deadly office suite nontheless.

The only real hurdles I've come across so far, that prevent me from converting the entire office, are a) embedded VB (important in some sheets... very important) and b) I can't figure out how to open Password-protected Excel sheets.

Sometimes, as a business, you have to fit what you do to the tools you have. There will never be a perfect replacement for office, but there will be things just as good (Like staroffice). You will always have to change the way you do certain things.

Wrong! HancomOffice has an excellent set of MS Office import/export filters. It looks to be a very complete and mature product and I'm looking forward to seeing what it can do. Especially with Hancom's recent alliance with theKompany, giving it Kivio (Envision), Aethra (QuickSilver), Quanta+ (WebBuilder), and reKall (easyDB) to add to the HancomOffice package (story on the Dot [kde.org]). Of course, I'm still rooting for KOffice though:-)

Nobody will ever compete with Microsoft Office head on--not because people can't technically produce anything better, but because Microsoft sets the agenda. Lotus SmartSuite probably had the best shot, and it failed even in situations where people got it for free.

But Office is a cumbersome dinosaur. Office-based business applications are flaky, difficult to use, and unreliable. Office can be dethroned.

What we really need to do is to figure out how to get the same jobs done with something that is compellingly better: software that enables web-based collaboration, software consisting of small, specialized, downloadable applications, software that's much easier than Office to extend and program, even for non-programmers.

Absolutely! If you let your competition define what you are, if you let your competition change the rules of the game, then you can't win. Is the goal simply to push Office off the desktop? Then find a company who can reengineer it, try to sell it for, say, $25 a license, and absord the loss as everyone says "Why trust a cheap imitation?"

Or...go study the market and find out what people really want to do with a computer and build something that does exactly that.

Remember, Linux is Unix, and Unix has been around for a quarter century. If we really want Ordinary Mortals (i.e., people who don't care what OS they use) to use Linux, or any other "free" OS, we're going to have to give them a very, very good reason.

Gobe actually has great import/export filters, but they're even better: They actually developed an API that anyone can write to, so if they port the API and the filters over to linux (which they are apparently doing), then any application can choose to just write to that API and will immediately be able to save or write in any of the M$ formats that Gobe supports.

BTW, this functionality is based on how BeOS does translation for other formats, too, mainly graphics. Linux could really use to take a lesson from this, because it was one of the coolest and best functionalities of BeOS. Hopefully Gobe will port the full API over, not just the filters themselves.

Once a good set of filters are out there, Microsoft WILL change the file formats, guaranteed. Ask the OS/2 people what maintaining compatibility with M$ was like, and how much it helped them.

Whereas this was once true, it is no longer. Microsoft cannot change formats so quickly that it makes their own legacy software incompatible. If someone cannot read a DOC format in Office97, Microsoft stands to lose.

However, it is worth discussing briefly the DOC and XLS formats. Both of them can insert objects through COM under Windows. This means that almost anything that can be an object in Windows can be in a DOC format. In case you do not get it yet, this means the entire operating system's APIs need to be cloned to import a document completely and properly

I think it is safe to say this will never happen.

Powerpoint is less relevant. It sucks rocks, plenty of free better alternatives exist, and people exchange powerpoint slides a LOT LOT less than they exchange office documents and spreadsheets. What REALLY needs to happen is that people need to insist document exchanges occur in common formats. For read-only things, pdf works great. For editable documents, an old version of word doc format works (with text only), or html, or xml.

When someone sends you a DOC format, immediately email them back to ask for it in a standardized format. If this becomes commonplace, standardized formats will become more common as well, and EVERYONE will benefit from true competition among office suites.

Right now the only competition to Word is free office suites. And that is not a competitive market.

almost anything that can be an object in Windows can be in a DOC format. In case you do not get it yet, this means the entire operating system's APIs need to be cloned to import a document completely and properly

This is true. However, few people [ab]use this feature enough to make this a deal-breaker for free software.

People really do want to drop spreadsheet data, charts, and graphs into a word processor document. They might even want to grab a record from a database. Once free word processors have enough features to usefully match MS Word, and once free spreadsheets have enough features to usefully match MS Excel, it will be possible to make an import filter that will convert a Word document, even one that references some Excel data.

Yes, there will always be documents that have strange things embedded, but the 99% case is just a few types of embedded data. Those few types can and will be imported by free software.

So, how long do you guess it will take M$ to introduce a default-encrypting-scheme on.doc and all their other proprietary formats and starts haunting all the Word-et-al-filter-authors for breaking the DMCA?

So, how long do you guess it will take M$ to introduce a default-encrypting-scheme on.doc and all their other proprietary formats and starts haunting all the Word-et-al-filter-authors for breaking the DMCA?

For all the machievellian things Microsoft does, and except for the gaffe over the Kerberos doc, Microsoft is one of the least litigous tech companies around (and notice how quick they were to distance themselves from legal aggression over it once the PR backlash began). Considering how closely their every move is scrutinized, I haven't seen a single slashdot article about Microsoft sueing anyone. Apparently the legal system is not part of their bag of dirty tricks. They probably could have sued Wine into oblivion, and they havent -- even though it's now getting functional enough in parts to start making serious inroads. Adobe on the other hand is already trying to put people in iron cages for competing with them.

Developers can write better and better office software, they spend hours, days, and months to make it more stable, more powerfull, and more user friendly, but all you need is import/export.doc files.
So Microsoft is safe, he will have office monopoly forever, becouse users don't need features, they just need to open and save.doc file with pure text (sometime with different fonts and bolds).Am I the only one who is happy with LyX (yes, without learning LaTeX) ?

I for one would like to put aside the KDE & GNOME bias that pushes many to adopt this word processor or that.

Our fundamental problem to be solved is a lack of UNIVERSAL and fully functional MS-Office import *and* export filters. At this point, I would say it's the biggest problem Linux users must struggle with (emphasis on "users" here... the administrators must still struggle with Linux's crappy font management, etc).

RTF, HTML, and the "other" semi-formatted languages don't support popular features very well, such as tables and frames. Would YOU export your resume from a Linux app as HTML or RTF, and leave it to Office to render correctly? HR people are the most "clingy to Office types", and if your resume looks shitty - it's YOUR fault not theirs (world is not fair).

If your RTF resume looks bad in Office, *obviously* you are not a good candidate. You show little attention to detail to allow your resume to overlap characters and corrupt text. I've seen Office mangle some RTF docs that look PERFECT elsewhere -- it's an anti-competitive feature of MS Office. RTF documents from Office, re-import perfectly.

SO... to get to my point, we need good filters. The KDE Office and AbiWord folks should get together on the OpenOffice mailing list, and work to make sure the OpenOffice filters are exactly what they need. There's NO EXCUSE for not standardizing our I/O filters now.

As a great example of co-operation between KDE and GNOME applications, look at gPhoto. This started as a Gnome digital camera app, but the code became something better... a standard Linux API for cameras. Now there's a ton of KDE and Gnome apps, all of which run on top of gPhoto.

Just because KDE and GNOME use fundamentally incompatible desktop libraries, does not forgive these folks for not working together on EXTENSIONS to the desktop. We need more success stories like gPhoto, in areas like Printing, Font Management, pretty Wizards for Samba, etc.

I think about the lack of such examples in Linux, and the thought depresses me...

_Scott

When is Slashdot moderation going to favor less frequent "signal" posts, over "dozen posts a day" noise accounts?

I was recently exploring a change of job opportunity. Most people I talked to said, "Send me your resume in Word format." Even for a Linux sysadmin position. At one point, I told the recruiter, "I don't have access to Microsoft Office but I have my resume in HTML form which you can load in Word with no trouble." His (her?) response was, "Well, you can hardly call yourself a professional if you don't use Office, now can you?" and the conversation dropped.

Another place sent me a job application form in Excel. I tried loading it in StarOffice and it sort of loaded, but I couldn't actually fill it out -- the StarOffice loader choked on protected fields and so on.

ps. I'm still half-heartedly looking for work. My resume can be seen here [the-dixons.net].

I was recently exploring a change of job opportunity. Most people I talked to said, "Send me your resume in Word format." Even for a Linux sysadmin position. At one point, I told the recruiter, "I don't have access to Microsoft Office but I have my resume in HTML form which you can load in Word with no trouble." His (her?) response was, "Well, you can hardly call yourself a professional if you don't use Office, now can you?" and the conversation dropped.

As well it should have -- that conversation should only have been continued with that recruiter's manager, at which time you should have focused on the very unprofessional insult rather than any technology choice issues involved. Anyway, I send my resume in HTML format, it views in their email client just fine, never raises a peep. If they're really insistent, I have a copy in Wordpad. The reason's technical: I only have Word2k, which didn't seem to want to convert down properly last time, and I don't have access to older versions of Word anymore to test.

Filters (importing/exporting) are only a temporary solution. If only maybe for the sole reason that MS will break it's format to make them useless again.

But for the reason that we need to create an open file format. I know there is some work going on with the OpenOffice project to do so, but it needs to have the support of all office suites and applications.

I greatly applaud, and welcome, the Gobe production suite, but all we need are more proprietary file formats.

If we could get everyone...WordPerfect, StarOffice, Hancom, Gobe, KOffice, Gnome, etc. to band together to create an "Open File Foundation" to create a standard to which each could build file formats that could be shared accross platforms and applications suites the magnatude of such a collaboration would be huge!

It would be(or is) my dream that one day an office could theoretically have each of it's employee's using their office suite of choice and be able to seemlessly share documents amoung co-workers and others outside the office!

This could be the very straw that broke the camels back, so to say. If MS did not want to comply with the Open Standards it faces incompatability with the rest of the world. In this day and age of the internet, p2p infrastructure, and the like, it's a common compatibilty, not only across platforms but across applications, that is going to be needed.
People will eventually see this and if MS dosn't want to play...so be it, alternatives abound!

This not only goes for File formats but also to other formats such as audio, video, and other streaming media. Ogg is a nice place to start and I pray it takes hold.

The days of closed formats and single platform narrow mindedness are coming to and end!

So for the time being...and unfortunatly a requirement to even get into the door to create such standards...yes we do need decent filters!
but only for a temporary solution!

Another thing these are missing is a Mac verison. Is there any Linux-Mac word processors available. "Cross-platform" word processors are either, Windows-Mac(MS Word) or Windows-Linux(Abiword, StarOffice,WordPerfect). If Abiword came out for the Mac I would probably switch to it and suggest it to everyone I know.

Someone pleeeaasse setup a site dedicated to writing really _good_ MS Word 97+ serialization routines in ANSI c. I would but I'm alread sidetracked on a tangent of a subproject and the stack is just too high right now. This is not hard folks. I know it sounds like a boring project but it's not!

Are you familar with the principle of Recursive Composition (a.k.a The Composite Pattern)? This is without a doubt my favorate programming construct. The key here is that you define an object that can be a child as well as potentially contain children itself. If you can uniformly parameterize the properties common to a set of these objects you can use the priciple of Recursive Composition to build a tree of these objects and then serialize it back using preorder depth first search tree traversal.

For example, a binary networking protocol might have a header, some parameters, and a data payload area. The header has an arbitrary block of security information, which in turn might have a DES encrypted key and an integer describing the length of the payload. So to encode this message using Recursive Composition, define a packet_t type that has the three sub components such as the arbitrary security block, which in turn has an encrypted DES block as a child component. See the tree? Now, if you can parameterize the temporal properties of these objects you can delegate the responsibilty of encoding certain areas of the network message to functions like: enc_security_block(struct security_block *sb, char *dst, size_t off, size_t len) would then call enc_des_key(struct des_key *dk, char *dst, size_t off, si....

The classic example of Recusive Composition is that of GUI components. You have an abstract object called say Component. Components can contain other components. Sub types would be ButtonComponent, TextComponent, TableComponent, etc. These components might contain subcomponents as well (e.g. ButtonComponent might have a TextComponent for it's label). See the tree again? Now, when it comes time to draw these components you don't have one big block of speggetti code that considers all of the different component types but rather delegate that responsibility to method of the component itself. This greatly reduces the complexity of the problem (actually making it feasable whereas it was not before). Again, we just have to parameterize *where* these components are to draw themselves such as FrameComponent_draw(Window *win, int x, int y...etxc.

So what does this have to do with writing serialization and deserialization routines for Word documents? Microsoft Words format (and the format of just about every other sophisticated document format out there) is flattend by serializing an internal tree of nodes (like the GUI Components and more so the network packet encoding described above). The tree of nodes is no different from the trees used above to describe Recursive Composition. So by recusively delegating the resonsibilty of encoding/decoding a region of a MS Word document you can parse it into a tree and then do preorder dfs tree traversal to serialize it into any format including.doc.

The hardest problem here by far is determining what the primative types of the document are (e.g. like the security_block and the payload length integer in the network packet). If you don't know what the leaves of the tree look like you cannot start to write a lexer. Find out everything you can about the format of each of Word's elements. There are several projects that claim to have decoded the format to a certain degree. These would be a great start. However I have spoken to these guys and the problem is they are only interested in supporting their own product (Abiword and the KOffice guys talked about a calaborative effort but got hung up on choosing libraries and language and other trite crap). An group independant from these organizations should be established so that the library is not tied to one product.

Once you have a good idea of the bits and bytes behind the layout of nodes in the format you can write a (at first crude) lexer or Lexical analyser. This is simply a peice of c that will break the format into tokens. It's simple in the respect that it doesn't have to worry about the logical layout of elements at all. It's only concerned with nibbling off the primative elements (tokens) themselves. The interface might be as simple as init(char *filename), gettoken(struct lexer *lex).

Now you have to write a parser. This is what bison/yacc is for. This is non trivial but theres a great book called _lex & yacc_ by John R. Levine that can describe how to write a yacc grammer in 200 lines that in convential c would take several thousand lines, take twice as long, and still not work. Ahh yacc grammers to me are like dougnuts to Homer Simpson.

Once you have a working lexer and parser (probably a 1000 lines of code), you can start to build a tree. You need a tree structure. The W3C has written a specification for representing documents as a tree of nodes in memory called the Document Object Model (DOM). Mozilla uses the DOM. It's XML and HTML centric but it's really totally arbitrary. A DOM tree could easily be constructed by adding createNode, appendChild, etc calls to the yacc parser. It just so happends that I have written a DOM implementation in ANSI c. Its called DOMC [freshmeat.net] and it would be perfect for this task.

If you do this much you are sitting pretty. You can just traverse the tree and spit out whatever the analigous elements are for say ps, html, sgml, xml etc.

If that doesn't get modded up to +5 informative, there's something wrong, because that was a damn fine exposition of recursive composition. I still don't know that it's very interesting tho, since recursive composition in a nutshell is: instances of a class have have has-a or linked-to relationships with objects that are concrete subclasses of that class. Almost any tree structure is like that. It just looks interesting in a UML diagram when you see that arrow looping back onto the same class.

Anyway, there's DOM-based XML parsers already in C, like gnome-xml (or whatever it's called, it doesn't really require gnome, I've used it elsewhere with no difficulty). Same library works in both stream (sax) and tree (dom) mode, actually. And MS has an outstanding DOM-based parser usable in pretty much any language with their XML parser, which IE happens to use too.

Anyway, I'm under the impression that XSLT was designed for this task of descending a DOM tree and translating it to another domain, e.g. ps or html...

Well, keep in mind my only point about the DOM is that it can be used without XML. It's really just a tree of nodes with operations to build/modify it. It can be used to represent a tree of nodes for a MS Word document as easily as it can an XML one. And once you have it as a DOM tree you can get to XML, ps, html, word, rtf,...

Figuring out how to render it on the screen so that it looks and acts like it looked and acted on Word is the problem.

Well, I'm not talking about rendering or actually editing (implied by the "acted" word). At the very least you could convert it fairly well to just about any format (e.g. postscript). But presumably the Office suite using the "filter" would have rendering capability that is flexible enough to render a word document as it would appear in word. If this is indeed true then the real problem is generating a suitable document tree for the viewer in question. This is simply a matter of traversing the tree generated by the filter and translating it into the tree the viewer uses. You don't need to do any rendering at all. You just have to get your node-for-node translation routines to tweek it's attributes in the translation. If the viewer doesn't do a perfect job it should still be quite functional. If the veiwer doesn't support some OLE mumbo jumbo you can quitely skip those nodes in the tree and you still have a functional document. You could then edit it and reverse the translation.

...documents are not dead trees. They can do the darndest things,...Sounds, animations,

And you know how Word does it? Recusive Composition. Meaning Word doesn't do it at all! It delegates the resposibilty of playing that sound to another component. Within the document that sound is probably represented as some arbitrary chunk of bytes flagged as 0x52{media-unknown/joebobssoundformat[TGS%%@Y@*(SJ ESIEW&*EY...]} which Word plucks out and creates a node in the tree for, and passes it to some subsystem function to return a OLE component to satisfy the blob. Do you think they completely refactor the.doc format to accomodate an anamation? No! This is well known information guys, comon someone back me up here!

...if rendering was unambiguous, pages would look the same on IE and Netscape...

Well this is a different issue. They render stuff differently because the specifications for stuff like CSS where just getting started when NS4 was released. It's been a while. I believe Mozilla and IE should render things exactly the same way minus font metrics. That is if they both conform to the standards established by the W3C and friends. And I think they do. But this is incedental and I'm not talking about rendering (see other response to this thread).

First, if you want to know what the AbiWord and KWord folks are up to, look at:

Well, I have not checked lately but when I looked into this problem the last time I didn't see a lot of interest on the various mailing lists and I tried what I believe was considered to be the best working code and it didn't work to hot for me.

the lexing problem is being solved by *generating* the lexer from the specifications themselves

Ok. Good to hear. But the documentation I saw on MS website didn't look like much of a "specification". Do you have a link?

you talk as though it would all be trivial if we had used compiler-compiler tools.

You obviously didn't read my anaysis too carefully or you would have seen that I specifically stated; "This is what bison/yacc is for. This is non trivial but theres a great book...".

Word syntax requires a huge amount of semantic knowledge to drive the parse,

Well, I don't know for sure because I have yet to find any really good information on the actual format but I find it extreemly difficult to believe that it is not based on Recursive Composition. It may seem obfuscated because of backwards compatibility issues but MS's language support is very good. So to dismiss using a yacc grammer shows me you are either clueless about the topic or you wrote the filter for Abiword or KOffice and this is just hand-waving.

Many people here are saying that Star Office is doomed if it doesn't have good import/export filters. Although this would be a good feature to convince hesitant managers, I think that this feature is overrated somewhat, at least compared to some other considerations. "We must be able to read external documents" is the usual defense, but this probably comes up less frequently than one might think, and star office handles most of those situations fairly well already. I've even used it to import--nearly flawlessly--powerpoint with Equation editor inserts.

What I mean is, if format was so important, Microsoft word would have never caught on, because its wordperfect->word filters were terrible. Even its word 5-> word 95 -> word 97 -> word on mac filters were terrible. Everytime I would look at a document in a new version, things would move around. Same goes for Lotus/Quattro->Excel. They even changed fundamental syntax for the spreadsheet! (in quattro, functions begin with an @ sign, whereas in excel, an =; a number of the function names are different as well, I believe.)

My point is that compatability isn't everything. Platform can be even more important. One of the major reason's MS Office is a 'standard' is because Microsoft moved the industry to Windows with 3.1, and the industry leaders (WP, Lotus, etc.) on the dos-based platform understood only too late that slow adaption to Windows meant their death.

So, StarOffice might stand a chance, even if they are not 100% compatable, because other considerations can be more powerful. For instance, with Microsoft pushing increasingly restrictive licensing, and the emminent maturing of many linux desktop and business apps, this may give enough of a toehold for real market penetration. By the same logic, even if the conversion filters are flawless, they might not capture the attention of the business world, many of whom won't likely even consider Star Office as an alternative.

Two things prevent most people and businesses from moving from Microsoft products to other products:

1. Application Lock-In, and2. FUD

1. Application Lock-In

Everybody and their brother, nearly every business, and all of their strategic partners, not to mention schools and government - all of them use to some extent Microsoft tools, day in, and day out. People have had YEARS to learn the nuances and problems, how to get around them, and what the applications can do. All of them know that they can email a.DOC or.XLS file to a business partner's secretary, and s/he will be able to load it effortlessly, and it will look the same.

A Linux Office suite? How are these people to be certain that it will work - plus how are they to cope with the differences that are sure to be in place between the Linux Office Suite and the MS Office Suite? How do they know they will be able to send this exported XLS file to their friend, and it will open in MS Excel properly?

2. FUD

Which leads us to the second issue, that of FUD - if they don't know, they will be full of fear, uncertainty, and doubt as to whether to use the office suite for Linux, because these files they are trading down the hall or across the city may represent a potential deal - if the presentation software doesn't go a smoothly as Microsoft's, it may mean loss of money - maybe a job! If the XLS or DOC file is mangled (either by the Linux Office Suite, or by the MS Office Suite reading the Linux version), time and money will be lost trying to figure out what happened, or at least getting it loaded and converted using "standard" MS Office.

These are the two problems a Linux Office Suite has to overcome (actually, two problems any MS Office competitor has to overcome). Because MS has such a huge lock-in, and the FUD is raging - companies won't switch - because their partners aren't switching (and their partner's partners aren't, etc).

It is a tough situation, and will be hard to overcome. Education to override the FUD will help, but even if you had perfect compatibility, all MS would have to do is introduce a "new" format that Office would default to, and you will end up holding up and vindicating the FUD. People will then be doubly uncertain to try the Linux stuff, even though it would be MS who broke the compatibility! I don't know what the answer to this is, but if Linux is ever to really gain on the desktop, those two issues will have to be addressed...

As far as I know all of these are lacking the single most important thing, a robust and complete set of import filters for Word, Wordperfect, Excel, Powerpoint, etc.

There's a real good reason we haven't seen this yet. It's the chicken in the egg problem. Before you can have fully capable import filters, you must first impliment the feature set of the app you're inputing from. For example, Microsoft Word has a bunch of features that do not yet appear in most other "word processors". If your word processor doesn't impliment these features, a filter that does is quite useless for your application (except in regards of ignoring things your application doesn't understand).

Unfortunately, before those features are implimented in your own application, you're going to need some more acceptance (to bring more developers on the project). Unless you can say you do what the mainstream needs/wants, you're still an obscur project. *sigh*

Off this topic, one other thing that kind of bothers me is the massive ammount of reinventing the wheel. Now while having many options is good, there are just far too many open source projects that are each trying to create their own robust, fully-featured office suite. Why is the community wasting so much time?

Some of these really should merge and share code more. Or at least, there should be one organization that is dedicated to creating a unified set of the features found in all open source office suite projects. That way, they could create a big set of libraries that do these things... so when the next guy has this reckless desire to make his own office suite... well, you get the idea.

Off this topic, one other thing that kind of bothers me is the massive ammount of reinventing the wheel. Now while having many options is good, there are just far too many open source projects that are each trying to create their own robust, fully-featured office suite. Why is the community wasting so much time?

In the absence of being paid for their work, open source hackers prefer to work with people they know, toolkits they're comfortable with, languages they prefer, and so on. This will always create fragmentation.

Some of these really should merge and share code more. Or at least, there should be one organization that is dedicated to creating a unified set of the features found in all open source office suite projects. That way, they could create a big set of libraries that do these things... so when the next guy has this reckless desire to make his own office suite... well, you get the idea.

I frankly don't see anyone joining into a bureacracy like that. Agglomerating incompatible organizations together like that just drags everyone down. What we could use is a component standard, like COM (or XPCOM, assuming it actually has binary level compatibilty). It has to be less painful than removing one's own spleen to create such components, and they really do have to work in various languages, C, C++, perl, and python at the very least. It's COM and OLE that have really made windows a platform of choice for hordes of developers. It'd be nice to see at least those successes brought to open source, even if MS is moving one step beyond that now...

I like OpenOffice much better than StarOffice 5 (so far) because it can use my X fonts and it's pretty (anti-aliased). But I haven't used it enough to know if it's more stable than StarOffice 5 yet. Perhaps others can offer some knowledge. Also what's the deal with the inbuilt web browser? Did the developers write a new one (since the original one was stripped out with the release of the source to staroffice)?

I had never heard of Gobe and Hancom prior to this article, yet they appear to have Office suites far superior to KOffice, Gnome Office, and OpenOffice, and which were developed quite rapidly. Both companies appear to be small and efficient with tight-knit programming teams. Both companies focus on Linux and receive all the benefits therein. Both companies are *selling* their products as proprietary closed software, but for very reasonable prices compared to Microsoft Office and with far more flexible licensing.

This tells me two things:

1.) Open Source development in office suites is not working as it stands today. Progress is slow and the results are mostly crap. I'm sorry, but I've had far too many crashes and frankly, that is entirely unacceptable. It is not that damn hard to write a stable piece of software. StarOffice is perhaps an exception, but remember that StarOffice started out as a commercial product and was then bought and given away to the community by Sun as a means of undermining their biggest competitor. The fact that the Open Source office suites are largely failing means that the experienced programmers are not being supported enough to work on them full time.

2.) Gobe and Hancom are meeting their operating costs by charging reasonable licensing fees for their software. I venture to bet they are only marginally profitable, yet they are stable businesses at the moment. In return, their programmers get paid to write Linux software full-time -- software that appears thus far to be superior to free open source offerings. In other words, their development model is working for them. While these two companies have every right to choose their means of business, it is my belief that true open source companies could do at least as well. The problem is a lack of open source entrepreneurs. There are dozens of business models that have not been explored for making money from writing free software. There are dozens more not even dreamed up yet. What we need as a community is creativity. Eric Raymond's list of business models in "The Cathedral and the Bazaar" is a good start, but it is by no means complete.

Open Source is a powerful idea, but it must be exploited wisely. Whining has never solved any of the world's problems. Nor has complacence. Open Source programmers, look at yourselves and believe that you can change the world, for you can if you will only believe. You are intelligent, you are capable, you are innovative. Go make a difference while you have a chance. I certainly plan to.

So why is it so hard to find screenshots of
Productive? I won't even think about a product
until I see it in action. Any plans to release
a demo for Linux (e.g. a movie of someone using
your product to do common things)? Any plans to
have a checklist of features of Office XP vs.
Productive (a la OpenOffice)?

I'm a Linux, Winblahs, MacOS 9.x and X.x user (former Be user) - and a fan of Productive.

Obviously the a fair amount of the discussion here at Slashdot is about file filters.

Can Productive aim to become the babelfish for documents from anywhere to anywhere?

For example, if my Mac using buddies send me ClarisWorks, AppleWorks 6, and Nisus docs, and my uncle in Ohio sends me.DOC or an old.wpd, it'd be a real treat to open it all in Productive, and have it come out fine.

Now, it'd also be cool if productive worked on Mac OS X- I'd buy productive for Win32, and Mac OS X... I might buy it for Linux instead of Win32, and spawn an X display from the linux box... but more and more, I find I'm not using linux for anything more than file serving and cd-burning.

I don't have a lot of influence over my Unk's OS choice, but I can get him to switch office suites without too much arm-twisting. I got him to use WordPerfect for about 4 years before he felt the urge to go back to MS...

VNC is a way to remotely control a computer. The desktop of the remote computer appears in a window on your computer. If you want to run Linux on your computer, but you need to use Windows sometimes, this is one way you can do it.