From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Displaying scrollable images in a grid-layout Date: Wed, 15 Apr 2015 19:05:27 +0300 Message-ID: <83wq1d9y2g.fsf@gnu.org> References: <87pp785u5a.fsf@hochschule-trier.de> <83r3rocbzr.fsf@gnu.org> <87bnirzur7.fsf@hochschule-trier.de> <83egnndb93.fsf@gnu.org> <873842vnwp.fsf@gnu.org> <83twwibw64.fsf@gnu.org> <877ftesebt.fsf@gnu.org> <831tjmazgz.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429114536 25527 80.91.229.3 (15 Apr 2015 16:15:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Apr 2015 16:15:36 +0000 (UTC) Cc: emacs-devel@gnu.org, politza@hochschule-trier.de, tsdh@gnu.org To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 15 18:15:28 2015 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 1YiPyI-00010m-IH for ged-emacs-devel@m.gmane.org; Wed, 15 Apr 2015 18:15:26 +0200 Original-Received: from localhost ([::1]:33060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiPyH-0004qX-MQ for ged-emacs-devel@m.gmane.org; Wed, 15 Apr 2015 12:15:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiPps-000804-5N for emacs-devel@gnu.org; Wed, 15 Apr 2015 12:06:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiPpp-0003U9-8J for emacs-devel@gnu.org; Wed, 15 Apr 2015 12:06:44 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:49338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiPpp-0003Tz-0c; Wed, 15 Apr 2015 12:06:41 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NMU00B00V2AG500@a-mtaout20.012.net.il>; Wed, 15 Apr 2015 19:05:12 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMU00BC5VCOE740@a-mtaout20.012.net.il>; Wed, 15 Apr 2015 19:05:12 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:185461 Archived-At: > From: Yuri Khan > Date: Wed, 15 Apr 2015 10:17:02 +0600 > Cc: Tassilo Horn , politza@hochschule-trier.de, > Emacs developers > > > ??? Why does it make sense to show a partial line, when we can show it > > in its entirety? Can you explain? > > You assume that the line is a bigger unit than the image, that the > image is part of the line. However, in PDF viewers, an image of a > whole page contains many lines of text. I meant the Emacs screen line, a.k.a. "glyph row" in the display engine terminology; sorry for not being clear. A screen line in Emacs can never be smaller than its largest element, be that some character glyph, image, or whatnot. > Many people, when confronted with a need to read documents in PDF > format, scroll the parts they have already read past the top window > edge, so that the window edge tracks where they are reading. This way, > if they are distracted, they can continue reading immediately without > having to find the last sentence they read. I don't think you are talking about the same issue as Andreas was. His original use case was with thumbnails, which are by definition small images unfit for displaying any significant amounts of text embedded in the image. By contrast, when viewing an image generated from PDF, the image of a standard page of a document should usually be quite tall, so it should be easy to have pixel-wise scrolling that you describe with the current codebase. Moreover, what you describe above about having the already read part scrolled out of view only makes sense when there's a significant amount of text shown in the image, which again tells me that you refer to tall images for which pixel-wise scrolling is already supported by C-p/C-n and up- and down-arrows, and also by the equivalent mouse gestures. If the PDF viewing command wants to support this feature for images smaller than the window height, it could display the image in slices, I think. Emacs already supports such display. If a screen line holds only a portion of an image, then it should be possible to scroll only that portion with the current display code. > The UI gesture for such reading mode is either mouse scrolling or > pressing the arrow repeatedly or continuously. In both cases, > the reader wants scrolling to be as smooth as possible, ideally, with > each press or each wheel step scrolling by a constant number of > pixels. (Mouse scrolling may be further improved with acceleration, > but also based on pixels, not logical lines.) Smooth pixel-wise scrolling of arbitrary stuff on display should be possible, as the infrastructure for that already exists in the form of a window's vscroll value. However, supporting this consistently on the user level will require non-trivial changes in the part of the display engine that decides how much to scroll, because currently that part is heavily biased towards avoiding partial screen lines whenever possible. This bias exists both on the C level and on the Lisp level (see line-move and line-move-partial, for example, which are the workhorses of visual line movement we use all the time). Moreover, this bias is heavier when the screen line in question includes point. The reason for this bias is clear: the display engine was designed and implemented primarily for showing variable-size text with only a few images; if that assumption is invalidated, many design and implementation decisions will be invalid as well.