AbiWord 2.2 Unleashed

Thank you very much for your comments. One new feature that I'm very curious to hear what users think of is visual drag and drop of text.

1. Select text by dragging your mouse as usual.
2. Move your mouse over the text.
3. Now hold down the left mouse button and drag. The selection lifts out of the document and follows your mopuse.
4. Move the text to where you want to put it (the caret shows your where it goes) and release the left mouse button.
5. The text drops into the document.

For text copy hold down the shift key at step 3.

Cheers

Martin

... is really cool! Only remark is that I had to use ctrl instead of shift to copy. (I'm still on 2.1.96 in Debian)

Just like to add, that unlike the original poster, I was impressed with Abiword from day 1.

If I may suggest one thing, it would be to write a little article detailing the cross-platform/ui abstraction layer that seems to have worked so well for AbiWord. If you compare it to different approaches (wxWidgets, the Openoffice approach, the Mozilla approach) it really gives the most "native" results. What are the complexity or performance costs?

I seem to remember Abisource was going to go for a whole office suite a long time ago. Any chances of porting Gnumeric over to the ui abstraction Abiword uses, or is it not worth it anymore now that GTK+ has advanced a lot, and is easily ported to win32 (and looks reasonably native with theming a la GTK-WIMP).

In other words, if you had to start Abiword over today, would you go GTK+ only or do the extra work for the ui abstraction layer?

Gnumeric doesn't need Abiword's abstraction layer. It is just native GTK2 code now, with the exception of the GConf dependency, which is now a compile-time option. So the Win32 build doesn't need many code changes as it is.

Jody Goldberg of Gnumeric has started to extract the powerful reusable parts of Gnumeric into a library, libgoffice. A better "code sharing" approach than having everyone use Abiword's cross-platform layer is to have Abiword developers move reusable code into libgoffice. This is the plan as far as I'm aware.

Abiword's cross-platform layer is a very interesting approach to solve the problem, and it seems to have worked well for them. However, I'm interested in hearing the developers' reply to your last question: "If you had to start Abiword over today, would you go GTK+ only or do the extra work for the ui abstraction layer?". I would add: How does the compatibility layer compare to NWF in OOo? (Toolkits aside -- VCL code looks pretty ugly I think.)

It's tough call. The abstraction layer has lots of benefits besides the native widgets. It enforces a clean seperation between FE GUI and the backend stuff that worries about word processing.

On the other hand it is developer intensive. We basically need at least one high level expert for each platform. This has been a problem for the Windows and OSX ports at various times as various high-level experts come and go or get too busy.

Also, the defacto standard for text copy is Ctrl+Drag, not Shift+Drag.

There is a problem with Shift+Drag in GNOME-2.8: Holding Shift before the drag makes it impossible to drag the selected text. Holding Shift during the drag makes the dragged selection just "sit" where it is, even after releasing the mouse button. It doesn't paste, and no copy is made, and the dragged text is hanging in the middle of nowhere.

No time to file a Bugzilla report right now, sorry -- (I hope you see this, Martin :-) )

I like it a lot -- it was a real surprise that you see the whole selection drag. It is very good from a UI design perspective, because you get instant feedback as to what is happening.

The only comment I would give is that for large blocks of text, it is hard to see where you're dragging to, because the selected text covers so much of the document canvas. I would suggest one of three ways to fix this:

(1) Make the dragged image partly transparent using Composite on X. Won't work for Windows version, or older X.

(2) Move the selection down and to the right by about 2cm, and then draw a red arrow between the beginning of the selection and the caret insert position, so that you have some room between the selection and the insert position. Should work for any platform.

(3) Ellipsize the text, if it is longer than some threshold in either width or height.

What do you think about these suggestions?

Doh! I wrote that code I should remember it's cntrl-drag not shift drag.

The suggestions for large selections are all interesting. The default solution was to put a little marker next to the cursor to show text was being dragged ala MS Word if the selection was too big. I didn't get around to doing it for 2.2 though. I really like the transperent selection idea though! Once composite goes mainstream I'd like to implement that for all selections.

OSX might be able to do transperent selections already. I'll ask our OSX devs.

Otherwise elipising the text might be a good compromise.

Martin

AbiWord's export to .doc is indeed "just" .rtf, but it has nothing to do with importing. If formatting is lost on import or export, it's either because the importer/exporter doesn't handle the content or there's a bug.

Relevant (archived) thread:

http://www.abisource.com/mailinglists/abiword-dev/2003/Apr/0161.html

