Modernizing AbiWord code
figuiere.net
figuiere.net
Glad 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'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.
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.
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.
[0] https://github.com/swift/swift/commit/eddd92ed76ae68cb1e2026... [1] https://github.com/swift/swift/commit/3c560e31b0f168da917e8d...
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.
It was just a nod a reading stuff with a second set of eyes (ie code I didn't write).