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: Several suggestions for image support Date: 16 Apr 2004 12:06:27 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082110157 2115 80.91.224.253 (16 Apr 2004 10:09:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2004 10:09:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 16 12:09:12 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 1BEQHY-0001NM-00 for ; Fri, 16 Apr 2004 12:09:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEQHY-0003AP-00 for ; Fri, 16 Apr 2004 12:09:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEQGl-0000KM-6K for emacs-devel@quimby.gnus.org; Fri, 16 Apr 2004 06:08:23 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEQGQ-000079-Q0 for emacs-devel@gnu.org; Fri, 16 Apr 2004 06:08:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEQFr-0007u9-9A for emacs-devel@gnu.org; Fri, 16 Apr 2004 06:07:58 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEQEq-0007E6-9E for emacs-devel@gnu.org; Fri, 16 Apr 2004 06:06:24 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BEQEG-0006Ie-9V; Fri, 16 Apr 2004 06:05:48 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 75 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:21742 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21742 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > > > PNG images support transparency. Emacs can't make use of it. You can > > only have Emacs declare a particular color as transparent. This is > > dissatisfactory. It should tell the PNG decoding routines Emacs' > > background color for the purpose of transparency. > > Using `:mask heuristic' should make the image background transparent. > The tool-bar code uses this. > > I suppose you know that, so what's the problem with this approach? That it does not work. It only works when the majority of corner pixels has the transparent color. Also it is impossible for an image to have, say, both white and transparent color. Since transparency is a feature of PNG files, is there any particular reason not to just use the information, preferring some heuristic hack to it that does not work in all circumstances? > > I would find it important if an image specifier could restrict the > > displayed portion of an image. > > This might be useful for other reasons, e.g. image panning. > Zoom (scaling) would be useful too. > > > The reason is that large images always appear as a single big > > character to Emacs. If I could split such an image into a bunch of > > smaller images, I could walk through it with the cursor. But it > > should only be necessary to instantiate the complete image itself once > > for this purpose. Of course, one should find a way that does not > > cause all of the subimages to be entered separately into the image > > cache. > > Something like this is already on my to-do list. > > However, I have other ideas to make image scrolling work, and it > is at the top of my to-do list. This is not mainly for making image scrolling work (it would be quite overkill for that). This is to split an image into addressable items. For example, preview-latex will turn a tabular into one large graphic. If I click on that graphic at a particular point, the whole graphic dissolves into text and the cursor is positioned at the start of the tabular. This is pretty useless if the table is large because you still have to find your point. If instead just the table cell opened and the cursor would be positioned there, one could use this for serious table editing. Since the whole table is available as one graphic, loading hundreds of separate images would be inconvenient. It is conceivable to split the image within TeX and load it as separate graphics. However, the involved complexity is far greater if I want to keep the alignment intact. It would also mean that I could walk the cursor through _rows_ of the preview-latex image instead of having to walk through it all at once. Image scrolling is a different problem: it does not involve actually changing the value of point. Of course, a different possibility would be to just display one image, but have a way of walking the cursor display across it. This would have the advantage that the table would have its optical integrity preserved (no line spacing between rows of the table), and the disadvantage that you could only open the whole table at once into text, not just a cell in between. It would probably be nice to have a way of tiling an image into areas with individual property lists (posn-point, keymap, mouse-highlighting...). But that's just phantasizing for the future. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum