AbiWord is my favorite word processor. It was so much less bloated than any other graphical option. I wrote pretty much all of my papers in college with it. It reminded me of my previous favorite from my youth: Claris Word.
Glad to see it's still alive. Updating to C++11 should make it a lot more appealing for new contributors.
I used it back when OpenOffice was just too slow and bloated to use very well on most computers I owned ~10 years ago and earlier. But through a combination of improved OpenOffice/LibreOffice performance and faster computers, I finally drifted away from AbiWord. For one, I still had to install OpenOffice for PowerPoint type work, so it was there anyway and it usually kept up with MS format compatibility better than AbiWord. I think the last straw for for leaving AbiWord behind completely was the Novell(?) patches that made OpenOffice feel more at home on Linux and stop sticking out like a sore thumb(and I think those were the same patches that led to the LibreOffice fork when Sun/Oracle wouldn't accept them).
StarOffice 5.1 run fine on a Pentium 133MHz on Win95. It come from a German company which got bought buy Novell and rebranded and open sourced as OpenOffice 1x.
Comparing StarOffice 5.1 and LibreOffice 4, lottle has changed. Well, the same can be said between Office 97 and Office 2016. The office suits were already feature complete in the late nineties, and conceptional issues still plague us 20 year later, as those programs saw only increamental improvements. While StarOffice was in good shape, OpenOffice was always in more rough shape, but nowadays LibreOffice cares more to deliver a more polished UX.
Star Division was bought by Sun Microsystems (later bought by Oracle). I was there, then.
That's the original reason we have Oracle OpenOffice: Open Office part derived from Sun's OpenOffice; the Oracle part the reason for the split between LibreOffice and OpenOffice. ;-)
SuSE/Novell had a license deal with Microsoft. MS sold SuSE Linux and Novell added improved Office format and VBA compatibility to their OpenOffice fork.
IBM forked OpenOffice for their Lotus suite. IBM Lotus Symphony.
Star office 5.1 could run on pretty limited hardware, but honestly it's a stretch to describe it as feature complete. That was the bad old days when I had to boot into windows to get most non coding work done.
Read the section "Components" incl "Older discontinued components" and "Proprietary components"!
StarOffice up to v5.2 was amazingly feature full and feature complete. Newer StarOffice and OpenOffice/LibreOffice forks lost some functionality and contain incremental improvements.
StarOffice 5.1 come even with its own Windows shell for Win95, that showed the Windows desktop icons, etc. (similar to what IE4 did with Win95, it came with a free shell upgrade, then it looked like Win98)
I used AbiWord years ago, and do recall it being pretty lean.
I get sort of the same feeling, these days, from Apple's Pages, though I'm not sure whether that's true. (Looking at the copy of it I have sitting around, the application bundle is 418MB, with 344MB of that being taken up by the Resources (icons, UI elements, translation strings) and SharedSupport (themes, templates) folders, leaving the app itself sitting at ~75MB. Not too bad, I suppose.)
One thing I think more people should consider, though, is how much of what they use a word processor for that could really just be accomplished using a rich text editor such as WordPad or TextEdit. Now those are light programs!
(And honestly, limiting yourself to unstructured rich text for the composition stage of a document is probably for the best. It keeps you on task, for one thing. But beyond that, anyone who has only used word-processors is missing out on the extremely natural workflow of separately doing your composition (in a rich text editor) and your document layout (in a desktop publishing program, like Publisher or InDesign) and then taking the finalized rich text and linking it to a text-region-chain on the layout document. It's so much easier to make your document look good when your text isn't changing any more.
I totally agree. I stayed on WordPad with RTF and TXT files for as long as I could. Everything was so lightweight with it also easier to sandbox that sucker and similar editors.
Far as AbiWord, I last put it on my Mom's old laptop because it ran way faster than other Windows 8 stuff she had. She absolutely loved it because it had just what she needed, loaded instantly, and was lightening fast in general.
Apple Pages is a toy. It's missing some pretty basic features like even/odd page margins, and becomes annoyingly slow once you do stuff like tables inside multiple columns. I recently prepared a pretty complex but not very long document using it and the experience was pretty unpleasant.
A manual typewriter is even better for this. You really lose the temptation to constantly go back and fiddle with what you're writing when fiddling involves hammering through retyping the whole page
I edited a news-stand magazine for six years using TextEdit. My job was the words, and TextEdit did that fine. When the words were complete, I passed the .rtf over to the designer who made it all look beautiful in InDesign. Word would have provided nothing extra I needed, and a lot of distractions that just get in the way. (I still use TextEdit for my freelance writing work.)
Both part of "Gnome Office" along with a few other applications as native GTK+ office applications. Though I guess it's probably be more of a collection than a well connected suite like MS Office, LibreOffice or even whatever KOffice is called these days.
The GNOME project decided not to be serious with GNOME Office years and years ago.
Imagine if they had put their effort into it though? Almost certainly they would have been at the forefront of desktop options and a good likelihood as a candidate for corporations.
You know it is hard to order people to do something when they aren't paid. Even project like OpenOffice.org that had commercial venture had hardship with funding. Oracle cancelled it, Novell cancelled it, IBM do whatever they want, etc.
All in all, GNOME Office didn't happen. Some bits did, though. AbiWord was always broader than GNOME. And Gnumeric is great IMHO.
Except there was a group of people who did want to do it - Abi was a company at one point! But the Gnome guys decided to deemphasise it - that was the problem.
It became clear to me that there isn't any money to be made in desktop FOSS software, as most users either pay for their tools, or end up pirating or using FOSS software if they don't plan to spend any money.
Desktop software just isn't the same as sellling consulting, trainings or SaaS licenses behind browser paywalls that server based software enjoys.
I thought ClarisWorks was the suite, and Claris Word was the name for the word processing component? I could be misremembering, of course. I haven't used it in 20 years or so.
ClarisWord never existed — ClarisWorks was the product. Claris had MacWrite II for a time because they were the software spin-off from Apple, and that was their stand alone word processor offering, not much better than Claris Works, which was one application unlike MS-Office.
If you think cross platform development is bad now, go back to the late 90s or early 2000s... this brought back some painful memories. Look at the old Mozilla C++ guidelines for more cringe-worthy stuff.
I thought Qt was a bit conservative, but then I read the wxWindows API (late 90s).
Single platform often wasn't that much better, though. The awefulness of MFC was one big reason why Delphi was so popular.
I mean yes, I totally agree that the late 90s were really bad for portable C++ development. You couldn't trust the compilers, you had limited faith in the libraries, rewriting the container classes yourself and falling back on C idioms were commonplace. Man, we really had no idea who owned which pointer back then.
But there was a sweet spot around 2006, when with C++ and Qt4 you could reach every major desktop platform with a single codebase with essentially identical UIs bar the detailed widget rendering, and you could do it using code that was still largely acceptable to work with. I did a fair bit of successful work that way.
Then the iPhone came along, and a platform explosion, incompatible managed-code platforms, many different input and output devices to support, more variety in UI design styles, the world of walled gardens and having to recreate the UI layer again and again for each company's devices. Now that's settled down a bit, and instead we have the paralysis of choice among piles of UI/back-end languages and frameworks all with their own tradeoffs.
There are more platforms today, but the tools are much better. Maybe it's a wash.
In terms of platform sprawl I feel like we're back to the 1980s when there was Apple II, Mac, IBM PC, IBM clones (not always compatible), TRS-80, Commodore 64, etc.
People laugh at me but as I work mostly in Java I don't have many cross-platform bugs. The best I had with C++ cross-platform was Qt but even that has weird issues which are a real pain to track down sometimes.
I really loved AbiWord in the early 2000s.
However, the fact that they refused to default to ODF meant I switched away. Who's going to store important documents in a format that only AbiWord can read.
Still though, it's got many advantages over the LibreOffice bloat.
Always liked using Abiword on Linux, but the Windows version seemed quite buggy last time I tried it. IIRC Abiword could read and write in (some) .doc format, though that was not the default native format. Come to think of it, a decade or so ago, access to .doc files was a major reason to use Abiword on non-Windows platforms. It will be good to see it working again.
It can read .doc. Never write. When it writes .doc it is actually writing RTF. A kludge, but this is better than always explaining users that saving as .rtf will be fine. And Word did that for a while part of a feature that was removed in an update. The only things were this didn't work is for some proprietary CMS that supported .doc but not .rtf.
I'm personally not super happy about that, but it is still much better than not doing it.
I loved AbiWord's file format. It was literally a basic html file, so I could confidently store anything in it and know I could read it later, much easier than any ODF.
Very nice to see activity on Abiword. The enthusiasm of the author is evident.
Abiword does have support for ODF, but it could be better. Abiword 3 uses ODF 1.1. At the last ODF plugfest quite some issues were found [1, end of page].
There are now automatic tests than can be run to improve ODF support. The tests can be run from the command-line and give output as HTML [2].
Currently, there is a project underway that makes it possible to run the tests on a public test server which will show live results.
hub asks for tests in his blog post. For loading, saving and rending ODF files, the ODF community can help.
It is not "refused". It is just not a trivial undertaking and with even more limited resources now, it is even less easy.
Just switching to ODF as a default format wouldn't have been a good idea, the difference in data models would have caused problems. I have in mind that to do that we'd have to change the internal model for things like list and tables to not have to convert them back and forth each time with losses.
This is a sad fact of the reality.
BTW one of the glorious hackers from the "LibreOffice side" has implemented a LibroOffice filter to read AbiWord documents.
Happy to see AbiWord, the first open-source project I was part of, continuing to do things the right way. The cross-platform approach in AbiWord has always been committed to quality over convenience, and I'm glad that's continuing.
I'm not sure this will go the way one would want. There is nobody to do Windows and the Mac port has also fallen behind. I'd rather continue the bootstrapped Qt port in parallel to Gtk and use that.
It helps okay. I recently used it to slowly and mostly automatically introduce more and more C++11 across a bigger code base. For example it does a great job introducing nullptr [0] and an okay job turning classic for loops into range based for loops [1] where possible.
I liked AbiWord. It was very lean and GTK+ friendly. But I always had little gotchas with the formatting and problems with ODF occurring between word processors that didn't occur as often when originating from LibreOffice. It had the clean/snappy interface that LibreOffice should have had, but definitely not the document feature support it needed.
These days, I'm not sure why anyone would bother trying to revive AbiWord. Not that I don't have my fair share of software engineering projects that are specific to my interests, but I personally wouldn't go back to using it or LibreOffice. If I really need a full-blown word processor, Google Docs does everything I need, and their Chrome app works for offline use. Most of the time, I can get away with writing stuff in Markdown. Then again, I'm a developer so that appeals to me. Microsoft Word online also works well cross-platform. With either one, you may not get the best multi-format support, but they're both very dependable IMO. I couldn't depend on AbiWord most of the time unless I knew the same doc would be opened in another AbiWord instance.
Web-based technology really is, I think, the best way forward in cross-platform development for things like word processing which are not CPU intensive. People can and should use whatever tools they want to get the job done but, if I was to start a new Linux/CP word processor today, I'd be using Node.js with Babel and make it "Web Native". For some things you'll want C++ but, for me, not this. But best of luck to them for sure.
Microsoft Office and Google Docs are examples of applications that require internet access and report information about the user to the software provider. That provider in turn can share that information with advertisers. That is a trade-off that not everybody is willing to make.
There are applications like Etherpad, WebODF (supplied with packages like ownCloud) that make it possible to work from the browser but on a server that you can choose. Even desktop applications can be used in this way via LibreOffice Online or open365.io.
This is something I think about a lot. No matter how much time we spend on software design and doing things "right", in 5 years it's all going to get thrown out by someone who thinks the codebase needs "modernizing".
It's actually a bit reassuring to me. Things only having a 5 year lifespan means you shouldn't spend a lot of time worrying about them. Code is meant to be disposable, and the less we treat it so, the more we hold ourselves back.
If we treat software as permanent, we hold ourselves back from making risky changes that wreck it.
If we treat software as temporary, we hold ourselves back from worthwhile improvements that will have enduring value, especially if they are fairly difficult.
61 comments
[ 3.2 ms ] story [ 135 ms ] threadGlad to see it's still alive. Updating to C++11 should make it a lot more appealing for new contributors.
Comparing StarOffice 5.1 and LibreOffice 4, lottle has changed. Well, the same can be said between Office 97 and Office 2016. The office suits were already feature complete in the late nineties, and conceptional issues still plague us 20 year later, as those programs saw only increamental improvements. While StarOffice was in good shape, OpenOffice was always in more rough shape, but nowadays LibreOffice cares more to deliver a more polished UX.
That's the original reason we have Oracle OpenOffice: Open Office part derived from Sun's OpenOffice; the Oracle part the reason for the split between LibreOffice and OpenOffice. ;-)
SuSE/Novell had a license deal with Microsoft. MS sold SuSE Linux and Novell added improved Office format and VBA compatibility to their OpenOffice fork.
IBM forked OpenOffice for their Lotus suite. IBM Lotus Symphony.
Read the section "Components" incl "Older discontinued components" and "Proprietary components"!
StarOffice up to v5.2 was amazingly feature full and feature complete. Newer StarOffice and OpenOffice/LibreOffice forks lost some functionality and contain incremental improvements.
StarOffice 5.1 come even with its own Windows shell for Win95, that showed the Windows desktop icons, etc. (similar to what IE4 did with Win95, it came with a free shell upgrade, then it looked like Win98)
I get sort of the same feeling, these days, from Apple's Pages, though I'm not sure whether that's true. (Looking at the copy of it I have sitting around, the application bundle is 418MB, with 344MB of that being taken up by the Resources (icons, UI elements, translation strings) and SharedSupport (themes, templates) folders, leaving the app itself sitting at ~75MB. Not too bad, I suppose.)
One thing I think more people should consider, though, is how much of what they use a word processor for that could really just be accomplished using a rich text editor such as WordPad or TextEdit. Now those are light programs!
(And honestly, limiting yourself to unstructured rich text for the composition stage of a document is probably for the best. It keeps you on task, for one thing. But beyond that, anyone who has only used word-processors is missing out on the extremely natural workflow of separately doing your composition (in a rich text editor) and your document layout (in a desktop publishing program, like Publisher or InDesign) and then taking the finalized rich text and linking it to a text-region-chain on the layout document. It's so much easier to make your document look good when your text isn't changing any more.
Far as AbiWord, I last put it on my Mom's old laptop because it ran way faster than other Windows 8 stuff she had. She absolutely loved it because it had just what she needed, loaded instantly, and was lightening fast in general.
Also Apple has abandoned it. Last update was 5 months ago.
Of course, Word 5 is still the gold standard, as far as I'm concerned. :)
I edited a news-stand magazine for six years using TextEdit. My job was the words, and TextEdit did that fine. When the words were complete, I passed the .rtf over to the designer who made it all look beautiful in InDesign. Word would have provided nothing extra I needed, and a lot of distractions that just get in the way. (I still use TextEdit for my freelance writing work.)
Imagine if they had put their effort into it though? Almost certainly they would have been at the forefront of desktop options and a good likelihood as a candidate for corporations.
All in all, GNOME Office didn't happen. Some bits did, though. AbiWord was always broader than GNOME. And Gnumeric is great IMHO.
And people see the future in the cloud.
And Abi as a company was long gone by that time.
Desktop software just isn't the same as sellling consulting, trainings or SaaS licenses behind browser paywalls that server based software enjoys.
But yes, I'm aware of the history of the product.
ClarisWord never existed — ClarisWorks was the product. Claris had MacWrite II for a time because they were the software spin-off from Apple, and that was their stand alone word processor offering, not much better than Claris Works, which was one application unlike MS-Office.
I mean yes, I totally agree that the late 90s were really bad for portable C++ development. You couldn't trust the compilers, you had limited faith in the libraries, rewriting the container classes yourself and falling back on C idioms were commonplace. Man, we really had no idea who owned which pointer back then.
But there was a sweet spot around 2006, when with C++ and Qt4 you could reach every major desktop platform with a single codebase with essentially identical UIs bar the detailed widget rendering, and you could do it using code that was still largely acceptable to work with. I did a fair bit of successful work that way.
Then the iPhone came along, and a platform explosion, incompatible managed-code platforms, many different input and output devices to support, more variety in UI design styles, the world of walled gardens and having to recreate the UI layer again and again for each company's devices. Now that's settled down a bit, and instead we have the paralysis of choice among piles of UI/back-end languages and frameworks all with their own tradeoffs.
Still, at least C++ is a nicer language now.
In terms of platform sprawl I feel like we're back to the 1980s when there was Apple II, Mac, IBM PC, IBM clones (not always compatible), TRS-80, Commodore 64, etc.
On Android, it involve doing JNI + Java and cross compiling the AbiWord engine. Something like what Firefox for Android is doing.
But neither is in the pipe.
It was just a nod a reading stuff with a second set of eyes (ie code I didn't write).
I'm personally not super happy about that, but it is still much better than not doing it.
Images are also PNG, JPEG and SVG. Formulas are MathML.
Styling uses the same properties as CSS, but the are written in XML instead of using the CSS syntax.
The ODF Essentials book is good introduction to the format. http://books.evc-cit.info/odbook/book.html
Abiword does have support for ODF, but it could be better. Abiword 3 uses ODF 1.1. At the last ODF plugfest quite some issues were found [1, end of page].
There are now automatic tests than can be run to improve ODF support. The tests can be run from the command-line and give output as HTML [2].
Currently, there is a project underway that makes it possible to run the tests on a public test server which will show live results.
hub asks for tests in his blog post. For loading, saving and rending ODF files, the ODF community can help.
[1] http://odfplugfest.org/2015-thehague/report.html [2] http://autotests.opendocumentformat.org/
There is a long list of bugs from every side.
Just switching to ODF as a default format wouldn't have been a good idea, the difference in data models would have caused problems. I have in mind that to do that we'd have to change the internal model for things like list and tables to not have to convert them back and forth each time with losses.
This is a sad fact of the reality.
BTW one of the glorious hackers from the "LibreOffice side" has implemented a LibroOffice filter to read AbiWord documents.
[1] http://clang.llvm.org/extra/clang-tidy/
[0] https://github.com/swift/swift/commit/eddd92ed76ae68cb1e2026... [1] https://github.com/swift/swift/commit/3c560e31b0f168da917e8d...
These days, I'm not sure why anyone would bother trying to revive AbiWord. Not that I don't have my fair share of software engineering projects that are specific to my interests, but I personally wouldn't go back to using it or LibreOffice. If I really need a full-blown word processor, Google Docs does everything I need, and their Chrome app works for offline use. Most of the time, I can get away with writing stuff in Markdown. Then again, I'm a developer so that appeals to me. Microsoft Word online also works well cross-platform. With either one, you may not get the best multi-format support, but they're both very dependable IMO. I couldn't depend on AbiWord most of the time unless I knew the same doc would be opened in another AbiWord instance.
Web-based technology really is, I think, the best way forward in cross-platform development for things like word processing which are not CPU intensive. People can and should use whatever tools they want to get the job done but, if I was to start a new Linux/CP word processor today, I'd be using Node.js with Babel and make it "Web Native". For some things you'll want C++ but, for me, not this. But best of luck to them for sure.
There are applications like Etherpad, WebODF (supplied with packages like ownCloud) that make it possible to work from the browser but on a server that you can choose. Even desktop applications can be used in this way via LibreOffice Online or open365.io.
It's actually a bit reassuring to me. Things only having a 5 year lifespan means you shouldn't spend a lot of time worrying about them. Code is meant to be disposable, and the less we treat it so, the more we hold ourselves back.
If we treat software as temporary, we hold ourselves back from worthwhile improvements that will have enduring value, especially if they are fairly difficult.
That's what we said in the 80s when we were using two-digit date fields.