People keep prattling about how great the filters are in Open Office. Come on, people, let's be a little more objective. Parroting the OO party line is not good for the open source movement.
From my experience, OO's filters are decent, perhaps a little better than Microsoft's, but hardly anything to get excited about. The last time I read a Word file in OO, it screwed up a very simple bulleted list. Face it, it's very, very hard to write a really good word processor filter, especially for a file format as messy as Microsoft's.
The OO native file format is pretty good, or at least the current version is. I have some issues with it, like throwing in every obscure XML namespace that has some silly feature that somebody likes. And there's still too much device-specific information. But I guess you can always just ignore the noise, especially since it's more neatly separated out than in previous formats.
OK, I'm cynical about attempts to challenge Word's workplace dominance. But here's a scenario/fantasy that's worth thinking about: Bush II loses the '04 election, despite his carrier landing skills. An "anti-business" Attorney-General revives the anti-trust actions against Microsoft. This time, they ignore silly outdated rememdies like splitting off the application divisions (multiple monopolies, great) and come up with something that's ahead of the curve. Like forcing Redmond to work harder at standards compliance. Hey, you say Word dominates because it's better? Prove it: have it read and write OO format! Then you can compete on features, rather than locking out the competition with format crap.
Thanks for the validation. I know a lot of tech writers whose eyes glaze over when you talk about the nasty little issues. Smart people, mostly, but no patience for nasty little technical issues.
Yeah, that's why I'm a tech writer. I don't have the creativity to be a writer in the ordinary sense of the word. But the mental effort needed to write good technical prose is what I need to keep my brain from getting calicified.
Tools: because you asked. RoboHelp [ehelp.com], Adobe FrameMaker [adobe.com], and, sad as it is, MS Word, are the main tools for the job. Knowing XML, HTML, Dreamweaver, Flash, and the like can also be helpful, depending -- this field is as specialized as the computer world. The technologies you know define your job. For more ideas, check out the trainings [ace1training.com] offered at a local tech. comm. consulting firm.
Your advice is correct -- unfortunately. The authoring tools we use are seriously out of date. It isn't that XML is "specialized", except in the sense that XML isn't worth the trouble if your document isn't very structured -- in other words, it isn't a technical document.
XML and its progenitor SGML solve a lot of problems. Using them, you can create documents where proper structure is enforced. That's damned important when you have a big document base that difficult to manage, or when you need to deliver documents in multiple versions (the C++ version of the API versus the Basic version versus the Python version..) or when you need to deliver it in multiple forms (HTML, PDF, WML, VML...). And it makes content management easier. I could go on and on.
So why is everybody still using anti-structured, closed-format tools like Word, FrameMaker, Robohelp? Bunch of reasons. The biggest is inertia. There are a lot of people with expertise in these tools, and they don't want to retools themselves. There's also the sheer difficulty of pausing the product cycle long enough to convert your document base. And the difficulty of designing XML applications (much easier than SGML, but still not easy easy).
What's really frustrating is that XML applications are exploding in everything except technical writing. The technology is just the best way to manage huge gobs of data or content. It's gotten so that when you say "XML Content Management System" people assume you're talking about web content. Which is cool technology, but not something that does me any good.
Well, Word does make it hard to impose structure on a document, and formatting does tend to "explode" (perhaps "leak" or "infect" is more accurate) in mysterious ways. But FrameMaker have its share of structure/formatting confusion issues. Perhaps a little easier to control than in Word, but you always have to be aware of them. A poorly-trained writer can really fuck up a Frame document.
FrameMaker dominates a certain kind of writing because it has a lot of features you need to do that writing: conditional text, self-updating cross-references, self-updating indexes, fancy templates, etc. None of these features is particularly well-designed, but the Word equivalents are mostly even worse. Or at least they were 15 years ago, when the two programs were carving out their respective niches.
I dislike Word, but I positively hate FrameMaker. Mainly I hate its user interface, which is like the GUI version of EMACS -- it pays lip service to menus and toolbars, but it still assumes that a real user has memorized all the keystrokes. Unfortunately, FrameMaker will remain dominant in tech pubs for my lifetime. I had hopes that competing XML editors would grab away market share, but the only one that came close was XMetal, and Corel seems bent on destroying that one.
Actually, FrameMaker does a semi-decent job of authoring structured markup -- provided you have a prepackaged XML or SGML application for it to use. It comes with ones for a subset of XHTML and an obsolete version of DocBook. Anyting else, be prepared to spend money on a consultant, because developing FrameMaker structure definitions is a nightmare.
I can tell you that most of it is pure druggery. If you like rewritting the same paragraphs over and over and then only rewritting someone elses copy over and over should you consider going that route.
For some strange reason, I actually enjoy that stuff. No, I take that back -- it isn't strange. It's the satisfaction of recrafting an explanation until it can't possibly be misunderstood. Which is probably similar to the pleasure a programmer gets from crafting code that couldn't possibly work any better.
I know it is typical in the industry to not pay them dick...
Not in my experience. I've always made good money as a tech writer. Maybe a little less than a programmer with similar education and/or experience, but not that much. I have seen companies that think that tech writers are glorified proofreaders ("don't try to understand it, just check my spelling and put it in the manual"), and pay them accordingly. I'd avoid working at such a company -- as much a matter of self-respect as of greed.
Some programers are good writers, but when they are writing about their program they do a terribal job.
I don't think that programmers simply lose their writing skill when they try to document their own software. The problem is that "good writing" and "good technical writing" are two completely different things.
Example: I once worked for a software company that was known for hiring really, really smart people. A lot of whom were very good writers -- I'm forced to admit that many of them were better than me, in the sense that they could turn out lucid, interesting prose. But they simply didn't understand the practical problems of explaining technical procedures to people.
Once, I was tasked with documenting a package that was basically a patch on another product. There was a central engine in the form of a DLL, and installing the package meant first installing the original product, then extracting the replacement DLL from a ZIP file and putting it in the correct directory so the original product could be made to load it in place of the default engine. Should have been done with an installer, of course, but for various reasons this wasn't possible.
So, I sat down and wrote a careful, nit-picky explanation of how to do all this. I carefully explained how to extract the file on the command line using info-zip (winzip didn't have its current dominance at the time, and info-zip was easy to obtain) with enough generalities so the user could adapt the procedure to another archiver.
I was not allowed to include this procedure in the release notes. The engineers felt it made the product look bad, like we didn't trust the users to figure out a more elegant explanation.
I ended up quitting that project because I just wasn't doing anything, except repackaging the prose of the engineer who grabbed my job away from me. He was actually quite a good writer -- he just didn't understand how easily written procedures can be misunderstood. As, in fact, his mostly were.
I am considering a masters in professional writing, so I can be qualified for technical writing positions, or just going back for a masters in CS.
OK, false assumption here: that you need to study tech writing in school to actually do it. I've known a few people with Technical Communication degrees. Maybe 75% of them knew what they were doing. Which is probably twice the percentage of the profession as a whole, so most TC programs must be pretty good. But that other 25% tells me that the degree is no guarantee of anything.
I've never really looked at academic programs for tech writing. They didn't exist when I was in school, and most tech writers are still people who've drifted in from other professions. I've worked with several people who've bailed out of an academic career, and only one of them was in Computer Science. (Physicists seem to be pretty common for some reason.) The fact is, technical communication is a simple, pragmatic discipline. If you want formal training in it, you might actually be better off going to a certificate program at a community college. If it's a good one, it'll be taught by serious, working writers, who will teach you a lot more than academicians.
Not to discourage you from getting that Masters. First, it always carries weight, no matter what you get it in -- you'll simply make more money because you have it. And if you're not totally mercenary, you can consider that a good masters program (and do remember that there are lots of bad ones) will teach you how to do research and explain your ideas. But for that purpose, I'd have more faith in a degree in Literature or History than one in Technical Communication.
On the other hand, you might consider simply plunging ahead. If you're conspicuously smart, know technology, and write real good, you can probably get an entry-level job right now. Pick up a few books (Joan Haxos is good, if a little patronizing) and learn as you go.
I'm a tech writer myself, and I ought to flame you for slandering my profession. But I can't, because you're completely right. There are a lot of stupid, arrogant, ignorant, presumptuous bozos in my profession. A lot of them can't even write!
Damned if I know what it is. My best guess is that the industry just doesn't understand what good documentation is. Usually, the only measure of quality is completeness. If you've got an entry in the printed index or a keyword in the helpfile that covers every single feature, or API call or whatever, then supposedly you have a high-quality manual.
Which, of course, has nothing to do with the user's needs. It's not enough to talk about it. You have to put the information in a form people can find and use. It's not enough to have a keyword/index entry, you have to have the right one. It's not enough to describe every feature, you have to give a description that's readable, that explains why you're interested in the feature, how the feature relates to other features and to tasks the user might want to do.
But nobody gets this, so a lot of software products come with big fat manuals that nobody reads -- that aren't even meant to be read! They're just there so nobody can complain that everything isn't documented. And of course any idiot can write that kind of documentation.
Of course, there are companies that take good documentation seriously, and realize that it adds value to the product. They try to hire good tech writers and do good documentation. And yes, there are good tech writers out there. I sometimes persuade myself I'm one of them.
Speaking of which, anybody want to give me a job? (API writer, documented thousands them, can read every programming language you know about, and some you don't.) My big problem is that I kind of forgot to finish my BA. Which didn't use to be a fatal problem -- just a little harder to get hired at the best places. But now there's a surplus of "qualified" talent, and the gatekeepers just filter me out.
No, he means a device that makes water hot by heating it. Admittedly there is no other known way to make water hot, but technically the experession is correct.
Seriously, though: Dude, lighten up. You never said something in a clumsy way? Slashdot isn't the fucking Times of London, it's a bunch of people having a conversation. When people are having a conversation, formalities are not essential. Little slips of the tongue are deserve a little good-natured kidding, nothing more.
Amiga has a substantial wishful-thinking contingent, consisting of people who just can't deal with the fact that the platform failed. BSD actually has a lot of users, but you could argue that it's a wishful-thinking platform too. This is a concept that covers a lot of Slashdot content: Mozilla, desktop Linux, open-source alternatives to MS Office, Sealand as a place to stash your data... a big part of the fun in being a Slashdotter is participating in the debates between the Big Idea True Believers and the Wishful Thinking Skeptics. And part of the fun of being a Wishful Thinking Skeptic (like me) is that every once in a while, you turn out to be wrong.
Plan 9 isn't wishful thinking. It isn't even dead -- in order to be dead, you have to be alive at some point. Plan 9 appeared about 10 years ago, as a platform for various advanced OS concepts that evolved out of similar concepts in Unix. It's never found a real following, and really has neither past nor future.
What's really pathetic is that anybody would be interested enough in Plan 9 to actually install it, but so clueless about its current state, they can't even answer "Is there a third party X for Plan 9" without having their hand held. But not as pathetic as Cliff thinking such a clueless question is worthy of anybody's time.
Location of the binary is an implementation detail -- something isn't "more-OSy" just because it's in ROM. Besides, the very early MacOS wasn't a real OS -- like DOS, it was just a glorified loader. The fact that it was dressed up with a GUI actually supports my argument.
A "gui-based OS"? A GUI is just a layer on top of the OS. If you want to form any worthwhile opinion about an OS, you're going to have to dig a little deeper than that.
Back in the 60s, I took the Gene Roddenbery Correspondence Course on Bogus Science. Let me see if I remember how to do it: If you tighten the dimensional relationship of the atomic structure of an entity, you can make it bigger or smaller as you please.
You're going to ask me about weight. If you shrink an elephant to the size of a mouse, does it fall through the floor? Don't ask me, what do I know?
Anybody remember the 60s movie Fantastic Voyage, where they shrink a bunch of people and inject them into a guy's blood stream so they can fix a blood clot? They actually hired Isaac Asimov to write the novelization, and of course he insisted on dealing with all the Bad Science issues in the screen play. One thing he did was have the injectonauts go to a lot of trouble to get the wreckage of their submarine out of the body, 'cause of course it'll be a mess when it expands. Or maybe this was in Bixby's original screenplay. In any case, the movie just ignored this problem. The studio wasn't going to spend a lot of money on a detail that most of the audience wouldn't care about anyway.
And that's why movies have so much bad science. Good science is expensive, it's distracting, and nobody cares about it anyway. I've pretty much given up on movie SF.
However, the thought of "evil hackers" having low-level access to the system calls, snooping at the system would probably keep the CEOs up at night.
Windows doesn't do a particularly good job of hiding system calls. Anyway, a well-written cryptography application doesn't care who intercepts the data it sends, or how. There's a school of thought that says that opening up an encryption application on all levels actually enhances security, because it makes it easier for third parties to verify the vendors claims.
This is about support, nothing more. I'm suprised how many Slashdotters don't understand the costs of adding support for a platform to a product. I've worked on major projects where it was a big deal that we supported three platforms, and the choice of the third platform was a matter of major infighting. And this was in big companies with a lot of cash to throw around. I'm suprised that stamps.com has the resources to support two platforms.
Which begs the question, "Why is this important enough for an Ask Slashdot?" The last I heard of Plan 9 was a story on Slashdot about Plan 9 running on an embedded virtual machine, so it could run applications under a web browser, rather like Java applets. Nothing came of that either.
Which sucks. Means you can't subscribe to services that scape news pages or comic strips for you. It would be nice if you could set up a policy, saying that certain sites are allowed to download graphics. I think Outlook actually lets you do that, but of course it has other issues...
Incidentally, if you have Netscape or Mozilla, and use this option, you're not keeping graphics out of your inbox -- you're just keeping downloaded graphics out. It's still possible to reference graphics attached to the message.
Anyway, didn't we start out arguing over rich text in email? Even if I can't have downloaded graphics, I still want rich text.
I just thought of something really nasty I want to do. Find a server that's downloading tracking graphics, and saturate them with requests. Not a DoS attack, I don't care for those. Just a lot of requests making it very difficult to analyze their server log. All the files in the tracking list of course. But also a lot of random stuff.
The direction Microsoft took Corel when they bought 25% of them and shut down their Linux work was obviously and disaserously wrong. Corel has continued to lose market share, even in government work where it once ruled.
Your understanding of Microsoft's investment in Corel is simplistic. They didn't buy "25% of Corel". The bought a bunch of non-voting shares for a price that amounted to 25% of Corel's market capitalization. Given that Corel has been bleeding money since forever (that's what killed the Borland merger), this amounts to a simple gift, and not a very big one. Of course, giving someone money gives you some influence, but hardly total. You certainly can't blame Microsoft for the fate of any version of WordPerfect -- the Windows version was already commercially dead when Corel acquired it, the Linux version was a feature-deficient joke, and the Java version (yes there was a Java version) was dead almost before it was released.
Why did Microsoft throw all that money at Corel? OK, the official reason, to subsidize Corel's.NET efforts, isn't very plausible. But neither is the idea that they thought WordPerfect was any threat to them. Especially not Linux WordPerfect. My own guess is that this was a quid pro quo for Corel settling its patent lawsuits against Microsoft. By paying Corel off with an "investment", Microsoft avoids some taxes on the money. They did precisely the same thing with Borland -- before Borland started work on its Linux IDE!
You're right, I hadn't heard of that one before, and I thank you for telling me about it. The fix is to configure your client not to download external graphics. I'm going to do that right now!
Slashdot Mirror
From my experience, OO's filters are decent, perhaps a little better than Microsoft's, but hardly anything to get excited about. The last time I read a Word file in OO, it screwed up a very simple bulleted list. Face it, it's very, very hard to write a really good word processor filter, especially for a file format as messy as Microsoft's.
The OO native file format is pretty good, or at least the current version is. I have some issues with it, like throwing in every obscure XML namespace that has some silly feature that somebody likes. And there's still too much device-specific information. But I guess you can always just ignore the noise, especially since it's more neatly separated out than in previous formats.
OK, I'm cynical about attempts to challenge Word's workplace dominance. But here's a scenario/fantasy that's worth thinking about: Bush II loses the '04 election, despite his carrier landing skills. An "anti-business" Attorney-General revives the anti-trust actions against Microsoft. This time, they ignore silly outdated rememdies like splitting off the application divisions (multiple monopolies, great) and come up with something that's ahead of the curve. Like forcing Redmond to work harder at standards compliance. Hey, you say Word dominates because it's better? Prove it: have it read and write OO format! Then you can compete on features, rather than locking out the competition with format crap.
Yeah, that's why I'm a tech writer. I don't have the creativity to be a writer in the ordinary sense of the word. But the mental effort needed to write good technical prose is what I need to keep my brain from getting calicified.
XML and its progenitor SGML solve a lot of problems. Using them, you can create documents where proper structure is enforced. That's damned important when you have a big document base that difficult to manage, or when you need to deliver documents in multiple versions (the C++ version of the API versus the Basic version versus the Python version..) or when you need to deliver it in multiple forms (HTML, PDF, WML, VML...). And it makes content management easier. I could go on and on.
So why is everybody still using anti-structured, closed-format tools like Word, FrameMaker, Robohelp? Bunch of reasons. The biggest is inertia. There are a lot of people with expertise in these tools, and they don't want to retools themselves. There's also the sheer difficulty of pausing the product cycle long enough to convert your document base. And the difficulty of designing XML applications (much easier than SGML, but still not easy easy).
What's really frustrating is that XML applications are exploding in everything except technical writing. The technology is just the best way to manage huge gobs of data or content. It's gotten so that when you say "XML Content Management System" people assume you're talking about web content. Which is cool technology, but not something that does me any good.
FrameMaker dominates a certain kind of writing because it has a lot of features you need to do that writing: conditional text, self-updating cross-references, self-updating indexes, fancy templates, etc. None of these features is particularly well-designed, but the Word equivalents are mostly even worse. Or at least they were 15 years ago, when the two programs were carving out their respective niches.
I dislike Word, but I positively hate FrameMaker. Mainly I hate its user interface, which is like the GUI version of EMACS -- it pays lip service to menus and toolbars, but it still assumes that a real user has memorized all the keystrokes. Unfortunately, FrameMaker will remain dominant in tech pubs for my lifetime. I had hopes that competing XML editors would grab away market share, but the only one that came close was XMetal, and Corel seems bent on destroying that one.
Actually, FrameMaker does a semi-decent job of authoring structured markup -- provided you have a prepackaged XML or SGML application for it to use. It comes with ones for a subset of XHTML and an obsolete version of DocBook. Anyting else, be prepared to spend money on a consultant, because developing FrameMaker structure definitions is a nightmare.
Example: I once worked for a software company that was known for hiring really, really smart people. A lot of whom were very good writers -- I'm forced to admit that many of them were better than me, in the sense that they could turn out lucid, interesting prose. But they simply didn't understand the practical problems of explaining technical procedures to people.
Once, I was tasked with documenting a package that was basically a patch on another product. There was a central engine in the form of a DLL, and installing the package meant first installing the original product, then extracting the replacement DLL from a ZIP file and putting it in the correct directory so the original product could be made to load it in place of the default engine. Should have been done with an installer, of course, but for various reasons this wasn't possible.
So, I sat down and wrote a careful, nit-picky explanation of how to do all this. I carefully explained how to extract the file on the command line using info-zip (winzip didn't have its current dominance at the time, and info-zip was easy to obtain) with enough generalities so the user could adapt the procedure to another archiver.
I was not allowed to include this procedure in the release notes. The engineers felt it made the product look bad, like we didn't trust the users to figure out a more elegant explanation.
I ended up quitting that project because I just wasn't doing anything, except repackaging the prose of the engineer who grabbed my job away from me. He was actually quite a good writer -- he just didn't understand how easily written procedures can be misunderstood. As, in fact, his mostly were.
I've never really looked at academic programs for tech writing. They didn't exist when I was in school, and most tech writers are still people who've drifted in from other professions. I've worked with several people who've bailed out of an academic career, and only one of them was in Computer Science. (Physicists seem to be pretty common for some reason.) The fact is, technical communication is a simple, pragmatic discipline. If you want formal training in it, you might actually be better off going to a certificate program at a community college. If it's a good one, it'll be taught by serious, working writers, who will teach you a lot more than academicians.
Not to discourage you from getting that Masters. First, it always carries weight, no matter what you get it in -- you'll simply make more money because you have it. And if you're not totally mercenary, you can consider that a good masters program (and do remember that there are lots of bad ones) will teach you how to do research and explain your ideas. But for that purpose, I'd have more faith in a degree in Literature or History than one in Technical Communication.
On the other hand, you might consider simply plunging ahead. If you're conspicuously smart, know technology, and write real good, you can probably get an entry-level job right now. Pick up a few books (Joan Haxos is good, if a little patronizing) and learn as you go.
Damned if I know what it is. My best guess is that the industry just doesn't understand what good documentation is. Usually, the only measure of quality is completeness. If you've got an entry in the printed index or a keyword in the helpfile that covers every single feature, or API call or whatever, then supposedly you have a high-quality manual.
Which, of course, has nothing to do with the user's needs. It's not enough to talk about it. You have to put the information in a form people can find and use. It's not enough to have a keyword/index entry, you have to have the right one. It's not enough to describe every feature, you have to give a description that's readable, that explains why you're interested in the feature, how the feature relates to other features and to tasks the user might want to do.
But nobody gets this, so a lot of software products come with big fat manuals that nobody reads -- that aren't even meant to be read! They're just there so nobody can complain that everything isn't documented. And of course any idiot can write that kind of documentation.
Of course, there are companies that take good documentation seriously, and realize that it adds value to the product. They try to hire good tech writers and do good documentation. And yes, there are good tech writers out there. I sometimes persuade myself I'm one of them.
Speaking of which, anybody want to give me a job? (API writer, documented thousands them, can read every programming language you know about, and some you don't.) My big problem is that I kind of forgot to finish my BA. Which didn't use to be a fatal problem -- just a little harder to get hired at the best places. But now there's a surplus of "qualified" talent, and the gatekeepers just filter me out.
Answer a really important question: does Drop Bear Repellent actually work, or is it just a scam?
Seriously, though: Dude, lighten up. You never said something in a clumsy way? Slashdot isn't the fucking Times of London, it's a bunch of people having a conversation. When people are having a conversation, formalities are not essential. Little slips of the tongue are deserve a little good-natured kidding, nothing more.
Or as Miss Manners would say, Get a Fucking Life!
Plan 9 isn't wishful thinking. It isn't even dead -- in order to be dead, you have to be alive at some point. Plan 9 appeared about 10 years ago, as a platform for various advanced OS concepts that evolved out of similar concepts in Unix. It's never found a real following, and really has neither past nor future.
What's really pathetic is that anybody would be interested enough in Plan 9 to actually install it, but so clueless about its current state, they can't even answer "Is there a third party X for Plan 9" without having their hand held. But not as pathetic as Cliff thinking such a clueless question is worthy of anybody's time.
Location of the binary is an implementation detail -- something isn't "more-OSy" just because it's in ROM. Besides, the very early MacOS wasn't a real OS -- like DOS, it was just a glorified loader. The fact that it was dressed up with a GUI actually supports my argument.
You haven't had sex recently, have you?
A "gui-based OS"? A GUI is just a layer on top of the OS. If you want to form any worthwhile opinion about an OS, you're going to have to dig a little deeper than that.
It's also true.
Actually, some wolves get most of their protein from mice. Check out Never Cry Wolf by Farley Mowat.
And thanks to the web, there's no excuse for not reading it.
You're going to ask me about weight. If you shrink an elephant to the size of a mouse, does it fall through the floor? Don't ask me, what do I know?
Anybody remember the 60s movie Fantastic Voyage, where they shrink a bunch of people and inject them into a guy's blood stream so they can fix a blood clot? They actually hired Isaac Asimov to write the novelization, and of course he insisted on dealing with all the Bad Science issues in the screen play. One thing he did was have the injectonauts go to a lot of trouble to get the wreckage of their submarine out of the body, 'cause of course it'll be a mess when it expands. Or maybe this was in Bixby's original screenplay. In any case, the movie just ignored this problem. The studio wasn't going to spend a lot of money on a detail that most of the audience wouldn't care about anyway.
And that's why movies have so much bad science. Good science is expensive, it's distracting, and nobody cares about it anyway. I've pretty much given up on movie SF.
This is about support, nothing more. I'm suprised how many Slashdotters don't understand the costs of adding support for a platform to a product. I've worked on major projects where it was a big deal that we supported three platforms, and the choice of the third platform was a matter of major infighting. And this was in big companies with a lot of cash to throw around. I'm suprised that stamps.com has the resources to support two platforms.
Which begs the question, "Why is this important enough for an Ask Slashdot?" The last I heard of Plan 9 was a story on Slashdot about Plan 9 running on an embedded virtual machine, so it could run applications under a web browser, rather like Java applets. Nothing came of that either.
Incidentally, if you have Netscape or Mozilla, and use this option, you're not keeping graphics out of your inbox -- you're just keeping downloaded graphics out. It's still possible to reference graphics attached to the message.
Anyway, didn't we start out arguing over rich text in email? Even if I can't have downloaded graphics, I still want rich text.
I just thought of something really nasty I want to do. Find a server that's downloading tracking graphics, and saturate them with requests. Not a DoS attack, I don't care for those. Just a lot of requests making it very difficult to analyze their server log. All the files in the tracking list of course. But also a lot of random stuff.
Why did Microsoft throw all that money at Corel? OK, the official reason, to subsidize Corel's .NET efforts, isn't very plausible. But neither is the idea that they thought WordPerfect was any threat to them. Especially not Linux WordPerfect. My own guess is that this was a quid pro quo for Corel settling its patent lawsuits against Microsoft. By paying Corel off with an "investment", Microsoft avoids some taxes on the money. They did precisely the same thing with Borland -- before Borland started work on its Linux IDE!
You're right, I hadn't heard of that one before, and I thank you for telling me about it. The fix is to configure your client not to download external graphics. I'm going to do that right now!