From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 23:18:15 2017 Received: (at submit) by debbugs.gnu.org; 21 Feb 2017 04:18:15 +0000 Received: from localhost ([127.0.0.1]:48075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cg1u3-00034O-9d for submit@debbugs.gnu.org; Mon, 20 Feb 2017 23:18:15 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cg1u0-00034B-QA for submit@debbugs.gnu.org; Mon, 20 Feb 2017 23:18:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cg1tu-0005wq-EN for submit@debbugs.gnu.org; Mon, 20 Feb 2017 23:18:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50627) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cg1tu-0005wj-At for submit@debbugs.gnu.org; Mon, 20 Feb 2017 23:18:06 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cg1tt-0003nm-10 for bug-gnu-emacs@gnu.org; Mon, 20 Feb 2017 23:18:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cg1to-0005u1-Vk for bug-gnu-emacs@gnu.org; Mon, 20 Feb 2017 23:18:04 -0500 Received: from mail-pg0-x236.google.com ([2607:f8b0:400e:c05::236]:34430) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cg1to-0005tg-PY for bug-gnu-emacs@gnu.org; Mon, 20 Feb 2017 23:18:00 -0500 Received: by mail-pg0-x236.google.com with SMTP id 1so10417823pgi.1 for ; Mon, 20 Feb 2017 20:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=tuEiCuyB11ye8vfnBZPnvITXqqz/lYHCBPnT3ugZiQc=; b=ONeDEkhHNeQHKbbdCzDL0Egqhz/KjNEK6zwLt3jhULtk8wpZlFaBfZGlzvV1Hi//kJ mNJaALik4jZSVwAgQi/+UlYBIDZWo2BYy9fYxkKihTZxJvGQJT4gTCFLaAbTbLkN9Kq4 ADh9vbCbDUQaMLolHizUdkYKHEl9kPcZWY6FaN7tB+6h1B0ghDRK8HmLFI50SCKcVYkK 8kdXmVWMOf3VOyVIDnsQLCqiAMsLjzw22prL9VZOo2nKkhdfTJ/qrPzgAS+9atQUYhiY RFj+XCI7lBVQ0RaWj1ZrHAcZbrRLW43fAE2GNsw+/9CRLarGFuIuLVYs8+1ygMEAE+8M +z6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=tuEiCuyB11ye8vfnBZPnvITXqqz/lYHCBPnT3ugZiQc=; b=bvMDuLiC37JQ24g/GF4242JsdOQI4uOeoab+lNiL7pg8RucoxRZYxc6oqtixLZJE/L rljd+X3miW8c4CXfOV0qOl+ipv7S/OcoH0Q4KXkRjYYYUoV7xcX0Qz1CKH/gkZX5n7jG p/M+VrAz26ZZZ05CU71xt6hYbULgLmR6TVbtQFXwJb0+gWuYsBceWlHUxmadeUPHhUNE qXgZk31/jo0bXR5trYHpvC9dpQ0eIztDUsP0LZ6FcYFfUN1E+GMxSCidEWxNjfpNWLYK 5gAkNMLlpuS7fVBJVadM1dJMxIiHsGJvd8Ee1bXdK1g8f9+YgSq/zit/Kaj2SfnTVWW9 jMWg== X-Gm-Message-State: AMke39kNjQaZJ/mHSqfP/jvtU9X7rNNSW9KFW2idIHs7n5DhPDQVLySsYnQxIiW1kmG2Yw== X-Received: by 10.99.131.198 with SMTP id h189mr23615583pge.226.1487650679382; Mon, 20 Feb 2017 20:17:59 -0800 (PST) Received: from PNUT-PC (east24-p58.eaccess.hi-ho.ne.jp. [218.42.167.59]) by smtp.gmail.com with ESMTPSA id z29sm27071666pgc.7.2017.02.20.20.17.57 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Feb 2017 20:17:58 -0800 (PST) From: ynyaaa@gmail.com To: bug-gnu-emacs@gnu.org Subject: 25.1; bugs about display specfications Date: Tue, 21 Feb 2017 13:17:58 +0900 Message-ID: <87poicrxc9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) I found 4 bugs about display specifications. ------------------------------------------------------------ (1) raise display specification may be affected by height specification. This form displays two X's on the same height. (insert "A" (propertize "X" 'display '((raise 1) (height 1))) (propertize "X" 'display '((raise 1) (height 2)))) But the form below displays second X heigher than first X. The order in the display property is swapped. (insert "A" (propertize "X" 'display '((height 1) (raise 1))) (propertize "X" 'display '((height 2) (raise 1)))) ------------------------------------------------------------ (2) height display specification may not be applied to STRING specification. This form displays a large string. (insert (propertize "X" 'display '((height 2) "TEST"))) But the form below displays a normal size string. (insert (propertize "X" 'display '("TEST" (height 2)))) ------------------------------------------------------------ (3) raise display specification is not applied to STRING specification. This form displays strings on the base line. (insert (propertize "X" 'display '((raise 1) "TEST1")) (propertize "X" 'display '("TEST2" (raise 1)))) ------------------------------------------------------------ (4) raise display specification may display needless space. This form displays needless space over A, as if raise specification is not specified. (insert "A" (propertize "X" 'display '((raise -1) (height 2)))) In GNU Emacs 25.1.1 (i686-w64-mingw32) of 2016-09-18 built on LAPHROAIG Windowing system distributor 'Microsoft Corp.', version 6.0.6002 Configured using: 'configure --host=i686-w64-mingw32 --without-dbus --without-compress-install CFLAGS=-static' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS Important settings: value of $LANG: JPN locale-coding-system: cp932 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils misearch multi-isearch rect help-mode easymenu cl-loaddefs pcase cl-lib debug time-date mule-util japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 multi-tty make-network-process emacs) Memory information: ((conses 8 97029 6894) (symbols 32 19796 0) (miscs 32 83 406) (strings 16 16516 4085) (string-bytes 1 445422) (vectors 8 13376) (vector-slots 4 521906 4206) (floats 8 167 397) (intervals 28 919 15) (buffers 520 20)) From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 12:38:42 2017 Received: (at 25824) by debbugs.gnu.org; 21 Feb 2017 17:38:42 +0000 Received: from localhost ([127.0.0.1]:49152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgEOg-0006gH-Hf for submit@debbugs.gnu.org; Tue, 21 Feb 2017 12:38:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgEOe-0006g0-Ge for 25824@debbugs.gnu.org; Tue, 21 Feb 2017 12:38:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgEOU-0000QD-Et for 25824@debbugs.gnu.org; Tue, 21 Feb 2017 12:38:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgEOU-0000Pr-BE; Tue, 21 Feb 2017 12:38:30 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2164 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cgEOT-0004VA-FY; Tue, 21 Feb 2017 12:38:29 -0500 Date: Tue, 21 Feb 2017 19:37:54 +0200 Message-Id: <83h93no365.fsf@gnu.org> From: Eli Zaretskii To: ynyaaa@gmail.com In-reply-to: <87poicrxc9.fsf@gmail.com> (ynyaaa@gmail.com) Subject: Re: bug#25824: 25.1; bugs about display specfications References: <87poicrxc9.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 25824 Cc: 25824@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: ynyaaa@gmail.com > Date: Tue, 21 Feb 2017 13:17:58 +0900 > > I found 4 bugs about display specifications. Thank you for your report. I don't think these are bugs, but perhaps we should clarify the expected behavior in the docs some more. > (1) raise display specification may be affected by height specification. > > This form displays two X's on the same height. > > (insert "A" > (propertize "X" 'display '((raise 1) (height 1))) > (propertize "X" 'display '((raise 1) (height 2)))) > > But the form below displays second X heigher than first X. > The order in the display property is swapped. > > (insert "A" > (propertize "X" 'display '((height 1) (raise 1))) > (propertize "X" 'display '((height 2) (raise 1)))) This should be expected. The display properties in a spec that is a list or a vector are processed one after the other, left to right (which is really the only way that makes sense and that will produce deterministic results). And the documentation about 'raise' says: ‘(raise FACTOR)’ [...] FACTOR must be a number, which is interpreted as a multiple of the height of the affected text. So when the previous element of the display spec changes the height, FACTOR converted to pixels will also change accordingly. (The documentation goes on to say something that could be interpreted as contradicting the above, but that is just plain confused/wrong, and certainly doesn't match the implementation.) > (2) height display specification may not be applied to STRING specification. As expected: 'height' affects display of the text in the buffer covered by the property, but a display string completely conceals that text, so the result is undefined. > This form displays a large string. > > (insert (propertize "X" 'display '((height 2) "TEST"))) > > But the form below displays a normal size string. > > (insert (propertize "X" 'display '("TEST" (height 2)))) The latter is just a side effect of implementation details. Display string and 'raise'/'heaight' specs don't make sense together in the same display spec. > (3) raise display specification is not applied to STRING specification. > > This form displays strings on the base line. > > (insert (propertize "X" 'display '((raise 1) "TEST1")) > (propertize "X" 'display '("TEST2" (raise 1)))) Likewise. > (4) raise display specification may display needless space. > > This form displays needless space over A, > as if raise specification is not specified. > > (insert "A" (propertize "X" 'display '((raise -1) (height 2)))) The space is needed to accommodate the enlarged X on the same screen line. Emacs display engine doesn't require that all the glyphs on a line be of the same size, but it does require them to have the same baseline (the display geometry is that of a canvas). Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 22 21:53:22 2017 Received: (at 25824) by debbugs.gnu.org; 23 Feb 2017 02:53:22 +0000 Received: from localhost ([127.0.0.1]:51799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgjX0-0004Of-Gr for submit@debbugs.gnu.org; Wed, 22 Feb 2017 21:53:22 -0500 Received: from mail-pg0-f43.google.com ([74.125.83.43]:33466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgjWz-0004OT-Ba for 25824@debbugs.gnu.org; Wed, 22 Feb 2017 21:53:21 -0500 Received: by mail-pg0-f43.google.com with SMTP id z128so8945542pgb.0 for <25824@debbugs.gnu.org>; Wed, 22 Feb 2017 18:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:mime-version; bh=IkJEP/Tp55BI57kUEFotYtDl+/T/oQDPKHRvxMo+i30=; b=jr2aZu2rzDd+gH8+odQBGPWNbn/3pISraEQNTFkdVoUmhzRCGpZuRRfKizNmYsUuiz l6hUAG4cjSbpE9jvfOoLyouLSrKXQtrqUd4DA2Hx0hJCVMDwBXG1YD4e8qzHGjmPhUZm TI8wiWLsb3UWigSy06VnQhvmP2KsV30VTc5s/v+2xgdnwuFms1wojAcH7nZ4EIbFcarO T93veDChlrirgIFQozO3kWmQyAQ7CLmDik/Se5npQBDtNXwRwpBcXLfjT7vydIwsaMr+ z93iZyf6wfmzGyG3k4AkoF7h0XL2sdwbMZ6fDb1XNDPMpqH+YIiwkZ2oEosBm9QK0x2r S7qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :mime-version; bh=IkJEP/Tp55BI57kUEFotYtDl+/T/oQDPKHRvxMo+i30=; b=pT7R28FCiqEbtKJtUjZHNvzLYZz0PVN8rFLXYav/2mrjp92/+HfH6eT5NxqoxNZo3C 9j0UMhkgWdkqt6MwYwUpBFFLs519Gvk+5J4/IxvdseLVF+MNFmoTwRXihHqlMJYHz2cN kzcgkj7mKXo4TLd6ISkL6TDT5dAmFG1ltEG2fHqcXeGUX3V0S0D/FJIC5pKGeAwV1omf JRjB3K+4gwx2pG1cKAFLV+EcODOT3Rqq1ONHRzMJL9dMbpmV6gU+1Ar49T2a7sVGeXO3 U+bGr0Nc85KIOFF1i+GUxgXxt+M+6AobepliXRP32/Gj1uxLnFJh7VaW5CE8vsS70KEB jMZA== X-Gm-Message-State: AMke39lSZW9pgTm6O2V75oLz8YoN5HSHnaVkkp2fLkUCsG5zW6G1bSEvuWRt0p4QLSuORQ== X-Received: by 10.98.112.134 with SMTP id l128mr43384021pfc.81.1487818395310; Wed, 22 Feb 2017 18:53:15 -0800 (PST) Received: from pnut-PC (east24-p58.eaccess.hi-ho.ne.jp. [218.42.167.59]) by smtp.gmail.com with ESMTPSA id m3sm5983331pfc.66.2017.02.22.18.53.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Feb 2017 18:53:14 -0800 (PST) From: ynyaaa@gmail.com To: Eli Zaretskii Subject: Re: bug#25824: 25.1; bugs about display specfications References: <87poicrxc9.fsf@gmail.com> <83h93no365.fsf@gnu.org> Date: Thu, 23 Feb 2017 11:53:16 +0900 Message-ID: <87y3wxfwir.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 25824 Cc: 25824@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.1 (/) Eli Zaretskii writes: > Display > string and 'raise'/'heaight' specs don't make sense together in the > same display spec. The height of the replacing text can be controlled by its face. Is there any chance to 'raise' the replacing text? > The space is needed to accommodate the enlarged X on the same screen > line. Emacs display engine doesn't require that all the glyphs on a > line be of the same size, but it does require them to have the same > baseline (the display geometry is that of a canvas). I don't understand the relation between the space and the baseline. I want to display large text centered vertically. But there is a blank area over the large text. I expect line-pixel-height of a line with 5 times larger text is 5 times larger than a normal line. Practically, if the large text is 'raise'd negative, line-pixel-height is 5 times plus 'raise'd pixels larger. (with some computational error) ;; normal line (line-pixel-height) =>22 ;; large text without raise specification (progn (insert "normal" (propertize "LARGE" 'display '((height 5)))) (beginning-of-line) (line-pixel-height)) =>107 ;; cap height is 14 and line height is 22 ;; 'raise' -2 * cap height pixels (progn (insert "normal" (propertize "LARGE" 'display '((raise -1.2727) (height 5)))) (beginning-of-line) (line-pixel-height)) =>134 By the way, if the baseline height is same, I think consecutive underlines should be displayed as one straight line. The form below shows three underlines with different height. (insert (propertize "X" 'face '(:underline t)) (propertize "X" 'face '(:underline t) 'display '((raise -1))) (propertize "X" 'face '(:underline t) 'display '((raise 1)))) As for overlines, they are displayed as one straight line. (insert (propertize "X" 'face '(:overline t)) (propertize "X" 'face '(:overline t) 'display '((raise -1))) (propertize "X" 'face '(:overline t) 'display '((raise 1)))) From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 10:52:27 2017 Received: (at 25824) by debbugs.gnu.org; 23 Feb 2017 15:52:27 +0000 Received: from localhost ([127.0.0.1]:53151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgvgx-0002o3-9B for submit@debbugs.gnu.org; Thu, 23 Feb 2017 10:52:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgvgu-0002nm-IW for 25824@debbugs.gnu.org; Thu, 23 Feb 2017 10:52:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgvgm-0004Rf-8q for 25824@debbugs.gnu.org; Thu, 23 Feb 2017 10:52:19 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgvgm-0004Rb-5B; Thu, 23 Feb 2017 10:52:16 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4232 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cgvgl-0006v5-EM; Thu, 23 Feb 2017 10:52:15 -0500 Date: Thu, 23 Feb 2017 17:51:46 +0200 Message-Id: <834lzkucq5.fsf@gnu.org> From: Eli Zaretskii To: ynyaaa@gmail.com In-reply-to: <87y3wxfwir.fsf@gmail.com> (ynyaaa@gmail.com) Subject: Re: bug#25824: 25.1; bugs about display specfications References: <87poicrxc9.fsf@gmail.com> <83h93no365.fsf@gnu.org> <87y3wxfwir.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 25824 Cc: 25824@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: ynyaaa@gmail.com > Cc: 25824@debbugs.gnu.org > Date: Thu, 23 Feb 2017 11:53:16 +0900 > > Eli Zaretskii writes: > > Display > > string and 'raise'/'heaight' specs don't make sense together in the > > same display spec. > > The height of the replacing text can be controlled by its face. > Is there any chance to 'raise' the replacing text? Only if the replacement comes from a before- or after-string (in which case the text won't be replaced, so you will have to hide it with some invisible property). Put the 'raise' display property on the overlay string, and you will have what you want. > > The space is needed to accommodate the enlarged X on the same screen > > line. Emacs display engine doesn't require that all the glyphs on a > > line be of the same size, but it does require them to have the same > > baseline (the display geometry is that of a canvas). > > I don't understand the relation between the space and the baseline. Maybe this snippet will help: (insert "A" (propertize "X" 'display '((raise -1) (height 2))) (propertize "X" 'display '((height 2)))) After evaluating this, move the cursor between the 2 "X"s and look at the top edge of the cursor block. Do you see that the top edge is at the same vertical coordinate in both cases? Do you also see that there's enough space above the 1st (lowered) "X" to display a non-lowered "X"? What the display engine does is reserve space above the baseline that is large enough for the enlarged font, and then draw the "X" with a negative offset relative to the baseline, by enlarging the 'descent' value of that particular glyph, which adds vertical space _below_ the line. > I want to display large text centered vertically. > But there is a blank area over the large text. Does the below do what you want? If not, perhaps I don't understand what you mean by "centered". (insert "A" (propertize "X" 'display '((raise -0.2) (height 2)))) > I expect line-pixel-height of a line with 5 times larger text > is 5 times larger than a normal line. > > Practically, if the large text is 'raise'd negative, > line-pixel-height is 5 times plus 'raise'd pixels larger. > (with some computational error) See above: I hope now it's clear why what you see in practice is how the code is supposed to work. IOW, the overall height of the screen line is enlarged to account for the 'raise' value _after_ enlarging the font due to 'height', because 'raise' works in font height units. > By the way, if the baseline height is same, > I think consecutive underlines should be displayed as one straight line. > The form below shows three underlines with different height. That's a separate bug (which you already reported). It happens when we redraw only the larger underlined glyph(s), without the smaller one(s) to its left. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 01:01:25 2017 Received: (at 25824) by debbugs.gnu.org; 24 Feb 2017 06:01:25 +0000 Received: from localhost ([127.0.0.1]:53453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ch8wX-0005KI-9W for submit@debbugs.gnu.org; Fri, 24 Feb 2017 01:01:25 -0500 Received: from mail-pg0-f52.google.com ([74.125.83.52]:33290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ch8wV-0005K6-WA for 25824@debbugs.gnu.org; Fri, 24 Feb 2017 01:01:24 -0500 Received: by mail-pg0-f52.google.com with SMTP id z128so7074070pgb.0 for <25824@debbugs.gnu.org>; Thu, 23 Feb 2017 22:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:mime-version; bh=YUEKHj8nu3E0Dlsix6c+GQWzoslej/EZab0io36WU58=; b=BGNKQqrOIoQQBNHXPexnqwlMdai8sJBL7TeZWqynNOOIX+0VruMAJpf3TPFWRnKwNY wgeo2Fx0o2sTUbyCpjteFM5qOV791X8aXOVWB0yNl1iJ1bKCYBJtowJ4XWQ2ewgMo9rX jETdErVtxYhP7sD8FZLckCr7+NGI96n6OWS1ohEJl1r5QQiPoRq5SrY8cUxMrxW9rG/G bNaYJpjcFA9pA2z4pgEb/+yA6kGTQQu64EwbkojqbvN7Wn/6B45tphz8Q0phtwgsjE3E dJwcNNlOQaPZ7wp6Sju4nbNG2FubI+uBLLclTFKzXXavnFzdsye6FjwX4uJd+ShrgW2c GDVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :mime-version; bh=YUEKHj8nu3E0Dlsix6c+GQWzoslej/EZab0io36WU58=; b=biFQ/pmPJoIWiWCeTnOcChQfOdyqZVHTwAAkxA4KvCD2qX3YnIOfZ/YMAkJ09SCS97 UsGYQLa0JfBKPJnKp76l1wWWEgCzNzt8eHXT2mp9Zm3URsYZObrE9ZGb2gYORw84tlrk i+aLMogQuSHoya0joa04mbjW0cvrzBGNBBgIEl7fRBk70CDyy3/JCtm7GlqISn0+Mf6w 90AYUh/TeP2VLSxuCgroz6G0jJhPeWaFuzHNerD/Eqw1xsyc4shRoZR6OnQNO+7un8I1 +5nhfJ7Lp4vzToVsq6Dx/9FcMG7pVs+v6X5WD+LFrtqOqrR/eTJxm1Ui6L9JWOSzksR1 FgYA== X-Gm-Message-State: AMke39l/QI4JvSM5ntRWH8S0+Py/rEI9vdG/LKrYXZoH8BCgu3h6/SjMgKD75uXdtOGfnA== X-Received: by 10.98.149.80 with SMTP id p77mr608791pfd.56.1487916078235; Thu, 23 Feb 2017 22:01:18 -0800 (PST) Received: from PNUT-PC (east24-p58.eaccess.hi-ho.ne.jp. [218.42.167.59]) by smtp.gmail.com with ESMTPSA id a1sm12864885pgn.51.2017.02.23.22.01.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 23 Feb 2017 22:01:17 -0800 (PST) From: ynyaaa@gmail.com To: Eli Zaretskii Subject: Re: bug#25824: 25.1; bugs about display specfications In-Reply-To: <834lzkucq5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Feb 2017 17:51:46 +0200") Date: Fri, 24 Feb 2017 15:01:19 +0900 Message-ID: <87bmtsnn4g.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25824 Cc: 25824@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: > Only if the replacement comes from a before- or after-string (in which > case the text won't be replaced, so you will have to hide it with some > invisible property). Put the 'raise' display property on the overlay > string, and you will have what you want. Overlays are not editable with kill and yank, so text properties are better. > What the display engine does is reserve space above > the baseline that is large enough for the enlarged font, and then draw > the "X" with a negative offset relative to the baseline, by enlarging > the 'descent' value of that particular glyph, which adds vertical > space _below_ the line. I wonder why the display engine does not take 'rase' into account when reserving space above the baseline. > Does the below do what you want? If not, perhaps I don't understand > what you mean by "centered". > > (insert "A" (propertize "X" 'display '((raise -0.2) (height 2)))) It is enough for only one line. With blank areas, emacs can display fewer lines. For example in my environment, the form below displays 9 lines. (insert (propertize "1\n2\n3\n4\n5\n6\n7\n8\n9\n" 'display '(height 5))) And the form below displays 7 lines. (insert (propertize "1\n2\n3\n4\n5\n6\n7\n8\n9\n" 'display '((raise -1.3) (height 5)))) From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 03:23:52 2017 Received: (at 25824) by debbugs.gnu.org; 24 Feb 2017 08:23:52 +0000 Received: from localhost ([127.0.0.1]:53511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chBAO-0000KV-1w for submit@debbugs.gnu.org; Fri, 24 Feb 2017 03:23:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chBAM-0000KJ-NT for 25824@debbugs.gnu.org; Fri, 24 Feb 2017 03:23:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chBAD-0006rY-N5 for 25824@debbugs.gnu.org; Fri, 24 Feb 2017 03:23:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chBAD-0006rT-Jz; Fri, 24 Feb 2017 03:23:41 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1244 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1chBAC-0001oq-PN; Fri, 24 Feb 2017 03:23:41 -0500 Date: Fri, 24 Feb 2017 10:23:13 +0200 Message-Id: <83tw7kro9a.fsf@gnu.org> From: Eli Zaretskii To: ynyaaa@gmail.com In-reply-to: <87bmtsnn4g.fsf@gmail.com> (ynyaaa@gmail.com) Subject: Re: bug#25824: 25.1; bugs about display specfications References: <87bmtsnn4g.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 25824 Cc: 25824@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: ynyaaa@gmail.com > Cc: 25824@debbugs.gnu.org > Date: Fri, 24 Feb 2017 15:01:19 +0900 > > Eli Zaretskii writes: > > Only if the replacement comes from a before- or after-string (in which > > case the text won't be replaced, so you will have to hide it with some > > invisible property). Put the 'raise' display property on the overlay > > string, and you will have what you want. > > Overlays are not editable with kill and yank, > so text properties are better. Then I'm afraid you are out of luck, because Emacs doesn't support recursive 'display' properties, i.e. a 'display' property that is a string which has another 'display' property for (a part of) that string. > > What the display engine does is reserve space above > > the baseline that is large enough for the enlarged font, and then draw > > the "X" with a negative offset relative to the baseline, by enlarging > > the 'descent' value of that particular glyph, which adds vertical > > space _below_ the line. > > I wonder why the display engine does not take 'rase' into account > when reserving space above the baseline. AFAIU, it's just a side effect of the implementation: 'raise' is implemented as modifications of the ascent or descent, so it behaves like these attributes of any glyph would. > > Does the below do what you want? If not, perhaps I don't understand > > what you mean by "centered". > > > > (insert "A" (propertize "X" 'display '((raise -0.2) (height 2)))) > > It is enough for only one line. > With blank areas, emacs can display fewer lines. Yes, there are limitations of what can be done in Emacs as far as text layout is concerned. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 11:00:36 2017 Received: (at 25824-done) by debbugs.gnu.org; 4 Mar 2017 16:00:36 +0000 Received: from localhost ([127.0.0.1]:40178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckC6m-0008F4-Ac for submit@debbugs.gnu.org; Sat, 04 Mar 2017 11:00:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckC6l-0008Es-2r for 25824-done@debbugs.gnu.org; Sat, 04 Mar 2017 11:00:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckC6c-0000hH-Lo for 25824-done@debbugs.gnu.org; Sat, 04 Mar 2017 11:00:29 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckC6c-0000hD-Hv; Sat, 04 Mar 2017 11:00:26 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ckC6b-0001f5-QO; Sat, 04 Mar 2017 11:00:26 -0500 Date: Sat, 04 Mar 2017 18:00:13 +0200 Message-Id: <83mvd1jalu.fsf@gnu.org> From: Eli Zaretskii To: ynyaaa@gmail.com In-reply-to: <83tw7kro9a.fsf@gnu.org> (message from Eli Zaretskii on Fri, 24 Feb 2017 10:23:13 +0200) Subject: Re: bug#25824: 25.1; bugs about display specfications References: <87bmtsnn4g.fsf@gmail.com> <83tw7kro9a.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 25824-done Cc: 25824-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Fri, 24 Feb 2017 10:23:13 +0200 > From: Eli Zaretskii > Cc: 25824@debbugs.gnu.org > > > From: ynyaaa@gmail.com > > Cc: 25824@debbugs.gnu.org > > Date: Fri, 24 Feb 2017 15:01:19 +0900 > > > > Eli Zaretskii writes: > > > Only if the replacement comes from a before- or after-string (in which > > > case the text won't be replaced, so you will have to hide it with some > > > invisible property). Put the 'raise' display property on the overlay > > > string, and you will have what you want. > > > > Overlays are not editable with kill and yank, > > so text properties are better. > > Then I'm afraid you are out of luck, because Emacs doesn't support > recursive 'display' properties, i.e. a 'display' property that is a > string which has another 'display' property for (a part of) that > string. > > > > What the display engine does is reserve space above > > > the baseline that is large enough for the enlarged font, and then draw > > > the "X" with a negative offset relative to the baseline, by enlarging > > > the 'descent' value of that particular glyph, which adds vertical > > > space _below_ the line. > > > > I wonder why the display engine does not take 'rase' into account > > when reserving space above the baseline. > > AFAIU, it's just a side effect of the implementation: 'raise' is > implemented as modifications of the ascent or descent, so it behaves > like these attributes of any glyph would. > > > > Does the below do what you want? If not, perhaps I don't understand > > > what you mean by "centered". > > > > > > (insert "A" (propertize "X" 'display '((raise -0.2) (height 2)))) > > > > It is enough for only one line. > > With blank areas, emacs can display fewer lines. > > Yes, there are limitations of what can be done in Emacs as far as text > layout is concerned. I've now clarified the relations between 'raise' and 'height' in the ELisp manual, and I'm closing this bug. Thanks. From unknown Sun Jun 22 22:45:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 02 Apr 2017 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator