DocView now supports OpenDocument & MS Office formats

DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Hi all,

I've just pushed two changes to doc-view.el, which enable viewing all
formats supported by OpenOffice.org.  Basically, that's all OpenDocument
formats, but also (almost?) all Microsoft Office formats.

Till now, I didn't modify the auto-mode-alist entry of doc-view-mode.  I
think, adding all MS office extensions is ok, cause those are not really
editable (binary) stuff anyway.  Should I go ahead?

For the OpenDocument formats, I'm not sure.  Basically, those are zip
archives containing the document contents as XML + images and metadata,
and it's not totally unreasonable to edit the contents directly.  So I
guess, that's a corner case like postscript files...

Bye,
Tassilo

RE: DocView now supports OpenDocument & MS Office formats

[Drew Adams]

This is good news, Tassilo.

Any particular versions of OpenOffice or MS Office that are more, or less,
supported?

> I've just pushed two changes to doc-view.el, which enable viewing all
> formats supported by OpenOffice.org.  Basically, that's all 
> OpenDocument formats, but also (almost?) all Microsoft Office formats.

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

"Drew Adams" <drew.adams@oracle.com> writes:

Hi Drew,

> This is good news, Tassilo.

Thanks.

> Any particular versions of OpenOffice or MS Office that are more, or
> less, supported?

Hm, I don't know.  It mostly depends on unoconv, which in turn depends
on OO.org.  I have version 0.4 installed here, but at least 0.3 should
be fine as well.

Bye,
Tassilo

>> I've just pushed two changes to doc-view.el, which enable viewing all
>> formats supported by OpenOffice.org.  Basically, that's all 
>> OpenDocument formats, but also (almost?) all Microsoft Office formats.

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Tassilo Horn <tassilo@member.fsf.org> writes:

Hi again,

> Till now, I didn't modify the auto-mode-alist entry of doc-view-mode.
> I think, adding all MS office extensions is ok, cause those are not
> really editable (binary) stuff anyway.  Should I go ahead?
>
> For the OpenDocument formats, I'm not sure.  Basically, those are zip
> archives containing the document contents as XML + images and
> metadata, and it's not totally unreasonable to edit the contents
> directly.  So I guess, that's a corner case like postscript files...

I've now implemented a better fallback mechanism, so that C-c C-c in
doc-view-mode opens the document in whatever mode would be chosen if
doc-view wasn't there (e.g. archive-mode for od[st] docs).  So IMO,
adding all OpenDocument and MS Office file extensions to the
doc-view-mode entry in auto-mode-alist should be fine, now.

Additionally, doc-view-previous-major-mode could be deleted.  That makes
only sense now if the user switched to some other major-mode manually
before enabling doc-view-mode, which seems to be a very unlikely
scenario.

WDYT?

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Stefan Monnier]

> Hm, I don't know.  It mostly depends on unoconv, which in turn depends
> on OO.org.  I have version 0.4 installed here, but at least 0.3 should
> be fine as well.

I see.  On my Debian machines (6 year-old Debian testing installation
which has accumulated pretty much all packages I've ever needed during
those years), I don't have unoconv installed, so I think there's a good
chance that many people don't have it installed.  This fact I think
gives a first answer to "should we add .doc and .odt to
auto-mode-alist": only if unoconv is available.


        Stefan

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> Hm, I don't know.  It mostly depends on unoconv, which in turn
>> depends on OO.org.  I have version 0.4 installed here, but at least
>> 0.3 should be fine as well.
>
> I see.  On my Debian machines (6 year-old Debian testing installation
> which has accumulated pretty much all packages I've ever needed during
> those years), I don't have unoconv installed, so I think there's a
> good chance that many people don't have it installed.  This fact I
> think gives a first answer to "should we add .doc and .odt to
> auto-mode-alist": only if unoconv is available.

So something along the lines of:

--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/files.el'
--- lisp/files.el       2010-12-13 15:27:36 +0000
+++ lisp/files.el       2010-12-30 15:47:14 +0000
@@ -2372,7 +2372,9 @@
      ("\\.\\(diffs?\\|patch\\|rej\\)\\'" . diff-mode)
      ("\\.\\(dif\\|pat\\)\\'" . diff-mode) ; for MSDOG
      ("\\.[eE]?[pP][sS]\\'" . ps-mode)
-     ("\\.\\(?:PDF\\|DVI\\|pdf\\|dvi\\)\\'" . doc-view-mode)
+     ,(if (executable-find "unoconv")
+         '("\\.\\(?:PDF\\|DVI\\|OD[FGPST]\\|DOCX?\\|XLSX?\\|pdf\\|dvi\\|od[fgpst]\\|docx?\\|xlsx?\\)\\'" . doc-view-mode)
+       '("\\.\\(?:PDF\\|DVI\\|pdf\\|dvi\\)\\'" . doc-view-mode))
      ("configure\\.\\(ac\\|in\\)\\'" . autoconf-mode)
      ("\\.s\\(v\\|iv\\|ieve\\)\\'" . sieve-mode)
      ("BROWSE\\'" . ebrowse-tree-mode)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Stefan Monnier]

> Additionally, doc-view-previous-major-mode could be deleted.  That makes
> only sense now if the user switched to some other major-mode manually
> before enabling doc-view-mode, which seems to be a very unlikely
> scenario.

In the case where the auto-mode-alist does not choose the right mode, it
is highly likely that the user sets the mode manually and would be
annoyed if doc-view-previous-major-mode were removed.


        Stefan

Re: DocView now supports OpenDocument & MS Office formats

[Stefan Monnier]

> So something along the lines of:

