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

[arthur miller]

> Just because something is a zip file with some xml files inside does not

> make it "not hard", "just dealing with xml".  It is complex to do
> non-trivial stuff.  If you do not see what I am talking about, try to
> implement something non-trivial (for example merge many docx documents
> into one).  You'll understand why it is not a pleasant experience and
> why I do not think anybody will do that in their free time.

We obviously have different understanding on what is hard. I considering something

to be hard if there is not a well-known solution you can take and apply to implement

the functionality. Or if there are very many  obscure details that have to be taken into

account. I don't consider working with standardized xml format to get into that

category. LibreOffice does quite good job of translating docx stuff you wrote about.

There is a difference between hard and labourus. I would say it is a lot of work not very

hard.

You should be able to open docx files, parse them with elisp and display text or even render

graphics to svg. I did some similar long time ago with Java.I think it is a lot of work, but not

very interesting. I wouldnt say it is unpleasant, it is certainly much better to work with a

documented standardized ooxml then with some undocumented old format. I probably

wouldn't say unpleasant, just very boring.

So if you are gonna go do it, please, it will be great thing if you implement it.

Good luck .

---

Från: Tomas Hlavaty <tom@logand.com>
Skickat: den 25 december 2020 15:44
Till: Arthur Miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

 

On Fri 25 Dec 2020 at 14:19, Arthur Miller <arthur.miller@live.com> wrote:
> 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.

So what?  I do not understand what are you trying to say.

I tried to get the point across that it is not all or nothing problem.
There are use-cases which bring lots of value and are achievable with
reasonable effort.

>> 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.

Just because something is a zip file with some xml files inside does not
make it "not hard", "just dealing with xml".  It is complex to do
non-trivial stuff.  If you do not see what I am talking about, try to
implement something non-trivial (for example merge many docx documents
into one).  You'll understand why it is not a pleasant experience and
why I do not think anybody will do that in their free time.

>>               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.

It is not clear to me about which use-case are you talking in this
prediction.

1) There are use-cases, for which there are solutions now, as I already
   shown.

2) There are use-cases, for which solutions could be implemented with
   reasonable effort.

3) There are use-cases, which will very likely never have an
   alternative.

For 1) I did my best.

For 2) we'll see what I will do;-)

For 3) I wish you good luck!