unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Jambunathan K <kjambunathan@gmail.com>
Cc: Bastien <bzg@gnu.org>,
	emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	Tassilo Horn <tsdh@gnu.org>
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	[thread overview]
Message-ID: <87haljxy26.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87y5evmsim.fsf@gmail.com>

From the unoconv home page:

    Requirements
    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!)

Footnotes: 
[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	other threads:[~2013-02-11  4:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1U47Uj-0004Wk-3p@vcs.savannah.gnu.org>
2013-02-09 14:26 ` [Emacs-diffs] /srv/bzr/emacs/trunk r111707: * doc-view.el: Use (and prefer) soffice as default ODF->PDF Stefan Monnier
2013-02-09 20:03   ` Glenn Morris
2013-02-10  0:26     ` Glenn Morris
2013-02-10  8:57       ` Bastien
2013-02-10 20:51         ` Glenn Morris
2013-02-11  3:36           ` Jambunathan K
2013-02-11  4:40             ` Stephen J. Turnbull [this message]
2013-02-12  9:59               ` Tassilo Horn
2013-02-12 11:58                 ` Tassilo Horn
2013-02-10 11:07   ` Tassilo Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87haljxy26.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=bzg@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kjambunathan@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=tsdh@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).