> -     ("\\.\\(?:PDF\\|DVI\\|pdf\\|dvi\\)\\'" . doc-view-mode)
> +     ,(if (executable-find "unoconv")
> +
> ("\\.\\(?:PDF\\|DVI\\|OD[FGPST]\\|DOCX?\\|XLSX?\\|pdf\\|dvi\\|od[fgpst]\\|docx?\\|xlsx?\\)\\'"
> . doc-view-mode)
> +       '("\\.\\(?:PDF\\|DVI\\|pdf\\|dvi\\)\\'" . doc-view-mode))

Could be an approach, except that files.el is preloaded, so that would
be evaluated at dump time rather than run time.  Another is to link them
to doc-view-mode-maybe which would first check whether doc-view-mode can
really be used and fallback to the next best choice otherwise (could
even remove itself from auto-mode-alist at that point, tho it's not
clear that it would be useful).


        Stefan

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Additionally, doc-view-previous-major-mode could be deleted.  That
>> makes only sense now if the user switched to some other major-mode
>> manually before enabling doc-view-mode, which seems to be a very
>> unlikely scenario.
>
> In the case where the auto-mode-alist does not choose the right mode,
> it is highly likely that the user sets the mode manually and would be
> annoyed if doc-view-previous-major-mode were removed.

Well, right.  So I'll let is as it is right now.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

> Could be an approach, except that files.el is preloaded, so that would
> be evaluated at dump time rather than run time.

Oh, that's not appropriate then.

> Another is to link them to doc-view-mode-maybe which would first check
> whether doc-view-mode can really be used and fallback to the next best
> choice otherwise

Ok, I've gone that road now.

Thanks,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[MON KEY]

>> Hm, I don't know.  It mostly depends on unoconv, which in turn depends
>> on OO.org.  I have version 0.4 installed here, but at least 0.3 should
>> be fine as well.

> I see.  On my Debian machines (6 year-old Debian testing
> installation which has accumulated pretty much all packages I've
> ever needed during those years), I don't have unoconv installed,
> so I think there's a good chance that many people don't have it
> installed.  This fact I think gives a first answer to "should we
> add .doc and .odt to auto-mode-alist": onlyif unoconv is available.

There is maybe a problem here around promoting unoconv wrt UNO API, e.g:

 unoconv < UNO < OO.org

It may be a bit misleading to give potential users of this feature an
impression that unoconv's dependencies are less than trivial, i.e.:

 "It mostly depends on unoconv, which in turn depends on OO.org."

From the Uno FAQ:

 2.22 How do I remotely connect to an OpenOffice.org running on a
 different machine?

,----
|
|  When connecting to an OpenOffice.org you supply an Uno URL, which
|  allows to locate a named Uno object in a different process. A Uno
|  URL consists of four parts:
|
|     * The constant string "uno".
|
|     * A connection specification with optional parameters as
|       key/value pairs.
|
|     * A protocol specification with optional parameters as key/value
|       pairs.
|
|     * The name of the object to be located.
|
|  Those four parts are concatenated to a string
|
|  uno:[connection],params;[protocol],params;[objectname]
|
|  An example Uno URL looks like:
|
|  uno:socket,host=localhost,port=2002;urp;StarOffice.ServiceManager
|
| {...}
|
`----
http://wiki.services.openoffice.org/wiki/Uno/FAQ#How_do_I_remotely_connect_to_an_OpenOffice.org_running_on_a_different_machine.3F

Isn't this sort of stuff a slippery slope to Software as Service? E.g.:

http://udk.openoffice.org/common/man/spec/remotebridge.html

Recall the recent discussion around software as service and Julien Danjou's GG
maps related interface...


--
/s_P\

Re: DocView now supports OpenDocument & MS Office formats

[Jason Rumney]

MON KEY <monkey@sandpframing.com> writes:

> http://wiki.services.openoffice.org/wiki/Uno/FAQ#How_do_I_remotely_connect_to_an_OpenOffice.org_running_on_a_different_machine.3F
>
> Isn't this sort of stuff a slippery slope to Software as Service?

No. This is plain old RPC. The "service" is Free Software running under
the user's own control.

Re: DocView now supports OpenDocument & MS Office formats

[MON KEY]

On Thu, Dec 30, 2010 at 5:59 PM, Jason Rumney <jasonr@gnu.org> wrote:
> No. This is plain old RPC.

This is not plain RPC its UNO "Universal Network
Objects" which does leverage aspects of RPC along with a heavily
influenced (albeit rebranded) CORBA interface.

> The "service" is Free Software

Its LGPL free as in "Oracle"...

Tune in for Episode 3 entitled "We are the Cloud, now get assimilated":
In which our benevolent dictator markets their branded version of
'Oracle Open Office' under the moniker 'Oracle Cloud Office' complete
with PHB targeted hype-speak:

 "Oracle Cloud Office Web-scale architecture can be used for on-premise,
  on-demand, or software-as-a-service (SaaS) deployments."

http://www.oracle.com/us/products/applications/open-office/cloud-office-170206.html


> running under the user's own control.
>

It is the remote aspects around the TCP/IP portion of the UNO
connections that are of concern.

Why is "host" necessarilly under user control?

,----
|
|  * uno:socket,host=localhost,port=2002;urp;StarOffice.ServiceManager
|  * uno:pipe,name=mypipename;urp;MyObjectName
|
|  http://udk.openoffice.org/common/man/spec/connection_services.html
|
`----

This certainly isn't clear from the UNO spec.

There is dicussion which suggests that certain issues re the "user's
own control" are neither resolved nor necessarilly secure, i.e.

http://udk.openoffice.org/common/man/concept/uno_security.html

Note the circa 2002 copyright date of that URL and the curiously
conflicting Oracle/Sun branding.

No doubt now that Sun is Oracle those lingering issues will finally be
dispatched esp. since the cloud has proven to be a viable economic
engine in years to come.

Whichever. Thanks to Tasillo et al for endeavoring to make ODF format
available to Emacs users.

I just find it unfortunate that the feature has the
python/pyuno/UNO/OpenOffice/Java dependencies. It would be nice to
have an ODF conversion interface which isn't so heavy, potentially
insecure, or so fundamentally antithetical to the KISS of Emacs' plain text.

--
/s_P\

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Jason Rumney <jasonr@gnu.org> writes:

>> http://wiki.services.openoffice.org/wiki/Uno/FAQ#How_do_I_remotely_connect_to_an_OpenOffice.org_running_on_a_different_machine.3F
>>
>> Isn't this sort of stuff a slippery slope to Software as Service?
>
> No. This is plain old RPC. The "service" is Free Software running
> under the user's own control.

Furthermore, there's no need to let the conversion take place in a
remote OO.org instance (although that's a nice feature).  Usually,
unoconv simply starts a headless OO.org instance locally and let that do
the conversion.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

MON KEY <monkey@sandpframing.com> writes:

> Whichever. Thanks to Tasillo et al for endeavoring to make ODF format
> available to Emacs users.
>
> I just find it unfortunate that the feature has the
> python/pyuno/UNO/OpenOffice/Java dependencies.

I've installed OO.org as precompiled binary and unoconv.  The UNO and
python bindings seem to be included in OO.org out of the box.  And
python and java are probably installed anyway.  (I mean, you even need
python to fetch Emacs source code.)

> It would be nice to have an ODF conversion interface which isn't so
> heavy, potentially insecure, or so fundamentally antithetical to the
> KISS of Emacs' plain text.

I don't know what you mean by insecure and antithetical.  DocView uses
unoconv in a way that it simply starts a local, headless OO.org instance
that does the conversion and exits.  And both tools are free software.

And that it can work remotely (as a kind of SaaS) is not a bad thing in
itself: As long as the service is provided by free software, I can setup
and study the service locally and don't lose my freedoms, right?

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Fri, 31 Dec 2010 09:35:08 +0100
> Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
> 
> (I mean, you even need python to fetch Emacs source code.)

No, you don't.  Installing Bazaar gets you two Python libraries
(pythoncomNN.dll and pywintypesNN.dll on MS-Windows), which is a far
cry from the full Python installation.

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> (I mean, you even need python to fetch Emacs source code.)
>
> No, you don't.  Installing Bazaar gets you two Python libraries
> (pythoncomNN.dll and pywintypesNN.dll on MS-Windows), which is a far
> cry from the full Python installation.

Ok, ok.  But IMO having to install python, OO.org and unocov is a fair
tradeoff to be able to view anything OO.org supports in Emacs.  And at
least on most GNU/Linux boxes, python and OO.org are installed anyway.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Stefan Monnier]

>> From the Uno FAQ:
>  2.22 How do I remotely connect to an OpenOffice.org running on a
>  different machine?

Irrelevant.  E.g., Elisp also allows you to connect to SaaS thingies.


        Stefan

Re: DocView now supports OpenDocument & MS Office formats

[MON KEY]

On Fri, Dec 31, 2010 at 11:43 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> From the Uno FAQ:
>>  2.22 How do I remotely connect to an OpenOffice.org running on a
>>  different machine?
>
> Irrelevant.  E.g., Elisp also allows you to connect to SaaS thingies.
>

Yes, of course; where Emacs is the client (or its immediate mediator);
and where Emacs is built from the more or less standard GNU C
libs/protocols; and where Emacs C API is quite a bit more transparent;
and where the Emacs environment is generally a far cry from the
massive amounts of indirection required to do an ODF conversion via
python/pyuno/UNO/OpenOffice/Java dependency chain -- indeed, it does!

Following are some "benchmarks" which might come of some interest to
the types of people who worry about dumpsize, the slow creep of Emacs
puresize, the size of online documentation relative to the printed
manual, backward compatibility with MS-DOS, running Emacs portably in
both TTY and GUId environments, etc. :P

http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html
http://www.oooninja.com/2008/05/openofficeorg-moores-law-obeys.html
http://www.oooninja.com/2009/03/multiplatform-benchmark-30.html	

Would be interesting to chart some of the above benchmarks against the
decline of "Eight Megs And Constantly Swapping" as a prejorative
acronym...

--
/s_P\

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    > The "service" is Free Software

    Its LGPL free as in "Oracle"...

Whatever you mean to say, could you please say it without sarcasm?
I do not understand your point.

A service can't be free software
because a service is not software.
But I am rather lost so maybe I misunderstood it all.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[MON KEY]

On Sat, Jan 1, 2011 at 7:33 PM, Richard Stallman <rms@gnu.org> wrote:
>>> The "service" is Free Software
>
>> Its LGPL free as in "Oracle"...
>
> Whatever you mean to say, could you please say it without sarcasm?

The intent wasn't to be sarcastic, irony perhaps.

Oracle is now the "benevolent dictator" overseeing the OO.org UNO SDK.

Oracle's stated intent is to supply the Oracle OpenOffice deliverables
with SaaS capabilities. This is not a theoretical matter, its
happening.

IMHO It does not seem unreasonable to assume that Oracle will leverage
its influence on the future protocols of UNO SDK to ensure that
OpenOffice becomes a front end to service running remotely outside the
users control but under Oracle's sphere of influence.

> I do not understand your point.

In order for an Emacs to gain ODF support via the proposed docview.el
interface one must leverage python/pyuno/UNO/OpenOffice/Java

The point is:

 - interaction with the UNO bridge is not (necessarily) simple RPC;

 - the UNO SDK is a poorly specified;

 - Its protocol is compromised in lieu of the Sun/Oracle merger;

 - asking Emacs users to embrace these dependencies just to gain ODF
   support is tantamount to a tacit endorsement of Oracle's reframing
   of software as service in a distributed manner;

 - asking Emacs users to install the python/pyuno/UNO/OpenOffice/Java
   dependencies just to gain ODF support is ironic given the extent to
   which the Emacs-Devels have endeavored to keep the Emacs footprint
   small;

> A service can't be free software because a service is not software.

This doesn't make any sense.

There is significant tension around the semantics of the term
"software" and the term "service". It isn't clear that you have
resolved these semantics satisfactorily yet.

> Richard Stallman

--
/s_P\

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    Oracle's stated intent is to supply the Oracle OpenOffice deliverables
    with SaaS capabilities. This is not a theoretical matter, its
    happening.

"SaaS capabilities" is rather vague -- could you tell me what this
refers to?

The issue is important because OpenOffice is important.  I am not yet
sure it related to Emacs, but I should learn about it anyway.

    In order for an Emacs to gain ODF support via the proposed docview.el
    interface one must leverage python/pyuno/UNO/OpenOffice/Java

    The point is:

     - interaction with the UNO bridge is not (necessarily) simple RPC;

That is too vague to draw conclusions from.

     - the UNO SDK is a poorly specified;

That would be a problem if we cannot make it work.

     - Its protocol is compromised in lieu of the Sun/Oracle merger;

"Compromised" is rather vague, so I am not sure this is an issue.

     - asking Emacs users to embrace these dependencies just to gain ODF
       support is tantamount to a tacit endorsement of Oracle's reframing
       of software as service in a distributed manner;

I am not sure "Software as a Service in a distributed manner" is
coherent.  Often the alternative to a centralized network service is a
distributed system in which users' machines cooperate.

Thus, I have doubts about this conclusion.

     - asking Emacs users to install the python/pyuno/UNO/OpenOffice/Java
       dependencies just to gain ODF support is ironic given the extent to
       which the Emacs-Devels have endeavored to keep the Emacs footprint
       small;

People who want to use ODF need to install OpenOffice anyway,
so I am not sure this is a terrible problem.

If there's another way to do the job, it might be better.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    > A service can't be free software because a service is not software.

A program is something you can copy and install.
A service is something remote that you can talk to.
The difference is absolute and fundamental.


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Stephen J. Turnbull]

