In order to be scared, one should know if what the author did was a good decision at the time (tm) or not. I'd have to see the before and after pictures, and take into account that the "after" picture the author was aiming for might still be a little ways down the road. I'd have to know the rationale and a lot more about those 10 random projects than I'd probably be able to garnish from changelogs, mailing lists, and CVS histories alone. And all of this assumes that freshmeat and SourceForge are good barometers for this sort of data - which I'm not entirely convinced that they are. And that's my point.
What would be more convincing is something more concrete than anecdotal, off-the-cuff divinations. Though we may not agree with all of his conclusions in "The Mythical Man Month," no-one contests that Herb Brooks spoke with a large measure of firsthand experience and data to support his claims. Your article, at least as presented here, has none.
Maybe your next attempt won't be perfect, but I think that there's some credence to the adage that "one learns from one's mistakes." If we do not learn from the past, we're doomed to repeat it.
For example, I was careless when I was 16. Now, I'm 24, and I don't make 16-year-old types of mistake any more. There's some amount of wisdom that comes with experience and the right attitude. This carries over to code discipline as much as it does with (for example) driving.
Throwing away code blindly is a mistake, especially if it is working code. Then again, keeping crufty, bad code around is an equally large mistake. The larger point that Chromatic misses is that making uninformed code decisions is playing Russian Roulette. Throwing away code (or keeping code around) is only a mistake when one has no concrete rationale for doing so.
The important part is to have a good understanding of the problem scope, previous attempts (if any) at solving the problem, and what their advantages and drawbacks are.
You have to remember that code doesn't exist for code's sake alone. We write code to solve problems. Code is a window into how someone solved a problem. And not all solutions are created equal.
What is important is to understand the "whys" and "hows" of these previous attempts, and then chart the best course you see toward success. It may well be that the best solution is to scrap another's design. It may be the best solution to build off of another's success. However, it's probably a bad decision to build off of another's failures.
While I'm agreed that the best way to write good software is to not introduce bugs in the first place, I don't believe that this is an entirely avoidable problem.
There are certain types of necessary changes that inherently destabilize a codebase no matter how careful you've been. It's inevitable. Oftentimes, things like this are checked in to amortize the cost of producing, fixing, and improving said code. There are the unforseen interactions that your new subsystem has, that none of the regression or unit tests have picked up. I know - "write more/better tests" is a better solution. But omnipotence is an impossible goal.
To continue the author's "home" anology, relasing software is like preparing a meal. The pots and spoons simply must get dirty when you're cooking. Many try to "clean as you go," but at the end, you're still left with your dirty casserole dish. You can either choose to clean things up before your guests get there (feature freeze), or you can leave the dirty dishes lying on the counter for all to see.
I might be inclined to say that the shorter the feature freeze, the better. But I don't have any evidence to back this up - nor does Chromatic cite any evidence (except antecdoctal) to support or detract this claim. Maybe people by nature are better at fixing a slew of bugs at once. Maybe not.
Freezes, milestones (alpha, beta) and the like are inevitable parts of producing quality software fit for public consumption, short of "papal infallibility." We're only human.
Perhaps. But how many of these US commercial "standards" have the full measure and effect of a *government mandate* for adoption? Oh, that's right - none do. And with 1.3 billion potential (read: mandated) adopters, that's a wee bit more than just a "drop in the bucket."
Sun spent a bunch of time and money toward usability studies and such, which ultimately contributed toward the GNOME "HIG" (Human Interface Guidelines). More info available at:
It's wrong to think that PDFs are non-harmful. PDFs can have embedded javascript inside of them, and can embed arbitrary things like EXEs inside of them too. It's trivial to set the/OpenAction of a document to a particular java script, which then executes the embedded worm/virus inside of the PDF file. Or "format c:\", etc...
My old company, www.appligent.com, wrote a tool to work around this. I'd feel negligant if I didn't inform you about APActiveCheck and APStripFiles. APStripFiles is free ($).
http://www.appligent.com/products/applications/u ti lities/appligent_utilities.html http://www.applig ent.com/products/free_product_lis t.html
Actually, I wish that they would use Enchant, so that they could let the user decide what spellcheckers to work with. This also lets them continue using and distributing MySpell if they so desire, as Enchant's MySpell backend is top-notch.
As a writer of Free Software and a party to one of these legal actions, I prefer to think of the FSF more of a lobbyist group rather than hit men. This organization serves to protect my interests and copyrights where I have very limited resources to do so myself. They're standing up for the little guys. As such, it would be more accurate and appropriate to compare them with organizations like the ACLU rather than gangsters.
The FSF does not bait companies to incorporate GPL code into their own. Companies do so of their own free will and accord, and do so in spite of the well-known and well-understood GPL license. By doing so, companies like Linksys have violated the author's copyright. They have no more license to steal his/her works in violation of copyright than I do to steal "Ja Rule" songs on Kazaa. And at 400,000 units sold this quarter alone, they stand to benefit far more so from their copyright infringement than I do from downloading music. Consider that at $129 per unit, Linksys has made $51,600,000 more dollars from this code than the author him/herself has.
What's worse still is that, oftentimes, writers of GPL software are willing to re-license their code under a commercial license if provided with the correct incentive.
Messy litigations like this are always avoidable, as corporations always have at least three alternatives:
1. Don't violate another person's copyright; don't be lazy, write your own code 2. Negotiate some sort of commercial license with the author 3. Respect the author's license and release your derived work under the GPL as well
Companies like Linksys have broken the law by violating the author's copyright. As such, they deserve to be punished. No-one deserves to benefit from their own criminal acts. The FSF are our sheriffs. And I, for one, appreciate the job they do patrolling our corner of the 'net.
That's only completely valid if there can be a perfect translation from KWord's file format to OOo, or if Kword redesigns how it does certain things so that it matches OOo's expectations of the world. This is what I highly doubt, and I speak from some considerable experience when saying so.
Actually, we do have fairly decent support for the OpenOffice file format. It's just not the default file format, nor is it likely to be. If you're interested, please read:
Basically, while it makes sense for us to support the OOo file formats as best as possible, it is not desirable for us to make them the default file formats. If anything, RTF is a much better choice for this particular job, as I don't believe MS will be supporting the OOo file format anytime this century. However, both support RTF, and RTF is capable of preserving ~100% of the content and data that DOC is, albeit oftentimes more verbosely.
That said, it might make sense for upstream packagers (RedHat, Ximian,...) or individual users to change Abi's default file format to RTF or OOo to meet their needs. It's a matter of changing 1 line of code, or altering 1 line in a configuration file. It's intentionally easy.
This all boils down to different worldviews - Abi and OO won't ever have a 1:1 mapping of features, nor will we agree on how to represent those features in any single file format. The best you can hope for is "really close" conversions. Loss of content or presentation markup is unacceptable in a "native" file format.
IMO, the best solution is to all have a "common tongue", which may well be the OOo format, or say RTF. We should all use the common language when we want to speak to each other, and hope nothing gets lost or misinterpreted on either side during the translation (remember a translation from Abi -> KOffice using the OOo format as an "intermediary" has at least 2 points of failure instead of just 1). Unfortunately, that's all unavoidable. But when we're speaking "at home," we really want to speak our mother tongue. There's less ambiguity and a higher level of precision.
For those reasons, I don't think that the KOffice folks are necessarily making the best decision here, though I continue to wish them the best of luck and success.
There is a better way. I'm in the process of filing suit against a repeat GPL violator. The guys at the FSF are *extremely* happy and willing to help you through this. They're willing to provide legal assistance and even represent you throughout the process. Their goal is to free software, and to protect the rights of the free software that's out there.
If you have a problem, send Bradley Kuhn a quick email. He'll probably get back to you within a day or two. If things look naughty, you'll probably have a phone or in person conversation with him and/or Eben Moglen. I have.
Slashdot should be a last resort for these sorts of things. Mass hysteria and flamage is bad. The press is a powerful weapon that you should use - but only when it's the right time for it. Only use this if your other doors have been shut. Treat it like a doomsday device.
If you haven't contacted the FSF or the program/library's author about this, posting this to Slashdot is downright irresponsible and even reprehensible.
Couldn't agree more. Can't find a decent review by typing in "Toshiba DVD"? Type in "Toshiba DVD review". It's not amazing nor is it rocket science - through greater query specificity you get better results. "I'm feeling lucky" takes you to a site called "dvdreview.net". Google isn't flawed - Steven Johnson's expectations are.
Please see http://libwpd.sf.net/ - a couple of AbiWord hackers wrote libwpd, and then wrote an OOWriter plugin for it. Complete with screenshots and downloadable binary plugins.
Agreed. You can also take a look at a couple of my projects - wvWare and AbiWord </shameless-plug>, KWord, or any one of a number of similar products.
[abiword on unix] AbiWord --print=file.ps file.doc ps2pdf file.ps
KOffice 1.3 has a similar --print command-line argument.
[abiword on win32 - follow the instructions in the parent post. it'll work for abi or any other win32 program too]
[wv anywhere] wvPDF file.pdf file.doc
Both run well on Win32, OSX, Unix, QNX, and BeOS, which is a few more platforms than OO can currently boast. wvWare will even run on OS/390 and OS/2 with a little tweaking. Plus both can be run non-interactively from a command line or similar without a dedicated X connection, which is useful for server environments.
Most people don't know (or have forgotten) that OpenOffice isn't the only fee software office suite out there, nor is it necessarily the best one for all cases. It is a good one though, and do wish them continued success.
Companies that distribute sub-standard products deserve to have tarnished reputations. They deserve to feel some financial impact.
As a hypothetical, if I break a MasterLock lock by spraying water on it, run into a person's house and then re-arragne his/her furniture, I definitely deserve to be punished for Breaking&Entering and trespass. But MasterLock also deserves to feel the pinch in its wallet caused by consumer backlash, because it produced and sold an inferior product. This is how free market economies work.
If this company wants to un-tarnish its reputation, I believe the best thing is to quickly release an upgrade to the game servers that doesn't have this exploit. Sure, the criminals should be prosecuted. But as a first order of business, they must admit to their own culpibility, and produce a fix.
AbiConvert, like AbiWord, is licensed under the terms of the GPL. I'm not sure on the legalities of using GPL'd code in a plugin to a non-GPL product, such as MS Word.
AbiConvert supports all of the inputs and outputs that AbiWord does. This includes round-trip RTF and SXW support.
AbiWord and MSWord have top-notch support for RTF. OpenOffice is catching up in this regard. KWord has traditionally not been so good, though they recently rewrote a lot of their RTF code, so it has likely improved.
MSDN is the autoritative source for any information on the MS Office filter plugin system.
Unfortunately, the SXW file format isn't supported by MS Office currently by MSFT, nor do I see that changing in the near future. However, there are other formats which are good for document interchange/exchange. OO reads and writes DOC rather well; AbiWord and KWord read DOC well, and can read&write RTF.
That said, it wouldn't be terribly difficult to build a plugin for MS Word that allows it to support the SXW format, given some reasonable definition of "support." IIRC, the MS Word plugin API basically speaks RTF. One would have to write a SXWRTF converter for full read&write support.
A side project of AbiWord, AbiConvert, is basically our import/export filters hooked up to our Piece Table. It is a standalone application that converts XXXYYY. One might consider using this or the OO filters project to be the basis for such a plugin, if one were so inclined to do so.
As AbiWord's and wvWare's maintainer (and author of the DOC, RTF, and OpenWriter support in Abi), I'd just like to point out a few things in the parent post:
AbiWord can read and write the OpenOffice format to a large degree. I direct you to: http://www.abisource.com/lxr/source/abiword-plugin s/wp/impexp/OpenWriter/xp/
From experience, handling DOC and OpenOffice/OASIS SXW format aren't even comparable. SXW's format is much more intelligible to us humans and its documentation is much more complete and accurate than the DOC documentation.
In order to read/write DOC, you need specialized OLE2 libraries (libole2, libgsf, POI) and a deep knowledge of DOC and how it applies binary SPRM diffs to create the master document. There are no user-friendly or command-line type tools to create OLE2 files. OSS language bindings to OLE2 parsers are non-existant. A generic "MSWord file format" parsing/generation tool simply does not exist. SXW's XML format at least helps in this regard.
In order to read/write a SXW file, you need a Zip implementation (winzip, zip, libgsf, pkzip,...) and an XML parser. There are a plethora of both on the market for every flavour of OS and language you can imagine.
The end result? It's near-trivial to write a script to generate a SXW file as the output of a report, and say, serve it up on the web. It's near impossible to do the same with DOC, unless you're using a COM interface into Word on Win32.
The problem with the documentation on DOC is that MSFT pulled its documentation from MSDN and other sites, and is unlikely to ever release newer versions. The last oficially documented format was Word 97 (8), while we're at something like Word 11 now. Fortunately, the formats are similar enough for us to get by. OpenOffice's documentation, however, will always be available from openoffice.org. This is quite significant.
Granted, DOC is ubiquituous in the marketplace today, and we software vendors should do our best to inter-operate with all of the MS Wordies out there. I'd give it a few years, though - SXW is a very new format, and it's only natural that it take a bit of time for it to be widely adopted. But it is being adopted by GnomeOffice and KOffice, amongst others. I bet that you'll be seeing a lot more SXW files floating around the 'net. And this is a *very* good thing.
Actually, Gimp and AbiWord use FontConfig/Xft2 either directly or indirectly (read: transparently) now, as can any GTK2 application. I suggest you go get gimp 1.3.12 and AbiWord 1.1.4. Ximian's OpenOffice will use Xft2/Fontconfig as well. Expect that to be released _soon_
Having worked on these projects, I know all too well how bad it was. The font situation *was* deeply fragmented. Fontconfig made it all better. Let's not make it suck again. IMO, Sun would do better to simply support the Render extension on their XServers, or to improve the X backend to Xft2. It *can* be done. I'm dreading Sun's results. I'm afraid they've just made a lot more work for all of the users and hackers out there.
Slashdot Mirror
That fact alone shouldn't scare anyone.
In order to be scared, one should know if what the author did was a good decision at the time (tm) or not. I'd have to see the before and after pictures, and take into account that the "after" picture the author was aiming for might still be a little ways down the road. I'd have to know the rationale and a lot more about those 10 random projects than I'd probably be able to garnish from changelogs, mailing lists, and CVS histories alone. And all of this assumes that freshmeat and SourceForge are good barometers for this sort of data - which I'm not entirely convinced that they are. And that's my point.
What would be more convincing is something more concrete than anecdotal, off-the-cuff divinations. Though we may not agree with all of his conclusions in "The Mythical Man Month," no-one contests that Herb Brooks spoke with a large measure of firsthand experience and data to support his claims. Your article, at least as presented here, has none.
Dom
Maybe your next attempt won't be perfect, but I think that there's some credence to the adage that "one learns from one's mistakes." If we do not learn from the past, we're doomed to repeat it.
For example, I was careless when I was 16. Now, I'm 24, and I don't make 16-year-old types of mistake any more. There's some amount of wisdom that comes with experience and the right attitude. This carries over to code discipline as much as it does with (for example) driving.
Dom
Throwing away code blindly is a mistake, especially if it is working code. Then again, keeping crufty, bad code around is an equally large mistake. The larger point that Chromatic misses is that making uninformed code decisions is playing Russian Roulette. Throwing away code (or keeping code around) is only a mistake when one has no concrete rationale for doing so.
The important part is to have a good understanding of the problem scope, previous attempts (if any) at solving the problem, and what their advantages and drawbacks are.
You have to remember that code doesn't exist for code's sake alone. We write code to solve problems. Code is a window into how someone solved a problem. And not all solutions are created equal.
What is important is to understand the "whys" and "hows" of these previous attempts, and then chart the best course you see toward success. It may well be that the best solution is to scrap another's design. It may be the best solution to build off of another's success. However, it's probably a bad decision to build off of another's failures.
Dom
While I'm agreed that the best way to write good software is to not introduce bugs in the first place, I don't believe that this is an entirely avoidable problem.
There are certain types of necessary changes that inherently destabilize a codebase no matter how careful you've been. It's inevitable. Oftentimes, things like this are checked in to amortize the cost of producing, fixing, and improving said code. There are the unforseen interactions that your new subsystem has, that none of the regression or unit tests have picked up. I know - "write more/better tests" is a better solution. But omnipotence is an impossible goal.
To continue the author's "home" anology, relasing software is like preparing a meal. The pots and spoons simply must get dirty when you're cooking. Many try to "clean as you go," but at the end, you're still left with your dirty casserole dish. You can either choose to clean things up before your guests get there (feature freeze), or you can leave the dirty dishes lying on the counter for all to see.
I might be inclined to say that the shorter the feature freeze, the better. But I don't have any evidence to back this up - nor does Chromatic cite any evidence (except antecdoctal) to support or detract this claim. Maybe people by nature are better at fixing a slew of bugs at once. Maybe not.
Freezes, milestones (alpha, beta) and the like are inevitable parts of producing quality software fit for public consumption, short of "papal infallibility." We're only human.
Dom
Perhaps. But how many of these US commercial "standards" have the full measure and effect of a *government mandate* for adoption? Oh, that's right - none do. And with 1.3 billion potential (read: mandated) adopters, that's a wee bit more than just a "drop in the bucket."
Dom
Sun spent a bunch of time and money toward usability studies and such, which ultimately contributed toward the GNOME "HIG" (Human Interface Guidelines). More info available at:
http://developer.gnome.org/projects/gup/
There's a wealth of information under there. The Sun studies, conducted in March 2001, can be found here. I wouldn't be too "worried" if I were you.
It's wrong to think that PDFs are non-harmful. PDFs can have embedded javascript inside of them, and can embed arbitrary things like EXEs inside of them too. It's trivial to set the /OpenAction of a document to a particular java script, which then executes the embedded worm/virus inside of the PDF file. Or "format c:\", etc...
u ti lities/appligent_utilities.htmlg ent.com/products/free_product_lis t.html
My old company, www.appligent.com, wrote a tool to work around this. I'd feel negligant if I didn't inform you about APActiveCheck and APStripFiles. APStripFiles is free ($).
http://www.appligent.com/products/applications/
http://www.appli
Dom
Hate to nitpick - a liter is much closer to a quarter gallon (i.e. a quart) - 0.264172051 gal/liter.
A $5 per liter, that works out closer to $20 per gallon.
Dom
Actually, I wish that they would use Enchant, so that they could let the user decide what spellcheckers to work with. This also lets them continue using and distributing MySpell if they so desire, as Enchant's MySpell backend is top-notch.
Also, Enchant has a FreeDesktop.org endorsement, of sorts.
(disclaimer: I wrote Enchant, and thus am biased)
Don't be afraid to talk-back. I did.
i sp layArticleWebForm.cgi
http://www.expressresponse.com/cgi-bin/forbes/d
----
As a writer of Free Software and a party to one of these legal actions, I prefer to think of the FSF more of a lobbyist group rather than hit men. This organization serves to protect my interests and copyrights where I have very limited resources to do so myself. They're standing up for the little guys. As such, it would be more accurate and appropriate to compare them with organizations like the ACLU rather than gangsters.
The FSF does not bait companies to incorporate GPL code into their own. Companies do so of their own free will and accord, and do so in spite of the well-known and well-understood GPL license. By doing so, companies like Linksys have violated the author's copyright. They have no more license to steal his/her works in violation of copyright than I do to steal "Ja Rule" songs on Kazaa. And at 400,000 units sold this quarter alone, they stand to benefit far more so from their copyright infringement than I do from downloading music. Consider that at $129 per unit, Linksys has made $51,600,000 more dollars from this code than the author him/herself has.
What's worse still is that, oftentimes, writers of GPL software are willing to re-license their code under a commercial license if provided with the correct incentive.
Messy litigations like this are always avoidable, as corporations always have at least three alternatives:
1. Don't violate another person's copyright; don't be lazy, write your own code
2. Negotiate some sort of commercial license with the author
3. Respect the author's license and release your derived work under the GPL as well
Companies like Linksys have broken the law by violating the author's copyright. As such, they deserve to be punished. No-one deserves to benefit from their own criminal acts. The FSF are our sheriffs. And I, for one, appreciate the job they do patrolling our corner of the 'net.
Fastest? Maybe. Entirely compliant? Hah! In my dreams ;-)
Yes, the Gimp has stolen my RSVG plugin. No doubt Sven and Yosh have since souped it up.
Best regards,
Dom
That's only completely valid if there can be a perfect translation from KWord's file format to OOo, or if Kword redesigns how it does certain things so that it matches OOo's expectations of the world. This is what I highly doubt, and I speak from some considerable experience when saying so.
Dom
Actually, we do have fairly decent support for the OpenOffice file format. It's just not the default file format, nor is it likely to be. If you're interested, please read:
0 03 /Apr/0167.html/ abiword-dev/2003 /Apr/0183.html
...) or individual users to change Abi's default file format to RTF or OOo to meet their needs. It's a matter of changing 1 line of code, or altering 1 line in a configuration file. It's intentionally easy.
http://abisource.com/mailinglists/abiword-dev/2
http://abisource.com/mailinglists
Basically, while it makes sense for us to support the OOo file formats as best as possible, it is not desirable for us to make them the default file formats. If anything, RTF is a much better choice for this particular job, as I don't believe MS will be supporting the OOo file format anytime this century. However, both support RTF, and RTF is capable of preserving ~100% of the content and data that DOC is, albeit oftentimes more verbosely.
That said, it might make sense for upstream packagers (RedHat, Ximian,
This all boils down to different worldviews - Abi and OO won't ever have a 1:1 mapping of features, nor will we agree on how to represent those features in any single file format. The best you can hope for is "really close" conversions. Loss of content or presentation markup is unacceptable in a "native" file format.
IMO, the best solution is to all have a "common tongue", which may well be the OOo format, or say RTF. We should all use the common language when we want to speak to each other, and hope nothing gets lost or misinterpreted on either side during the translation (remember a translation from Abi -> KOffice using the OOo format as an "intermediary" has at least 2 points of failure instead of just 1). Unfortunately, that's all unavoidable. But when we're speaking "at home," we really want to speak our mother tongue. There's less ambiguity and a higher level of precision.
For those reasons, I don't think that the KOffice folks are necessarily making the best decision here, though I continue to wish them the best of luck and success.
Best regards,
Dom Lachowicz, AbiWord maintainer
Yeah, the resume is out of date, and I'm gainfully employed again. I'll update it eventually. Thanks, though.
As for the violated software, I'm not at liberty to divulge the accused party or the software in question. It's not AbiWord, though.
Dom
There is a better way. I'm in the process of filing suit against a repeat GPL violator. The guys at the FSF are *extremely* happy and willing to help you through this. They're willing to provide legal assistance and even represent you throughout the process. Their goal is to free software, and to protect the rights of the free software that's out there.
If you have a problem, send Bradley Kuhn a quick email. He'll probably get back to you within a day or two. If things look naughty, you'll probably have a phone or in person conversation with him and/or Eben Moglen. I have.
Slashdot should be a last resort for these sorts of things. Mass hysteria and flamage is bad. The press is a powerful weapon that you should use - but only when it's the right time for it. Only use this if your other doors have been shut. Treat it like a doomsday device.
If you haven't contacted the FSF or the program/library's author about this, posting this to Slashdot is downright irresponsible and even reprehensible.
Dom
Couldn't agree more. Can't find a decent review by typing in "Toshiba DVD"? Type in "Toshiba DVD review". It's not amazing nor is it rocket science - through greater query specificity you get better results. "I'm feeling lucky" takes you to a site called "dvdreview.net". Google isn't flawed - Steven Johnson's expectations are.
Please see http://libwpd.sf.net/ - a couple of AbiWord hackers wrote libwpd, and then wrote an OOWriter plugin for it. Complete with screenshots and downloadable binary plugins.
Dom
Agreed. You can also take a look at a couple of my projects - wvWare and AbiWord </shameless-plug>, KWord, or any one of a number of similar products.
[abiword on unix]
AbiWord --print=file.ps file.doc
ps2pdf file.ps
KOffice 1.3 has a similar --print command-line argument.
[abiword on win32 - follow the instructions in the parent post. it'll work for abi or any other win32 program too]
[wv anywhere]
wvPDF file.pdf file.doc
Both run well on Win32, OSX, Unix, QNX, and BeOS, which is a few more platforms than OO can currently boast. wvWare will even run on OS/390 and OS/2 with a little tweaking. Plus both can be run non-interactively from a command line or similar without a dedicated X connection, which is useful for server environments.
Most people don't know (or have forgotten) that OpenOffice isn't the only fee software office suite out there, nor is it necessarily the best one for all cases. It is a good one though, and do wish them continued success.
Dom
Companies that distribute sub-standard products deserve to have tarnished reputations. They deserve to feel some financial impact.
As a hypothetical, if I break a MasterLock lock by spraying water on it, run into a person's house and then re-arragne his/her furniture, I definitely deserve to be punished for Breaking&Entering and trespass. But MasterLock also deserves to feel the pinch in its wallet caused by consumer backlash, because it produced and sold an inferior product. This is how free market economies work.
If this company wants to un-tarnish its reputation, I believe the best thing is to quickly release an upgrade to the game servers that doesn't have this exploit. Sure, the criminals should be prosecuted. But as a first order of business, they must admit to their own culpibility, and produce a fix.
Which one is Steve Ballmer again?
AbiConvert, like AbiWord, is licensed under the terms of the GPL. I'm not sure on the legalities of using GPL'd code in a plugin to a non-GPL product, such as MS Word.
AbiConvert supports all of the inputs and outputs that AbiWord does. This includes round-trip RTF and SXW support.
AbiWord and MSWord have top-notch support for RTF. OpenOffice is catching up in this regard. KWord has traditionally not been so good, though they recently rewrote a lot of their RTF code, so it has likely improved.
MSDN is the autoritative source for any information on the MS Office filter plugin system.
Dom
Unfortunately, the SXW file format isn't supported by MS Office currently by MSFT, nor do I see that changing in the near future. However, there are other formats which are good for document interchange/exchange. OO reads and writes DOC rather well; AbiWord and KWord read DOC well, and can read&write RTF.
That said, it wouldn't be terribly difficult to build a plugin for MS Word that allows it to support the SXW format, given some reasonable definition of "support." IIRC, the MS Word plugin API basically speaks RTF. One would have to write a SXWRTF converter for full read&write support.
A side project of AbiWord, AbiConvert, is basically our import/export filters hooked up to our Piece Table. It is a standalone application that converts XXXYYY. One might consider using this or the OO filters project to be the basis for such a plugin, if one were so inclined to do so.
Dom
As AbiWord's and wvWare's maintainer (and author of the DOC, RTF, and OpenWriter support in Abi), I'd just like to point out a few things in the parent post:
n s/wp/impexp/OpenWriter/xp/
...) and an XML parser. There are a plethora of both on the market for every flavour of OS and language you can imagine.
AbiWord can read and write the OpenOffice format to a large degree. I direct you to: http://www.abisource.com/lxr/source/abiword-plugi
From experience, handling DOC and OpenOffice/OASIS SXW format aren't even comparable. SXW's format is much more intelligible to us humans and its documentation is much more complete and accurate than the DOC documentation.
In order to read/write DOC, you need specialized OLE2 libraries (libole2, libgsf, POI) and a deep knowledge of DOC and how it applies binary SPRM diffs to create the master document. There are no user-friendly or command-line type tools to create OLE2 files. OSS language bindings to OLE2 parsers are non-existant. A generic "MSWord file format" parsing/generation tool simply does not exist. SXW's XML format at least helps in this regard.
In order to read/write a SXW file, you need a Zip implementation (winzip, zip, libgsf, pkzip,
The end result? It's near-trivial to write a script to generate a SXW file as the output of a report, and say, serve it up on the web. It's near impossible to do the same with DOC, unless you're using a COM interface into Word on Win32.
The problem with the documentation on DOC is that MSFT pulled its documentation from MSDN and other sites, and is unlikely to ever release newer versions. The last oficially documented format was Word 97 (8), while we're at something like Word 11 now. Fortunately, the formats are similar enough for us to get by. OpenOffice's documentation, however, will always be available from openoffice.org. This is quite significant.
Granted, DOC is ubiquituous in the marketplace today, and we software vendors should do our best to inter-operate with all of the MS Wordies out there. I'd give it a few years, though - SXW is a very new format, and it's only natural that it take a bit of time for it to be widely adopted. But it is being adopted by GnomeOffice and KOffice, amongst others. I bet that you'll be seeing a lot more SXW files floating around the 'net. And this is a *very* good thing.
Dom
FYI, Phoenix/Firebird and Mozilla already have the ability to disable moving, resizing, raising, and lowering windows.
Dom
Actually, Gimp and AbiWord use FontConfig/Xft2 either directly or indirectly (read: transparently) now, as can any GTK2 application. I suggest you go get gimp 1.3.12 and AbiWord 1.1.4. Ximian's OpenOffice will use Xft2/Fontconfig as well. Expect that to be released _soon_
Having worked on these projects, I know all too well how bad it was. The font situation *was* deeply fragmented. Fontconfig made it all better. Let's not make it suck again. IMO, Sun would do better to simply support the Render extension on their XServers, or to improve the X backend to Xft2. It *can* be done. I'm dreading Sun's results. I'm afraid they've just made a lot more work for all of the users and hackers out there.
Dom