GNU bug report logs - #8651
`raise' properties on NextStep

Previous Next

Full log

Message #8 received at 8651 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alp Aker <aker <at> pitt.edu>
Cc: 8651 <at> debbugs.gnu.org
Subject: Re: bug#8651: `raise' properties on NextStep
Date: Wed, 11 May 2011 09:08:39 -0400

> From: Alp Aker <aker <at> pitt.edu>
> 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.

Previous Next

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