Richard Stallman writes:

 >     Oracle's stated intent is to supply the Oracle OpenOffice deliverables
 >     with SaaS capabilities. This is not a theoretical matter, its
 >     happening.
 > 
 > "SaaS capabilities" is rather vague -- could you tell me what this
 > refers to?

This refers to running the software on the vendor's host, and
delivering only the service to the user.  This makes conventional
(free or proprietary) software licensing moot, of course.  Probably
the best way to think about SaaS is as ASP2.0.  SaaS fanchildren like
to claim that SaaS as a business model is qualitatively different from
ASP, but it really is not.  It is the marriage of the ASP business
model with Web2.0 technology, but the fundamental concept is enabling
a pay-per-play revenue stream.

The most basic implementation provides an AJAX interface, so that
redisplay is done by manipulating HTML (or XML) and CSS efficiently,
but the underlying data (such as an ODF document or an RDBMS) is never
directly accessed by the user.  I don't know what Oracle is planning
for OOo, perhaps turning the redisplay into an arm's-length client,
perhaps rewriting it to target Web2.0 technology instead of local GUIs.

I don't think this will change Oracle's opportunistic attitude toward
"open source" as they call it.  They'll use it, and contribute to it,
where they see an advantage, but they'll also use SaaS to generate
sustainable/predictable revenue streams without the risk inherent in
delivering software to entities not under NDA.

 > The issue is important because OpenOffice is important.

I suppose you're right, but I'm sad to hear you say so.  One wishes it
wasn't so.  WYSIWYG is one of the greatest productivity-sappers ever
invented.

 > People who want to use ODF need to install OpenOffice anyway,

I hope you're wrong.  It should be possible to have any2odf
converters, for values of "any" like "restructured text" or "perldoc"
as well as "TeX" or "DocBook", and odf2any, for values of "any" like
"TeX" and "PDF".

And Emacs itself should be adaptable to manipulating ODF just as it
handles DocBook or TeX.  "AUC-ODF", anyone?

Re: DocView now supports OpenDocument & MS Office formats

[MON KEY]

On Sun, Jan 2, 2011 at 5:11 PM, Richard Stallman <rms@gnu.org> wrote:
>    Oracle's stated intent is to supply the Oracle OpenOffice deliverables
>    with SaaS capabilities. This is not a theoretical matter, its
>    happening.
>
> "SaaS capabilities" is rather vague -- could you tell me what this
> refers to?

