From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25824: 25.1; bugs about display specfications Date: Thu, 23 Feb 2017 17:51:46 +0200 Message-ID: <834lzkucq5.fsf@gnu.org> References: <87poicrxc9.fsf@gmail.com> <83h93no365.fsf@gnu.org> <87y3wxfwir.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1487865200 2729 195.159.176.226 (23 Feb 2017 15:53:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Feb 2017 15:53:20 +0000 (UTC) Cc: 25824@debbugs.gnu.org To: ynyaaa@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 23 16:53:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgvhd-00085u-6r for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Feb 2017 16:53:09 +0100 Original-Received: from localhost ([::1]:59456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgvhi-00013y-Uo for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Feb 2017 10:53:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgvha-00013i-9c for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2017 10:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgvhX-0004gU-8C for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2017 10:53:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54952) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cgvhX-0004gQ-3X for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2017 10:53:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cgvhW-0002ov-DO for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2017 10:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2017 15:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25824 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25824-submit@debbugs.gnu.org id=B25824.148786514710795 (code B ref 25824); Thu, 23 Feb 2017 15:53:02 +0000 Original-Received: (at 25824) by debbugs.gnu.org; 23 Feb 2017 15:52:27 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: <87y3wxfwir.fsf@gmail.com> (ynyaaa@gmail.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:129692 Archived-At: > 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.