... this sort of comments most of the time seems to come from people who have no idea about the feature-packed-ness (aka bloat) of the oowriter file format.
I'm doing small patches to abi's OOo filters from time to time. While import is doable, exporting from abi to OOo is a real pain. People who don't believe me should unzip a .sxw file and try understanding the zillion of xml attributes by reading the > 600 pages oasis standard.

Rob

No it should not, as it will cause loss of formatting. You can set this yourself in your AbiWord profile though.

kword, abiword, openwriter, siag... if every word processor has his own file format...
We need one standard.

kword and openwriter are targetting towards a common file format (OASIS)

A standard is good, but just choose the format of the leading open source software (here OOo) is not a good idea. OOo standard may not be good for Abiword.

Actually the standard does not have to be chosen anymore, it is already being created by Oasis, and it's based on OOo file formats. KOffice will switch to Oasis as their default file format, although KWord is frame based, while OOo is not, they still went ahead, and KOffice authors already said this won't pose any problem.

It would be really a pitty if Abiword would miss the boat. The OOo file format is the standard file format at my work, and I really hate it to use OOo because it is so slow, bloated, and I don't feel very comfortable using it. Abiword on the other hand, solves all the problems I have with OOo, but I cannot read or write OOo documents, which makes it unusable for me :-(

A rudimentary OpenWriter plugin exists, but it definitely won't do everything you need it to do (just letting it be known that you _can_ read and write OOo documents, just not perfectly or even close to perfectly - yet).

As a user, feel free to write the OO importer and exporter.

> Your bitching

The original poster pointed out something VERY important:
the import/export filters are crucial, and should take priority over adding features to the program.

That's not "bitching", it's valuable advice. Unless the Abiword developers are happy with a niche on a few percent of the home machines. The corporate world is itching to kill MS dead, but needs bridges.

And my personal thanks to the Abiword team - I have installed Abiword on a family member's laptop, to rid it of MSword "activation" insanity (it was pre-loaded software, but even so it had that humiliating "feature").

> Your bitching upon a brand new release is what is not acceptable.

Let them complain, lest we get complacent.
The right attitude to have should be:
Thank you for using Abiword, and thank you for caring enough to comment on where we could do better. Please be sure to try Abiword again soon as we are always improving.

There will always be someone making these same comments and while we shouldn't take them personally it is important not to be over confident.

> No one here is striving for an annihilation of MS Word, nor some "migration" of biblical proportions.

Total World Domination or "Word processing for everyone" is a nice goal but seriously the Abiword Developers are doing their very best to produce a user friendly word processor and doing a great job of it in my opinion.

> But for gods sake _stop bitching and bitching only around the clock_!

Don't let anyone tell you to stop bitching but please do try and provide detailed bug reports and specific criticism that will allow us to fix things and make abiword better.

Thanks for using Abiword.

OOo 1.x compatibility with M$ formats was pretty good for the Free/Open Source world. OOo 2.x compatibility will be astounding. Sun settled with M$ recently over some stuff, and as a result, M$ had to provide data format documentation, and agree not to sue them for patent infringement or anything else. Sun is now safe from M$, and is furiously making OOo import/export perfect. Literally.

Once that's done, Abiword etc. just need to look at the OOo source if they need to know anything about the binary formats that they don't know yet.

However, Abiword / Gnumeric etc. have done a pretty phenomenal job at reverse-engineering formats themselves, often in collaboration with other projects like OOo.

Do you have any source on the Internet which confirms the fact that Sun has access to MS Office document specifications, and are using this to improving OOo? I cannot remember having read this.

And yes, Sun's StarOffice is indemnified, but OOo was explicitely excluded from this indemnification in the settlement!

So you believe everything you read on the Internet? :)

From: http://www.winplanet.com/article/2553-.htm

May Goh Petry, Sun spokesperson: "Sun is strongly committed to OpenOffice.org and the settlement with Microsoft doesn't undermine its continued commitment to the community. Open source software is conventionally provided without warranty and liability coverage, and OpenOffice.org is no different. OpenOffice.org is not disadvantaged by the settlement. In fact, OpenOffice.org users may eventually benefit [from] superior interoperability with Microsoft Office."

Sun CEO Scott McNealy: Microsoft and Sun are working on making StarOffice "even more interoperable" with Microsoft Office.

Ask Google for more info: Sun Microsoft settlement OpenOffice

The doc access info is from an inside source.

