GNU bug report logs - #25824
25.1; bugs about display specfications

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 25824 <at> debbugs.gnu.org
Subject: bug#25824: 25.1; bugs about display specfications
Date: Thu, 23 Feb 2017 17:51:46 +0200

> From: ynyaaa <at> gmail.com
> Cc: 25824 <at> debbugs.gnu.org
> Date: Thu, 23 Feb 2017 11:53:16 +0900
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.