all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#8651: `raise' properties on NextStep
@ 2011-05-10 18:14 Alp Aker
  2011-05-11 13:08 ` Eli Zaretskii
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Alp Aker @ 2011-05-10 18:14 UTC (permalink / raw)
  To: 8651

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.






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8651: `raise' properties on NextStep
  2011-05-10 18:14 bug#8651: `raise' properties on NextStep Alp Aker
@ 2011-05-11 13:08 ` Eli Zaretskii
  2011-05-11 21:55   ` Alp Aker
  2011-05-11 14:44 ` Stefan Monnier
  2011-06-22 18:21 ` Alp Aker
  2 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2011-05-11 13:08 UTC (permalink / raw)
  To: Alp Aker; +Cc: 8651

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8651: `raise' properties on NextStep
  2011-05-10 18:14 bug#8651: `raise' properties on NextStep Alp Aker
  2011-05-11 13:08 ` Eli Zaretskii
@ 2011-05-11 14:44 ` Stefan Monnier
  2011-06-22 18:21 ` Alp Aker
  2 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2011-05-11 14:44 UTC (permalink / raw)
  To: Alp Aker; +Cc: 8651

> 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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8651: `raise' properties on NextStep
  2011-05-11 13:08 ` Eli Zaretskii
@ 2011-05-11 21:55   ` Alp Aker
  0 siblings, 0 replies; 6+ messages in thread
From: Alp Aker @ 2011-05-11 21:55 UTC (permalink / raw)
  To: bug-gnu-emacs

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8651: `raise' properties on NextStep
  2011-05-10 18:14 bug#8651: `raise' properties on NextStep Alp Aker
  2011-05-11 13:08 ` Eli Zaretskii
  2011-05-11 14:44 ` Stefan Monnier
@ 2011-06-22 18:21 ` Alp Aker
  2011-06-25 13:03   ` Stefan Monnier
  2 siblings, 1 reply; 6+ messages in thread
From: Alp Aker @ 2011-06-22 18:21 UTC (permalink / raw)
  To: 8651, monnier, eliz

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#8651: `raise' properties on NextStep
  2011-06-22 18:21 ` Alp Aker
@ 2011-06-25 13:03   ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2011-06-25 13:03 UTC (permalink / raw)
  To: Alp Aker; +Cc: 8651, Adrian Robert

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-06-25 13:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-10 18:14 bug#8651: `raise' properties on NextStep Alp Aker
2011-05-11 13:08 ` Eli Zaretskii
2011-05-11 21:55   ` Alp Aker
2011-05-11 14:44 ` Stefan Monnier
2011-06-22 18:21 ` Alp Aker
2011-06-25 13:03   ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.