Please take the opportunity to re-read my original post. Presumably,
that which you earlier
deemed sarcastic:

,----
| > The "service" is Free Software
|
| Its LGPL free as in "Oracle"...
|
| Tune in for Episode 3 entitled "We are the Cloud, now get assimilated":
| In which our benevolent dictator markets their branded version of
| 'Oracle Open Office' under the moniker 'Oracle Cloud Office' complete
| with PHB targeted hype-speak:
|
|  "Oracle Cloud Office Web-scale architecture can be used for on-premise,
|  on-demand, or software-as-a-service (SaaS) deployments."
|
| http://www.oracle.com/us/products/applications/open-office/cloud-office-170206.html
`----

The indented quote above was lifted verbatim from the referenced URL
(which, IMO tells the tale).

Again, the irony here is that after all of the effort and work
extended to get Sun Microsystems to open up the the Java codebase and
to get governments and corporations to support the ODF as opposed to
MScorps "Office Open XML", along comes Oracle in 2010-01-27 with a
cool US$ 7.4 Billion and ends up with a controlling interest in both
Java and ODF along with a strong interest in selling to enterprises
both "Software-as-a-Service" and the software and servers that deliver
these services while simultaneously extolling to these same
enterprises the virtues of the "Open Standards" based
software/services though clearly they do not intend to support such
"Open Standards" in an vendor neutral manner.

>
> The issue is important because OpenOffice is important.

OpenOffice is _not_ important. After all, its just branding for a bunch
of LGPL'd code. This said, ODF _is_ important, as is LibreOffice's
support of the format.

> I am not yet sure it related to Emacs,

Many Emacs users would probably benefit by having an interface to ODF.
Besides which, I'm pretty sure the GNU project has advocated strongly
in favor of this format and it would be a shame if Emacs is unable
to support it.

> but I should learn about it anyway.

Yes you should, esp. as you are already (quite recently) on record
endorsing LibreOffice in lieu of OpenOffice:

,----
|
| FSF President Richard Stallman welcomed LibreOffice release and
| it's stated policy of only recommending free software. "I'm very
| pleased that the Document Foundation will not recommend nonfree
| add-ons, since they are the main freedom problem of the current
| OpenOffice.org. I hope that the LibreOffice developers and the
| Oracle-employed developers of OpenOffice.org will be able to
| cooperate on development of the body of the code".
|
`---- :SOURCE (URL `http://www.documentfoundation.org/supporters/')

>
>    In order for an Emacs to gain ODF support via the proposed docview.el
>    interface one must leverage python/pyuno/UNO/OpenOffice/Java
>
>    The point is:
>
>     - interaction with the UNO bridge is not (necessarily) simple RPC;
>
> That is too vague to draw conclusions from.
>
Please don't minimize the conclusion on the basis of a bullet-point.
In the context of my earlier posts I wasn't quite so vague.

>     - the UNO SDK is a poorly specified;
>
> That would be a problem if we cannot make it work.
>

This incorrectly inverts the issue without acknowledging that you've
understood the problem. Obv. we are not trying to "make it work" b/c
we are relying on multiple pieces of third party software in order to
interface with the UNO SDK. Not only is it unclear if these software
are able to "make it work" by doing so cleanly/safely/transparently
and in a manner which protecting the users freedom, but it is
increasingly unclear that the core developers/implementers of the SDK
itself are willing and able to continue supporting it (witness the
LibreOffice fork).

>     - Its protocol is compromised in lieu of the Sun/Oracle merger;
>
> "Compromised" is rather vague, so I am not sure this is an issue.
>

OK, hows this:

- Oracle purchases/merges-with Sun;

- Oracle gains oversight of OpenOffice/UNO/Java;

- Oracle begins marketing Oracle Open Office;

- Some key OpenOffice developers decide to fork OpenOffice in late
  September of this year as it becomes increasingly clear that Oracle
  is not intent on remaining vendor neutral with its newly acquired
  codebase;

- LibreOffice begins an initiative to srub the forked OpenOffice
  codebase of pre-existing in-source comments. Presumably the
  "scrubbing" has some relation to issues around this:
  (URL `http://www.oasis-open.org/committees/office/ipr.php')

- It is not clear that the existing OpenOffice codebase will remain
  free of contest. For example, see the recent 2010-09-28 LWN.net
  interview with Michael Meeks:

,----
|
| LWN: There have been occasional hints that Sun had patents on some
|      StarOffice/OpenOffice components and we have seen that Oracle
|      is not terribly shy about patent litigation; does the project
|      have any concerns about patents or patented technology in the
|      codebase?
|
| MM: The OpenOffice.org code-base that LibreOffice is derived from is
|     licensed under the LGPLv3 - which gives us all a strong
|     explicit patent license, and a good copyright license, so
|     no. Clearly for new code we would want a plus ["or any later
|     version"] license, so we are considering recommending a LGPLv3+
|     / MPL combination for entirely new code.
|
`---- :SOURCE (URL `http://lwn.net/Articles/407339/')

Maybe we should wait to see what happens between the Oracle and The
Document Foundation before actively endorsing a particular
implementation of "OpenOffice".

>     - asking Emacs users to embrace these dependencies just to gain ODF
>       support is tantamount to a tacit endorsement of Oracle's reframing
>       of software as service in a distributed manner;
>
> I am not sure "Software as a Service in a distributed manner" is
> coherent.

It is difficult to anticipate exactly what Oracle intends for
OpenOffice.  No doubt if we each had crystal balls things would be
different. None the less, given what we can observe, the assertion
that Oracle (among others) may be reframing the scope of software
freedom is IMO far more coherent than denying the possibility by
virtue of semantic chicanery around the ambiguity of the term
"service".

> Often the alternative to a centralized network service is a
> distributed system in which users' machines cooperate.

Indeed, a zombied machine in a botnet fits this description as well.

The issue isn't whether and how the distribution of the system happens,
but if the collective of machines cooperating do so with user(s)
awareness and permission and whether the user has reasonable recourse
to recover/retain her processed data according her needs and wishes.

>
>     - asking Emacs users to install the python/pyuno/UNO/OpenOffice/Java
>       dependencies just to gain ODF support is ironic given the extent to
>       which the Emacs-Devels have endeavored to keep the Emacs footprint
>       small;
>
> People who want to use ODF need to install OpenOffice anyway,
> so I am not sure this is a terrible problem.

AFAIK the ODF acronym expands to "OpenDocument Format" an XML oriented
document file format standardized by ISO/IEC and was designed to be
vendor neutral and implementation agnostic.  It is certainly supported
by more than just "OpenOffice". Indeed, IIRC there is already a third
party Emacs based solution for pulling ODF conversions from GoogleDocs.

>
> If there's another way to do the job, it might be better.
>

It would be interesting if you could learn from the the LibreOffice
people whether they intend to support/extend the UNO SDK's C bridge.

Better still would be if some brilliant C hack could play matchmaker
with the ODF XML and Emacs' new libxml based features.

> Richard Stallman

--
/s_P\

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

Hello Richard,

Looking at the homepage and its description, is basically looks like an
approach to make OpenOffice.org functionality available to other
languages (and also remotely to other processes).

,----[ http://udk.openoffice.org/ ]
| Uno stands for Universal Network Objects.  Uno is one of the accepted
| projects of OpenOffice.org.
| 
| Uno is the component model of OpenOffice.org.  Uno offers
| interoperability between programming languages, other components
| models and hardware architectures, either in process or over process
| boundaries, in the Intranet as well as in the Internet. Uno components
| may be implemented in and accessed from any programming language for
| which a Uno implementation (AKA language binding) and an appropriate
| bridge or adapter exists.
`----

I don't know about the consequences with respect to software freedom
here.  OO.org is LGPL, so there might be a chance that proprietary
components leveraging OO.org functionality are now easier to write with
UNO.  But that would only be the case if accessing OO.org functionality
(possibly remotely) via UNO bindings is fundamentally different from
accessing OO.org functionality in C.

>      - asking Emacs users to install the python/pyuno/UNO/OpenOffice/Java
>        dependencies just to gain ODF support is ironic given the extent to
>        which the Emacs-Devels have endeavored to keep the Emacs footprint
>        small;
>
> People who want to use ODF need to install OpenOffice anyway, so I am
> not sure this is a terrible problem.

Well, there are other free office suites that handle ODF as well, like
KOffice.

> If there's another way to do the job, it might be better.

The reason I chose unoconv/OO.org is that it required only a few lines
of elisp to allow for viewing anything OO.org can read inside emacs.

And doc-view doesn't add any hard dependencies at all.  If the required
tools for some kind of document are not installed, or emacs has been
compiled without PNG support, or if the current emacs frame is a TTY
frame, then doc-view falls back to the mode that would be used if there
was no doc-view.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[CHENG Gao]

*On Sun, 02 Jan 2011 17:11:34 -0500
* Also sprach Richard Stallman <rms@gnu.org>:

> People who want to use ODF need to install OpenOffice anyway,
> so I am not sure this is a terrible problem.

Some developers of OO were not happy with Oracle dictatorship, so they
forked out to set up a community driven LibreOffice[1]. Maybe Emacs team
could take a look at this site and decide if they should be mentioned
instead of / alongside OO.

BTW, off the topic, some original MySQL developers felt the same as
LibreOffice developers and created MairaDB[2], a dropin replacement of MySQL.


Footnotes: 
[1]  http://www.libreoffice.org
[2]  http://mariadb.org

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

CHENG Gao <chenggao@cyberhut.org> writes:

Hi!

>> People who want to use ODF need to install OpenOffice anyway,
>> so I am not sure this is a terrible problem.
>
> Some developers of OO were not happy with Oracle dictatorship, so they
> forked out to set up a community driven LibreOffice[1].  Maybe Emacs
> team could take a look at this site and decide if they should be
> mentioned instead of / alongside OO.

Sadly, LibreOffice currently only provides RPM and DEB binaries, so I
couldn't install and test-drive it on my Gentoo GNU/Linux box.  But I
had a look at LibreOffice's Git repository.  That also contains the UNO
API including the python bindings.  So I'm pretty sure that DocView
works as good with LibreOffice as it does with OpenOffice.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    Some developers of OO were not happy with Oracle dictatorship, so they
    forked out to set up a community driven LibreOffice[1]. Maybe Emacs team
    could take a look at this site and decide if they should be mentioned
    instead of / alongside OO.

We definitely want to choose LibreOffice as the program we recommend
to the public.


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    > If there's another way to do the job, it might be better.

    The reason I chose unoconv/OO.org is that it required only a few lines
    of elisp to allow for viewing anything OO.org can read inside emacs.

It seems reasonable to me.  In principle, writing ODF support in Emacs
Lisp would be preferable, but that's a gigantic job and it might run
too slowly.

Anyway, even if this implementation is not ideal, it has the virtue of
existing.  So we may as well install it.  If another method is
implemented later, we could install that too.

Is it feasible to implement of saving a buffer with formatting
in ODF using this feature?  That would be really great.



-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    Please take the opportunity to re-read my original post. Presumably,
    that which you earlier
    deemed sarcastic:

    ,----
    | > The "service" is Free Software
    |
    | Its LGPL free as in "Oracle"...
    |
    | Tune in for Episode 3 entitled "We are the Cloud, now get assimilated":
    | In which our benevolent dictator markets their branded version of
    | 'Oracle Open Office' under the moniker 'Oracle Cloud Office' complete
    | with PHB targeted hype-speak:

With all the sarcasm, I cannot derive any concrete meaning from that.

    |  "Oracle Cloud Office Web-scale architecture can be used for on-premise,
    |  on-demand, or software-as-a-service (SaaS) deployments."

That doesn't give much specifics, but seems to say that they will
support SaaS, but not only SaaS.

    > The issue is important because OpenOffice is important.

    OpenOffice is _not_ important. After all, its just branding for a bunch
    of LGPL'd code.

I am talking about the code, not the name.
Give me a break, ok?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

     > "SaaS capabilities" is rather vague -- could you tell me what this
     > refers to?

    This refers to running the software on the vendor's host, and
    delivering only the service to the user.

That is the general definition of SaaS, which I already know.
(See http://www.gnu.org/philosophy/who-does-this-server-really-serve.html.)
The question was about what these capabilities are.

      I don't know what Oracle is planning
    for OOo, perhaps turning the redisplay into an arm's-length client,
    perhaps rewriting it to target Web2.0 technology instead of local GUIs.

That seems like a plausible guess.


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

RE: DocView now supports OpenDocument & MS Office formats

[Drew Adams]

> (See http://www.gnu.org/philosophy/who-does-this-server-really-serve.html.)

That should be:
http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
                                       ^^^^

Re: DocView now supports OpenDocument & MS Office formats

[Stephen J. Turnbull]

Richard Stallman writes:

 > That is the general definition of SaaS, which I already know.

Sorry; your question was somewhat vague, and the post that prompted it
was more so.  (Most vague of all are my colleagues, who don't yet
agree on what the economic meaning of "service" is in this context.
Probably that's who I was responding to. :-)

 >     I don't know what Oracle is planning for OOo, perhaps turning
 >     the redisplay into an arm's-length client, perhaps rewriting it
 >     to target Web2.0 technology instead of local GUIs.
 > 
 > That seems like a plausible guess.

As vague as it is, that's generous of you -- but I'll accept it as
praise. :-)  FWIW, my assessment is that Oracle will continue to
support OOo as free software, possibly at levels similar to Sun, and
for the same reasons: holding Microsoft at bay, and to some extent a
loss-leader/ad platform for their SaaS products.  In parallel they'll
develop the SaaS aspect for producing nice reports, presentations, and
customer-manipulable spreadsheets as a front-end for other services.

Also FWIW, I just tasked a team of students with a research project to
study SaaS in East Asia.  It's off-topic so I won't say more on-list,
but since the thread has gotten this far, let me say I'd be happy to
take input (offlist) from anyone interested who has suggestions about
what to look for or what's interesting to them about SaaS as a
business model (they're MBAs, not SEs).  As yet, my students have
barely learned to expand the acronym, so they'd be happy to get
suggestions too!

Regards and a Happy, Productive 2011 to all Emacsers!

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

>     > If there's another way to do the job, it might be better.
>
>     The reason I chose unoconv/OO.org is that it required only a few lines
>     of elisp to allow for viewing anything OO.org can read inside emacs.
>
> It seems reasonable to me.  In principle, writing ODF support in Emacs
> Lisp would be preferable, but that's a gigantic job and it might run
> too slowly.

Indeed.  But IMO emacs is not really a WYSIWYG editor, and doesn't want
to be one anyway.  But there are some tools that convert from markup
languages emacs support to OpenDocument, like for example docbook2odf.

> Anyway, even if this implementation is not ideal, it has the virtue of
> existing.  So we may as well install it.  If another method is
> implemented later, we could install that too.

And as I've mentioned in another mail, it should also work with
LibreOffice without any adaption, so it is not true that it promotes
only OpenOffice.org and thus Oracle.

> Is it feasible to implement of saving a buffer with formatting in ODF
> using this feature?  That would be really great.

No.  DocView is only a viewer for a large set of document formats.
Internally, every page of a document is converted to a PNG image that is
shown in an emacs buffer.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Tue, 04 Jan 2011 08:38:38 +0100
> Cc: monkey@sandpframing.com, jasonr@gnu.org, emacs-devel@gnu.org
> 
> > In principle, writing ODF support in Emacs Lisp would be
> > preferable, but that's a gigantic job and it might run too slowly.
> 
> Indeed.  But IMO emacs is not really a WYSIWYG editor, and doesn't want
> to be one anyway.

Actually, Emacs does want to have at least specialized mode(s) that are
WYSIWYG.  The beginning is in enriched-mode, and there's this entry in
etc/TODO:

  ** Program Enriched mode to read and save in RTF.  [Is there actually a
    decent single definition of RTF?  Maybe see info at
    http://latex2rtf.sourceforge.net/.]  This task seems to be addressed
    by http://savannah.nongnu.org/projects/emacs-rtf/, which is still in
    very early stages.

Volunteers are welcome.

> But there are some tools that convert from markup
> languages emacs support to OpenDocument, like for example docbook2odf.

Personally, I generally dislike features that require me to install
gazillions of other packages.  But that's me; the world seems to move
in the opposite direction.  See it as a rant of an old-timer.

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> But there are some tools that convert from markup languages emacs
>> support to OpenDocument, like for example docbook2odf.
>
> Personally, I generally dislike features that require me to install
> gazillions of other packages.  But that's me; the world seems to move
> in the opposite direction.

Well, I tend to agree.  But OTOH, implementing the wheel again from
scratch and using up gazillion hours of man-power to somehow keep up
with existing free tools (like OpenOffice.org/LibreOffice, KOffice) just
to have it in Emacs is not a real alternative.

BTW: I've just found out that Org mode lets you export to DocBook
format, and that can be converted to OpenDocument.

> See it as a rant of an old-timer.

Yeah, good ol' boy. :-)

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: rms@gnu.org,  monkey@sandpframing.com,  jasonr@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 04 Jan 2011 10:00:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Personally, I generally dislike features that require me to install
> > gazillions of other packages.  But that's me; the world seems to move
> > in the opposite direction.
> 
> Well, I tend to agree.  But OTOH, implementing the wheel again from
> scratch and using up gazillion hours of man-power to somehow keep up
> with existing free tools (like OpenOffice.org/LibreOffice, KOffice) just
> to have it in Emacs is not a real alternative.

Yes, and OTTH, you install a package, which tells you it needs another
package, which then tells you need yet another, which tells you it
doesn't support your version of the kernel, etc. etc, until eventually
you end up wasting many hours upgrading a large portion of your
well-tuned system, destabilizing it in the process with the bleeding
edge.

But I digress.

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    > Is it feasible to implement of saving a buffer with formatting in ODF
    > using this feature?  That would be really great.

    No.  DocView is only a viewer for a large set of document formats.
    Internally, every page of a document is converted to a PNG image that is
    shown in an emacs buffer.

Is there any chance of extracting the text as text
with markup in a format that Emacs could handle?


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Jambunathan K]

Richard Stallman <rms@gnu.org> writes:

>     > Is it feasible to implement of saving a buffer with formatting in ODF
>     > using this feature?  That would be really great.
>
>     No.  DocView is only a viewer for a large set of document formats.
>     Internally, every page of a document is converted to a PNG image that is
>     shown in an emacs buffer.
>
> Is there any chance of extracting the text as text
> with markup in a format that Emacs could handle?

Like Orgmode, for example? 

http://www.emacswiki.org/emacs/OpenDocument 

Above link talks of odf-mode and odt2org.

Not so long ago, I had used odf-mode and was quite unhappy with the text
extraction it was doing. I haven't tried odt2org though.

Jambunathan K.

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     > Is it feasible to implement of saving a buffer with formatting in ODF
>     > using this feature?  That would be really great.
>
>     No.  DocView is only a viewer for a large set of document formats.
>     Internally, every page of a document is converted to a PNG image that is
>     shown in an emacs buffer.
>
> Is there any chance of extracting the text as text
> with markup in a format that Emacs could handle?

Yes, OpenOffice.org/LibreOffice can export to DocBook-XML, [X]HTML, RTF,
MediaWiki, and LaTeX via the UNO bindings and the unoconv tool.  I have
no idea how good these exporters are.  doc-view.el only uses the PDF
export, and at least that's pretty good.

But I think that conversion from and to ODF is not the right approach to
support ODF editing in Emacs.  Imagine a colleague sends you an ODF file
she created using LibreOffice, you convert it to something Emacs can
handle, do some minor editing, convert back to ODF and send it away, the
chance are very high that some information were lost in one of the two
conversion steps.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Lennart Borgman]

On Tue, Jan 4, 2011 at 5:08 AM, Richard Stallman <rms@gnu.org> wrote:
>    > If there's another way to do the job, it might be better.
>
>    The reason I chose unoconv/OO.org is that it required only a few lines
>    of elisp to allow for viewing anything OO.org can read inside emacs.
>
> It seems reasonable to me.  In principle, writing ODF support in Emacs
> Lisp would be preferable, but that's a gigantic job and it might run
> too slowly.
>
> Anyway, even if this implementation is not ideal, it has the virtue of
> existing.  So we may as well install it.  If another method is
> implemented later, we could install that too.
>
> Is it feasible to implement of saving a buffer with formatting
> in ODF using this feature?  That would be really great.


Might be good to know that there at least soon will be an exporter
from org-mode to .odt files. Jambunathan has been working on this.

Re: DocView now supports OpenDocument & MS Office formats

[Stephen J. Turnbull]

Tassilo Horn writes:

 > But I think that conversion from and to ODF is not the right approach to
 > support ODF editing in Emacs.  Imagine a colleague sends you an ODF file
 > she created using LibreOffice, you convert it to something Emacs can
 > handle,

Uh, just teach jka-compr or crypt++ that it's a zipfile, and what
you'll see in the buffer is XML, no?  Since when is Emacs handicapped
w.r.t. XML?

It might be dog-slow to handle to full DTD, but that's another story.
There are any number of ways to dodge that bullet.

Re: DocView now supports OpenDocument & MS Office formats

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     The reason I chose unoconv/OO.org is that it required only a few lines
>     of elisp to allow for viewing anything OO.org can read inside emacs.
>
> It seems reasonable to me.  In principle, writing ODF support in Emacs
> Lisp would be preferable, but that's a gigantic job and it might run
> too slowly.

Note that unoconv itself is almost trivial.  It relies on what seems to
be a serialization library (a variant of CORBA?) for speaking to
OO/libreoffice; that may be more complicated, but it's not clear how
much is required to do the tasks docview wants to do.  If only a very
small subset is used, it might even be possible to simply hardwire those
bits needed.

-miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

Hi Stephen,

>  > But I think that conversion from and to ODF is not the right approach to
>  > support ODF editing in Emacs.  Imagine a colleague sends you an ODF file
>  > she created using LibreOffice, you convert it to something Emacs can
>  > handle,
>
> Uh, just teach jka-compr or crypt++ that it's a zipfile, and what
> you'll see in the buffer is XML, no?  Since when is Emacs handicapped
> w.r.t. XML?

No, you got me wrong.  Emacs already figures out it's a zip file, and of
course you can edit the content.xml in it (which is horrible slow,
because all the XML is on one line).  Maybe, one might need to update
some metadata as well, who knows, but that should be doable.

My concern was converting ODF to some more human-editable format like
LaTeX or DocBook.  And here, converting forth and back has a high
potential to lead to data loss for things the converters cannot handle,
like OpenDocument spreadsheets embedded in text documents.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>>     The reason I chose unoconv/OO.org is that it required only a few lines
>>     of elisp to allow for viewing anything OO.org can read inside emacs.
>>
>> It seems reasonable to me.  In principle, writing ODF support in Emacs
>> Lisp would be preferable, but that's a gigantic job and it might run
>> too slowly.
>
> Note that unoconv itself is almost trivial.  It relies on what seems
> to be a serialization library (a variant of CORBA?) for speaking to
> OO/libreoffice; that may be more complicated, but it's not clear how
> much is required to do the tasks docview wants to do.  If only a very
> small subset is used, it might even be possible to simply hardwire
> those bits needed.

Yes, that might be possible.  doc-view.el only uses the PDF export,
because that has a very good quality.  From that point on, the usual
doc-view PDF->PNG (and PDF->TXT for the search in documents) is applied.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Stephen J. Turnbull]

Tassilo Horn writes:

 > My concern was converting ODF to some more human-editable format like
 > LaTeX or DocBook.

Why not convert ODF to some more human-editable format like "ODF with
all the junk not displayed"?  (Aside from how slow it is.)

So, like, if it's REALLY all one line OR ODF DTDs don't care about
whitespace outside of (P)CDATA, add linebreaks and indentation where
ever you feel like it, and you can remove it at save time.  If not,
you'll have to be more careful about those linebreaks and other added
whitespace, but I'm sure some device can be found to mark them
reliably so they can be removed at save time (maybe even a text
property).  Save any embedded junk out to a file and replace it with
an entity or alternatively some sort of link element in an
emacscanthandlethiscruft namespace.  You know, like the way VM and
Gnus represent MIME attachments with "buttons" in the buffer.

The more stuff Emacs can't handle, the more stuff ends up replaced by
a short placeholder and the faster Emacs goes.  You can't lose! :-)

 > And here, converting forth and back has a high potential to lead to
 > data loss for things the converters cannot handle, like
 > OpenDocument spreadsheets embedded in text documents.

Sure.  So don't convert, fix the display of the XML.

Re: DocView now supports OpenDocument & MS Office formats

[Tom Tromey]

>>>>> "Jambunathan" == Jambunathan K <kjambunathan@coextrix.com> writes:

Jambunathan> Like Orgmode, for example? 
Jambunathan> http://www.emacswiki.org/emacs/OpenDocument 
Jambunathan> Above link talks of odf-mode and odt2org.
Jambunathan> Not so long ago, I had used odf-mode and was quite unhappy
Jambunathan> with the text extraction it was doing. I haven't tried
Jambunathan> odt2org though.

I also tried odf-mode with little joy.

I think it could probably be improved.  And, I think this would be
useful to do -- working with some reasonable subset of ODF would be
useful, if not perfect.  I think some other ODF editors also only handle
subsets.

One problem is that ODF is very large and has a lot of things that are
difficult or impossible to display in Emacs.

Tom

Re: DocView now supports OpenDocument & MS Office formats

[Eduard Wiebe]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Tue, 04 Jan 2011 08:38:38 +0100
>> Cc: monkey@sandpframing.com, jasonr@gnu.org, emacs-devel@gnu.org
>> 
>> > In principle, writing ODF support in Emacs Lisp would be
>> > preferable, but that's a gigantic job and it might run too slowly.
>> 
>> Indeed.  But IMO emacs is not really a WYSIWYG editor, and doesn't want
>> to be one anyway.
>
> Actually, Emacs does want to have at least specialized mode(s) that are
> WYSIWYG.  The beginning is in enriched-mode, and there's this entry in
> etc/TODO:
>
>   ** Program Enriched mode to read and save in RTF.  [Is there actually a
>     decent single definition of RTF?  Maybe see info at
>     http://latex2rtf.sourceforge.net/.]  This task seems to be addressed
>     by http://savannah.nongnu.org/projects/emacs-rtf/, which is still in
>     very early stages.
>
> Volunteers are welcome.

Try https://github.com/pusto/rtf-el

-- 
Eduard Wiebe

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    But I think that conversion from and to ODF is not the right approach to
    support ODF editing in Emacs.

What approach do you think is the right approach?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     But I think that conversion from and to ODF is not the right
>     approach to support ODF editing in Emacs.
>
> What approach do you think is the right approach?

I think, the approach Stephen described in

  <87hbdnh7o6.fsf@uwakimon.sk.tsukuba.ac.jp>

is the only feasible approach, i.e., directly read/write the
OpenDocument XML stuff and render it specifically.  Parts that emacs
doesn't know to handle at that point in time must be marked as such
(like with a construction site symbol).  Then a user would at least see
that there is an embedded table in the doc, and although he might not be
able to edit that, it would be still there after saving the document.

Bye,
Tassilo

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

    Try https://github.com/pusto/rtf-el

Could people determine whether we would like to install that?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 06 Jan 2011 13:42:45 -0500
> Cc: emacs-devel@gnu.org
> 
>     Try https://github.com/pusto/rtf-el
> 
> Could people determine whether we would like to install that?

It does the job, but clearly still needs work (layout is sometimes
incorrect or unpleasant, and I saw it err wrt to encoding of non-ASCII
characters at least once).  Visiting a 300K file takes about 20 sec,
which is quite slow, but tolerable.

It's possible that we should install this and continue developing
thereafter.

Re: DocView now supports OpenDocument & MS Office formats

[Eduard Wiebe]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Thu, 06 Jan 2011 13:42:45 -0500
>> Cc: emacs-devel@gnu.org
>> 
>>     Try https://github.com/pusto/rtf-el
>> 
>> Could people determine whether we would like to install that?

Sorry for the late reply,

> It does the job, but clearly still needs work 

Yes, it is far from "perfect".

> (layout is sometimes incorrect or unpleasant, and I saw it err wrt to
> encoding of non-ASCII characters at least once).

Have you any document samples? Than i could try to fix the known issues.

> Visiting a 300K file takes about 20 sec, which is quite slow, but
> tolerable.

> It's possible that we should install this and continue developing
> thereafter.

Fine with me.

-- 
Eduard Wiebe

Re: DocView now supports OpenDocument & MS Office formats

[Eli Zaretskii]

> From: Eduard Wiebe <usenet@pusto.de>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 08 Jan 2011 22:54:53 +0100
> 
> > (layout is sometimes incorrect or unpleasant, and I saw it err wrt to
> > encoding of non-ASCII characters at least once).
> 
> Have you any document samples? Than i could try to fix the known issues.

I'll try to collect them.

Re: DocView now supports OpenDocument & MS Office formats

[Richard Stallman]

IF we want to install https://github.com/pusto/rtf-el,
someone needs to see if we can get papers for it.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: DocView now supports OpenDocument & MS Office formats

[Eduard Wiebe]

Richard Stallman <rms@gnu.org> writes:

> IF we want to install https://github.com/pusto/rtf-el,
> someone needs to see if we can get papers for it.

I have already signed papers for emacs.

-- 
Eduard Wiebe

Re: DocView now supports OpenDocument & MS Office formats

[Kevin Rodgers]

On 1/5/11 12:38 AM, Tassilo Horn wrote:
> "Stephen J. Turnbull"<stephen@xemacs.org>  writes:
>>   >  But I think that conversion from and to ODF is not the right approach to
>>   >  support ODF editing in Emacs.  Imagine a colleague sends you an ODF file
>>   >  she created using LibreOffice, you convert it to something Emacs can
>>   >  handle,
>>
>> Uh, just teach jka-compr or crypt++ that it's a zipfile, and what
>> you'll see in the buffer is XML, no?  Since when is Emacs handicapped
>> w.r.t. XML?
>
> No, you got me wrong.  Emacs already figures out it's a zip file, and of
> course you can edit the content.xml in it (which is horrible slow,
> because all the XML is on one line).  Maybe, one might need to update
> some metadata as well, who knows, but that should be doable.

Maybe insert newlines when reading the XML in and delete them when writing it
out. (Newlines can safely be inserted before start-tags within element content.)

> My concern was converting ODF to some more human-editable format like
> LaTeX or DocBook.  And here, converting forth and back has a high
> potential to lead to data loss for things the converters cannot handle,
> like OpenDocument spreadsheets embedded in text documents.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: DocView now supports OpenDocument & MS Office formats

[Jambunathan K]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Emacs already figures out it's a zip file, and of course you can edit
> the content.xml in it (which is horrible slow, because all the XML is
> on one line).

One can instruct OpenOffice to save the xml files in such a way that it
is hand-editable. The option to tweak is under
Tools->Options->Load/Save->General->"Size Optimization for ODF
Format". This option has to be turned off.

http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Choosing_load_save_options

Jambunathan K.

-- 

Re: DocView now supports OpenDocument & MS Office formats

[Jambunathan K]

Richard Stallman <rms@gnu.org> writes:

>     > If there's another way to do the job, it might be better.
>
>     The reason I chose unoconv/OO.org is that it required only a few lines
>     of elisp to allow for viewing anything OO.org can read inside emacs.
>
> It seems reasonable to me.  In principle, writing ODF support in Emacs
> Lisp would be preferable, but that's a gigantic job and it might run
> too slowly.
>
> Anyway, even if this implementation is not ideal, it has the virtue of
> existing.  So we may as well install it.  If another method is
> implemented later, we could install that too.
>
> Is it feasible to implement of saving a buffer with formatting
> in ODF using this feature?  That would be really great.

I have added support for exporting Orgmode buffers to
OpenDocumentText. The module is in elisp and has no external
dependencies. The changes are in my private branch [1].

I encourage folks reading this message and in this thread to try out my
changes and give me feedback.

It was WIP when this thread was in progress. Now I believe org-odt.el is
quite usable, relatively stable and undergone some testing.

Footnotes: 
[1]  Refer http://orgmode.org/worg/org-faq.html#convert-to-open-office

-- 

Re: DocView now supports OpenDocument & MS Office formats

[Jambunathan K]

Hello Tassilo


>> Hm, I don't know.  It mostly depends on unoconv, which in turn depends
>> on OO.org.  I have version 0.4 installed here, but at least 0.3 should
>> be fine as well.
>
> I see.  On my Debian machines (6 year-old Debian testing installation
> which has accumulated pretty much all packages I've ever needed during
> those years), I don't have unoconv installed, so I think there's a good
> chance that many people don't have it installed.  This fact I think
> gives a first answer to "should we add .doc and .odt to
> auto-mode-alist": only if unoconv is available.

Thanks for adding support for converting odt files to pdf files.

I am wondering whether it would be possible to *not* make the unoconv
the default converter.

Speaking for myself, I had troubling getting unoconv-0.4 to work on my
Windows box right from the way go - mostly due to limited patience and
ignorance of python runtime. But I had better luck with using
OpenOffice.Org's Basic macros to convert my odt files to pdf [1].

So, may I propose following minor changes to doc-view.el?

Make doc-view-unoconv-program to be either an executable (as is now) or
a function pointer with the same signature as (defun doc-view-odf->pdf
(odf callback) ...) with one another argument that says where the
resulting pdf file need to be produced.

The above changes are minor and could be easily circumvented.

In summary what I am saying is this: All that docview needs is a pdf
file and how it is generated should be configureable and left to the
user's taste. This is particularly so when unoconv and the python
bindings it implies is not a de-facto standard.

Jambunathan k.

Footnotes: 

[1]  See the .bat wrapper and the macro code here:
http://user.services.openoffice.org/en/forum/viewtopic.php?f=20&t=39983

[2] On a related note. one can also "record macros" so generating quick
vb code for makeshift/one-off conversions from
odt->doc/rtf/xhtml/docbook would be a fairly straightforward task.

Following post has a recipe for converting using import/export filters
in inter-document conversions (The script is similar in spirit to the
way unoconv uses export filters)

http://user.services.openoffice.org/en/forum/viewtopic.php?f=21&t=23531

-- 

Re: DocView now supports OpenDocument & MS Office formats

[Tassilo Horn]

Jambunathan K <kjambunathan@gmail.com> writes:

Hi Jambunathan,

> I am wondering whether it would be possible to *not* make the unoconv
> the default converter.
>
> Speaking for myself, I had troubling getting unoconv-0.4 to work on my
> Windows box right from the way go - mostly due to limited patience and
> ignorance of python runtime. But I had better luck with using
> OpenOffice.Org's Basic macros to convert my odt files to pdf [1].

I have no experience with OO macros, but if that works then it's clearly
better than requiring an external tool with python dependencies.

Does that macro work for all files supported by OO.org/LibreOffice or is
it only for OOWriter?  (Your script calls oowriter and the macro
ConvertWordToPDF...)

> So, may I propose following minor changes to doc-view.el?
>
> Make doc-view-unoconv-program to be either an executable (as is now)
> or a function pointer with the same signature as (defun
> doc-view-odf->pdf (odf callback) ...) with one another argument that
> says where the resulting pdf file need to be produced.

Yes, please go ahead.  Thereby, doc-view-unoconv-program should be
renamed to doc-view-odf-converter or something like that.

Bye,
Tassilo