From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Possible problem with Gnus Date: 14 May 2004 23:18:06 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040509230720.GB20485@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084569999 25877 80.91.224.253 (14 May 2004 21:26:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 May 2004 21:26:39 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 14 23:26:34 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOkCQ-0006rw-00 for ; Fri, 14 May 2004 23:26:34 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOkCP-0000FW-00 for ; Fri, 14 May 2004 23:26:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOkAv-00020m-Qb for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 17:25:01 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOk69-0000zJ-Vi for emacs-devel@gnu.org; Fri, 14 May 2004 17:20:06 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOk4M-0000VQ-Un for emacs-devel@gnu.org; Fri, 14 May 2004 17:18:49 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOk4M-0000VE-Jx for emacs-devel@gnu.org; Fri, 14 May 2004 17:18:14 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BOk4F-0000Mk-OZ; Fri, 14 May 2004 17:18:08 -0400 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23427 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23427 Richard Stallman writes: > > If there are bugs in the Postscript support, please start > > reporting them one by one. This is a feature that is supposed > > to work, and if it doesn't, we should fix it. > > It is not a feature that is supposed to work. From the code in > lisp/gs.el: > > This makes it somewhat less urgent. But we still want this feature > to work. We should start fixing the problems in it, even if we do > so one by one. > > To set an example, I will add -dSAFER to gs-options. > > The only platform on which the postscript device works in the > first place is X11. > > That platform is more important than all the rest. > While we do support Windows and MacOS, they should never > weigh more in our decisionmaking than the GNU operating system. > > The sane thing to do is to serialize the whole GhostScript > operation to have at most one GhostScript process running, and > to not restart this process as long as images remain to be > rendered. > > That does sound desirable. However, > > For this to work, one has to stop passing the information > through an XPixMap but has to go through a file or pipe. > > Using a pixmap is preferable, in general. Why do you think > using a single Ghostscript process is incompatible with using > a pixmap? Because the interface to GhostScript that is used for passing the XPixMap Id and the respective sizes is queried just at the start of GhostScript. You can't change the size after GhostScript has started, so if you want to use one GhostScript process, it may only connect to a single XPixMap of fixed size. At least that's what I remember from last taking a look at the matter. > In contrast, preview-latex first deals with on-screen images. > Once they are dealt with, it reverts to rendering the rest > off-screen. > > That would be a good optimization to add. Rendering off-screen material is actually not as much an optimization, but an interactivity feature. It means that once GhostScript is through, scrolling through the file is not computationally expensive. However, if some document has thousands of images, it would be saner to render them just to disk in case you'll need them, but not burden Emacs' memory with them unless one actually moves there. If one wanted to fold a sizable chunk of the preview-latex concept into the display engine, then the display engine would need to a) be able to deal with general PostScript (multi-page) instead of isolated EPS files b) know which images belong to the same PostScript file, so that it will render them together, reading the PostScript resources of the file only once, like a PS previewer. The off-screen rendering/caching might be restricted to just images from a single PostScript file: savings are largest in that case. But investing serious work of that kind for the rather special case here would probably not be worth it unless one expanded the mechanism to be able to deal with more general conversion processes, like dvi->ps->png or gnuplot->png or stuff like that. If one would really want to immerse oneself into stuff like that, one would probably want some more general image rendering/embedding mechanism. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum