bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8651: `raise' properties on NextStep


From: Eli Zaretskii
Subject: bug#8651: `raise' properties on NextStep
Date: Wed, 11 May 2011 09:08:39 -0400

> From: Alp Aker <address@hidden>
> Date: Tue, 10 May 2011 18:14:31 +0000 (UTC)
> 
> Yesterday it came up on a thread on the devel list that on
> NextStep the `raise' property increases line height but does
> nothing more; it doesn't alter the vertical positioning of
> characters.  The question then arose whether this was a bug on
> NextStep, since the implementation of display properties isn't
> OS-specific.

This is a misunderstanding.  I never said that the problem is outside
Emacs.  I said that it's probably in the NS-specific parts of Emacs.

Most of the work of handling the `raise' property is in
device-independent code in xdisp.c.  However, the terminal-specific
code should obey the computed metrics of the glyphs when it draws the
glyphs on the screen.  It looks like NS-specific display code doesn't,
while both xterm.c and w32term.c do, see
x_draw_glyph_string_foreground.

> The above change is naive, and will break other things (such as
> underline positioning), but it serves as a proof of concept that
> the issue is on Emacs's side.  

Of course, it's on the Emacs side!  Where else could it possibly be?
It would be silly to claim that NextStep as a system cannot draw
characters at pixel resolution.

> many of the
> gylph-drawing functions in nsterm.m and nsfont.m only check the y field
> to determine the vertical position of a glyph; they don't use ybase 
> at all.

Which constitutes an NS-specific bug in Emacs.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]