bug#8651: `raise' properties on NextStep

bug#8651: `raise' properties on NextStep

[Alp Aker]

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.  Some hasty investigation appears to show that the
problem is actually in the implementation of the glyph-drawing
routines for NextStep.

Make the following change to the trunk:

=== modified file 'src/nsfont.m'
--- src/nsfont.m	2011-04-16 03:14:08 +0000
+++ src/nsfont.m	2011-05-10 17:13:25 +0000
@@ -1273,6 +1273,8 @@
     else
       [col set];
 
+    r.origin.y = s->ybase;
+
     CGContextSetTextPosition (gcontext, r.origin.x, r.origin.y);
     CGContextShowGlyphsWithAdvances (gcontext, s->char2b + s->cmp_from,
                                     advances, len);

and build with `./configure --with-ns'.  The result is an
executable in which `raise' properties have the documented
behavior.

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.  

As far as I can see, the problem is this (please correct me if
I've misunderstood the display routine, which is
likely).  Changes in vertical character position that result from
display properties are processed in xdisp.c, and those changes
are reflected in the value of the ybase field.  But 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.

bug#8651: `raise' properties on NextStep

[Eli Zaretskii]

> 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.

bug#8651: `raise' properties on NextStep

[Alp Aker]

> 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.

Well, you did say "Maybe it's a bug in NextStep, then" :)  

But sorry to have misinterpreted you.  In any case, I just wanted to
make sure the bug was in the database.

bug#8651: `raise' properties on NextStep

[Stefan Monnier]

> As far as I can see, the problem is this (please correct me if
> I've misunderstood the display routine, which is
> likely).  Changes in vertical character position that result from
> display properties are processed in xdisp.c, and those changes
> are reflected in the value of the ybase field.  But 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.

Thanks for the bug report and diagnostic, which sounds just right.
Hopefully someone familiar with the NS code will find the time to write
an actual patch for it.


        Stefan

bug#8651: `raise' properties on NextStep

[Alp Aker]

Stefan Monnier writes:

> Thanks for the bug report and diagnostic, which sounds just right. 
> Hopefully someone familiar with the NS code will find the time to write 
> an actual patch for it.

I studied the NS code some and wrote up a patch.  I posted it in the 
thread for bug 8913, as that concerns the same issue and was opened 
yesterday.  (I'm noting the connection here to make sure this bug also 
gets closed if the patch is accepted.)

bug#8651: `raise' properties on NextStep

[Stefan Monnier]

forcemerge 8651 8913
thanks

>> Thanks for the bug report and diagnostic, which sounds just
>> right. Hopefully someone familiar with the NS code will find the time to
>> write an actual patch for it.
> I studied the NS code some and wrote up a patch.  I posted it in the thread
> for bug 8913, as that concerns the same issue and was opened yesterday.
> (I'm noting the connection here to make sure this bug also gets closed if
> the patch is accepted.)

Thank you very much, could some NS guy confirm it's right and install it?


        Stefan