[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 <aker@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.