From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Several suggestions for image support Date: 23 Apr 2004 01:32:10 +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 1082669833 22055 80.91.224.253 (22 Apr 2004 21:37:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2004 21:37:13 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 22 23:36:55 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 1BGlsM-0007pD-00 for ; Thu, 22 Apr 2004 23:36:54 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BGlsM-0007iI-00 for ; Thu, 22 Apr 2004 23:36:54 +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 1BGlpO-0006Fq-H9 for emacs-devel@quimby.gnus.org; Thu, 22 Apr 2004 17:33:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BGlpB-0006F6-6s for emacs-devel@gnu.org; Thu, 22 Apr 2004 17:33:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BGloe-000686-Ho for emacs-devel@gnu.org; Thu, 22 Apr 2004 17:33:36 -0400 Original-Received: from [195.41.46.236] (helo=pfepb.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BGlo7-00060p-OT; Thu, 22 Apr 2004 17:32:31 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepb.post.tele.dk (Postfix) with SMTP id 020A05EE05F; Thu, 22 Apr 2004 23:32:27 +0200 (CEST) Original-To: David Kastrup In-Reply-To: Original-Lines: 74 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:22046 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22046 David Kastrup writes: > Richard Stallman writes: > > > I wonder if slicing images is really the right approach to take. It > > will make possible scrolling through an image, though the interline > > spacing will appear between the slices, which would be ugly. > > Unless we provide a way to suppress the interline spacing in that > case. I specifically reworked the interline spacing code to avoid adding extra spacing in this case. This is generally useful to properly display "pre-sliced" images which are very common on web pages. > > > anyway, requiring programs that display images to slice them is > > rather kludgy. > > Yes, most certainly. Scrolling through images should be possible > without slicing. I agree that it would be a really bad kludge if the > only way to scroll through images would be to require a program to > slice them. I never intended slicing to be used for image scrolling -- it _can_ be used for that, but it was implemented for other purposes. In any case, slicing of images is a general way to display one or more individual sections of a bigger image -- aka "cropping". E.g. with image slicing you can implement the good old 1 2 3 4 5 6 7 8 8 9 A B C D E X puzzle in emacs (I'm not going to do that :-) > > > Is there some other reason to prefer to handle images by slicing > > them? > > I would not recommend them as a general mechanism. However, in the > particular application for which I have asked for this feature, every > slice is associated with a different piece of source code that is > covered by it. Splitting the image is not as much a tool for > managing the display of the image than it is for managing control of > the source code. > > When the source code gets uncovered, it would be convenient to have > the cursor at the location corresponding to where the mouse pointed. > Slicing the image makes this possible. If I use the mouse to mark a > region on the images, this will copy and paste just the text > corresponding to that pieces of the images which have been marked. If > I edit a table cell, only the image of the cell I am editing at the > moment will be replaced by the actual text. In short: I need the > slicing for an application where it is the natural way of dealing > with the image. > > Whereas the proposal to demand applications to artificially slice > their images or Emacs will scroll badly would be an unnatural way of > dealing with it. > > I agree with you that slicing is not a solution to the bad scrolling > of Emacs with regard to images. I just implemented some functions requested by Stefan to assist implementing image scrolling in lisp. -- Kim F. Storm http://www.cua.dk