[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r111707: * doc-view.el: Use (and

From: Stephen J. Turnbull
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r111707: * doc-view.el: Use (and prefer) soffice as default ODF->PDF
Date: Mon, 11 Feb 2013 13:40:49 +0900

>From the unoconv home page:

    unoconv is written in python. It needs a recent LibreOffice or
    OpenOffice with UNO bindings.

For what it's worth, Jambunathan K writes:

 > unoconv does NOT depend on libreoffice-common

Always cross-check what a package manager tells you for this kind of
information.  Package managers have completely different model of the
world from humans.

 > >> I'm not sure I get the logic here: you need to have soffice
 > >> installed if you want to use unoconv, but being able to use
 > >> unoconv instead of soffice is good.

That's true for the *user* at the command line, but for Emacs it
depends on how unoconv is being used.  If the UI provides a Swiss Army
knife able to convert any given format to any other by delegating the
format grokking to unoconv, yes, it's sort of good, assuming that
Emacs will never pass incorrect arguments to unoconv.[1]  In that case
unoconv (and any other "universal converters") should be tried only
after specific converters that do a better job are tried.[2]

If in fact what happens is that Emacs parses the formats and only
handles formats that it recognizes, unoconv is useless to Emacs.  (I
suspect this is rarely what most users want[3], but I prefer it.  If
Emacs can't do a good job automatically, it should leave it up to me!)

[1]  It's OK if Emacs passes arguments that unoconv *can't* convert;
what I'm referring to here is a situation where unoconv could convert
if given certain information that Emacs does know in the correct
format, but because Emacs's "generic" invocation of unoconv either
fails to provide the information, or fails to invoke the command with
correct syntax, the command fails.

[2]  There may be none.  Seems unlikely to me though, given how
horribly unreliable even Microsoft Office software is for producing
high-quality output across platforms.

[3]  IME most users will accept any garbage that comes out as long as
a program has generated it because they're happy to blame the program
if somebody bitches about poor quality.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]