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: 18 Apr 2004 23:30: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 1082316863 6069 80.91.224.253 (18 Apr 2004 19:34:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2004 19:34:23 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Apr 18 21:34:15 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 1BFI3T-00080H-00 for ; Sun, 18 Apr 2004 21:34:15 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BFI3T-0006d5-00 for ; Sun, 18 Apr 2004 21:34:15 +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 1BFI27-0004e2-8w for emacs-devel@quimby.gnus.org; Sun, 18 Apr 2004 15:32:51 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BFI1K-0004N5-1a for emacs-devel@gnu.org; Sun, 18 Apr 2004 15:32:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BFI0m-0003tO-0A for emacs-devel@gnu.org; Sun, 18 Apr 2004 15:31:59 -0400 Original-Received: from [195.41.46.236] (helo=pfepb.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BFI0D-0003Vi-VU; Sun, 18 Apr 2004 15:30:54 -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 EDFD25EE039; Sun, 18 Apr 2004 21:30:52 +0200 (CEST) Original-To: David Kastrup 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:21849 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21849 David Kastrup writes: > Richard Stallman writes: > > > Emacs should have a way to scroll through an image, > > so that C-v each time can advance one window-height > > through the image. > > > > It would be inelegant to handle this by treating the tall > > image as several lines--but perhaps that might actually > > work more easily than some other methods. > > I don't think that splitting the image into lines by Emacs itself is > feasible: the cursor positions on the image would need to correspond > to actual cursor positions in the buffer, or things get inconsistent > (Emacs moves out of cursor positions in the image automatically). > While it would be a real boost of usability for my main application > (preview-latex) if I could walk the cursor across lines or other areas > of an image, the correlation between buffer positions and > corresponding location of the cursor display would need to get > explicitly established by the application: it would imply "stopping > points" when Emacs is trying to move the cursor out of visually > inaccessible areas. And then Emacs would have to draw a cursor box or > other indicator according to the location in there. Substructuring an > image like that would be a very nice feature. But I don't see that > it is possible to make the decision of where to split an image > mechanically. I have written some code (not too complex) which can split an image into individual row, and each of those rows into individual "slices" on each row, e.g. +--------+--------------+--------------+ | | | | | | | | POSSIBLE +--------+-----+-----------------------+ SLICING | | | | | | | | | | | | +--------------+-----------------------+ The major limitation of this is that all "slices" in one row is (and must be) of equal height - the height of the row. This is because emacs display engine is still row based, meaning that all "glyphs" on a row are padded with empty space in top and bottom to make all glyphs on the row of the same height (this is not entirely true, but you get the picture.) In principle, my implementation can take any slice of an image and combine it with any other slice of the same image, but the display engine does not allow those slices to be placed arbitrarily in the window, i.e. overlap rows like this: +----------------+---------------------+ | | | | | | | +---------------------+ IMPOSSIBLE | | | SLICING | | | +----------------| | | | | | | | +----------------+---------------------+ David, what are the requirements for preview-latex ? > > Of course, scrolling through large images should be possible, anyway, > and quite independent from that fanciful features. Emacs already has > set-window-vscroll in its display engine in order to deal perfectly > well with that. Yes, and it could probably be done entirely in lisp !? -- Kim F. Storm http://www.cua.dk