If there's a problem we can all pay Sun for StarOffice which will basically be OOo -- they probably deserve some compensation for what they've put into it anyway.

Plus, M$ really can't sue us for OOo without suing Sun, because StarOffice is based on OOo. Since they can't sue Sun, it will be very difficult for them to sue us. I think, anyway.

Sun is now safe from M$
I don't believe that for a second. And if they are, I have to suspect that the conditions of such safety threaten the freeness (as in speech) of OOo.

Once that's done, Abiword etc. just need to look at the OOo source
This seems like something MS would have almost certainly taken care to prevent, otherwise any of that format information MS gave Sun would effectively be seen as being released to the public domain.

No, Sun (and their customers) really is/are indemnified against Microsoft. And they really do have access to Microsoft's internal file format documentation. And they really are rolling that stuff furiously into the next release of OOo. And M$ knows that, and of course they aren't happy, but there's nothing much they can do if they don't want to be buried in even deeper legal problems.

There is a clause in the wording of the settlement that possibly singles out OpenOffice.org as an exception to the idemnification. But we're safe -- it's another SCO fiasco at most.

Sun did not sell out -- they know exactly what they are doing, and it is *not* for M$'s benefit.

No, Sun (and their customers) really is/are indemnified against Microsoft. And they really do have access to Microsoft's internal file format documentation. And they really are rolling that stuff furiously into the next release of OOo. And M$ knows that, and of course they aren't happy, but there's nothing much they can do if they don't want to be buried in even deeper legal problems.

There is a clause in the wording of the settlement that possibly singles out OpenOffice.org as an exception to the idemnification. But we're safe -- it's another SCO fiasco at most.

Sun did not sell out -- they know exactly what they are doing, and it is *not* for M$'s benefit.

...just because even MS Word itself has [small but nevertheless visible] incompabilities between different versions/installations. My wife has to work w/ word documents in her office and at home and regularly asks me "why that thing has been broken?".

Usually this happens when visual markup is in use (i.e. spaces for separation, arbitrary font changes etc). Logical markup (specific styles for different parts of a document, all other those nifty things available both in MS Word and OO Writer) usually allows much easier transition between different version of MS Office and even OOo. At least I feel almost no inconviniences when reading / writing my docs in OOo and sending them to MS Word users

I find most of the compatibility issues with OO are due to bad editing practices when using MS Word. For instance, using blank lines instead of page breaks to align the top of a page. Even with MS Word these documents are a pain in the ass to edit.

Yes. Use styles (Title/Body/Heading1 etc.) *everywhere* rather than explicit formatting commands, and then if the layout is different, you can probably just fix the styles. Semantic markup is always better than presentation-based markup, where it is possible to use it.

View -> Enable Formatting Tools forces you to do exactly that. Might be a good help :-)

It's not like we are deliberately making our Word filters "suck". It's hard to get right. Feel free to help out.

All things considered, the import/export is great...but don't count on your doc being readable at the other end. And when you're trying to do business, things have to be seamless. Unfortunately I don't know what can be done until MS opens up the .doc spec for all to use.

Just for the record, the bidi support in AbiWord has, since its inception nearly 5 years ago, been a one-man effort; there is only that much that one person can do in spare time, and only so many different platforms I can work at.

We have very good Arabic support on Windows and the Mac OSX is being worked on by the OSX maintainer at this very moment. Linux has fully working bidi implementation, but unsatisfactory shaping (I know, that is a serious problem for Arabic); it needs to use Pango, someone needs to write the interface code ... It all takes time; it took me 9 months to get the Windows code to the shape it is in, it would go much faster if more people were willing to chip in.

Just so you know, the OSX bidi support is being hacked on right now with the help of Hebrew developers. Care to help out for Arabic?

Subsribe to abiword-dev list, hang out on gimp.net#abiword IRC and offer your input.

Cheers

Martin

The problem mostly is that we don't have a lot of Arabic users/developers to help us out. Feel free to drop by some day and give us some help :-)

Same vith Japanese. Abiword relies on gtk-2, and gtk-2 with Pango and gtk-im cares about everything. How come Abiword is the only Gtk software that breaks the gtk multilingual management?

Yes we are smart asses... pango has *0* use when it can't print, which was the case until recently... Please think before you reply.

It has to deal with multi-platform bits and gtk-specific ones, so this is no pure gtk software. We need contributors like you to fix Japanese/Arabic shaper/whatever bugs :). Willing to help us? :)