From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel 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 Message-ID: <87haljxy26.fsf@uwakimon.sk.tsukuba.ac.jp> References: <877gmgbl4h.fsf@bzg.ath.cx> <87y5evmsim.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1360557685 5737 80.91.229.3 (11 Feb 2013 04:41:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 04:41:25 +0000 (UTC) Cc: Bastien , emacs-devel@gnu.org, Stefan Monnier , Tassilo Horn To: Jambunathan K Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 05:41:42 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4lCz-0006Mu-Vk for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 05:41:38 +0100 Original-Received: from localhost ([::1]:45120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4lCg-0005pY-Q2 for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2013 23:41:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4lCd-0005pS-F1 for emacs-devel@gnu.org; Sun, 10 Feb 2013 23:41:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4lCc-0006Si-7z for emacs-devel@gnu.org; Sun, 10 Feb 2013 23:41:15 -0500 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:54723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4lCb-0006Qi-Nw for emacs-devel@gnu.org; Sun, 10 Feb 2013 23:41:14 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 4786C3FA076A; Mon, 11 Feb 2013 13:40:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 066AE1A3C34; Mon, 11 Feb 2013 13:40:49 +0900 (JST) In-Reply-To: <87y5evmsim.fsf@gmail.com> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156956 Archived-At: >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.