Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Arthur Miller <arthur.miller@live.com>]

Tomas Hlavaty <tom@logand.com> writes:

>> This is why it would be useful to have this kind of capabilities in
>> Emacs: to enable users to visit MS Office documents with "C-x C-f",
>> edit them in some specialized WYSIWYG Emacs mode, and finally save
>> them with "C-x C-s".  If under the hood this runs some converters, it
>> doesn't matter.
>
> Note that this will never be perfect so we need some nuance here and
> perhaps address useful use-cases.
>
>> And there's no real Free Software alternative, certainly not based on
>> Emacs.
>
> There are and there could be.
>
> Here a rough list of use-cases with increasing complexity:
>
> 1) Reading abw, docx and odt documents as text is very simple in Emacs
>    without any extra dependencies:
>    https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html
>
> 2) Reading them as graphics documents is also pretty simple with some
>    extra dependencies:
>    https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html
>
> 3) Another use-case is to save a buffer to office document.  This should
>    be pretty simple to implement too.
>
> 4) Another use-case is to open, edit and save existing office document
>    and preserve as much original stuff as possible.  This should be
>    possible but lots of work.
>
> 5) Another use-case is WYSIWYG 3).
>
> 6) Another use-case is WYSIWYG 4).

The problem with documents in MS office is not text extraction; it is
just xml nowadays anyway, the problem is countless VBA scripts that
business and organisations run in Excell/Access/Word that just can't be
translate to Libre. Libre has VB, but the underlaying objects are not
there and lots of tools out there that people use can't be just
automatically translated.

I have worked in big organisation and did lots of automation for MS
office and databases.

> Dealing with office formats is not a pleasant experience so I am
> skeptical that volunteers will devote so much time to the use-cases with
> the highest complexity.

What is not so pleasant? New formats (marked with x) at the end are all
xml, so it is just dealing with xml, sinilar to odt. I see nothing hard
there and it is not that I defend Microsoft, I just don't see what you
are talking about. That is part that alternatives you mention do.

>               there could be.

You are correct about one thing: there could be free alternative.
All that will probably change in next 20 ~ 30 years, but we are not
there yet.