GNU bug report logs - #2836
23.0.92; The bottom of my font (Monaco 10) is cut off on Mac OS X

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2836 in the body.
You can then email your comments to 2836 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.92; The bottom of my font (Monaco 10) is cut off on Mac OS X
Date: Tue, 31 Mar 2009 15:17:57 -0700

[Message part 1 (text/plain, inline)]

I'm using monaco 10 on my Mac:

(set-default-font
"-apple-monaco-medium-r-normal--10-90-72-72-m-90-mac-roman" t)

This pretest, unlike the last one, has less space between each line.
This is cutting off the bottom of the font. Certain characters, most
notably [, ], {, }, ( and ) don't show their bottom row. The screen also
looks more cluttered because of the closer proximity of the lines which
makes it harder to read (I realize that sounds a bit
princess-and-the-pea-ish of me).

-David


In GNU Emacs 23.0.92.1 (i386-apple-darwin9.6.0, NS apple-appkit-949.43)
 of 2009-03-31 on black.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  diff-auto-refine-mode: t
  dir-locals-mode: t
  auto-insert-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Searching subfile emacs-8...
Searching subfile emacs-2...
Searching subfile emacs-3...
Searching subfile emacs-4...
Searching subfile emacs-5...
Searching subfile emacs-6...
Searching subfile emacs-7...
Searching subfile emacs-8...
Mark saved where search started
Mark set

[signature.asc (application/pgp-signature, attachment)]

Message #12 received at 2836 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: 2836 <at> debbugs.gnu.org
Subject: Re: bug#2836: Acknowledgement (23.0.92; The bottom of my font
 (Monaco 10) is cut off on Mac OS X)
Date: Sat, 04 Apr 2009 01:02:05 -0700

I have more info about when this occurred. I make nightly builds of the 
emacs cvs tree (http://porkrind.org/emacs) and so I used them to do a 
binary search and found that this bug seems to have been introduced on 
2009-03-14. My builds happen at midnight and 2009-03-14 works and 
2009-03-15 (and later) do not work.

Hopefully this can help someone figure out where this bug came from.

-David

Message #17 received at 2836 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: 2836 <at> debbugs.gnu.org
Subject: Re: bug#2836: Acknowledgement (23.0.92; The bottom of my font
 (Monaco 10) is cut off on Mac OS X)
Date: Sat, 04 Apr 2009 02:09:57 -0700

[Message part 1 (text/plain, inline)]

Ok. I went ahead and tracked it down. The regression was a change to 
src/nsfont.m on 2009-03-14 by davidswelt:

> nsfont.m (nsfont_open): remove ns_expand_space, assume -0.5 i.e. no
> additional spacing, similar to Carbon port.

I've attached a patch that fixes the regression (the bottom line of the 
font being dropped). It puts back expand to 0.5 which seems to be the 
default pre-checkin.

A couple things in this piece of code look a little sketchy. The "shrink" 
variable, for instance, seems to be defined but never used anywhere. 
There's some commented out stuff that's unclear what it was meant for and 
no indication of why one might comment it in or otherwise make use of it.

-David

[font-fix-2009-04-04.patch (application/octet-stream, attachment)]

Message #22 received at 2836 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: 2836 <at> debbugs.gnu.org
Subject: Re: bug#2836
Date: Mon, 27 Apr 2009 17:08:24 -0400

First, I reproduce this only when the system and Emacs are set up to  
switch off antialiasing for a font as small as that.
With antialiasing on, the error doesn't occur.  (Can be reproduced  
with Emacs -Q, which seems to use special settings for antialiasing,  
or with
(setq ns-antialias-text nil)).

Reintroducing line spacing (which was removed for a reason) not only  
fixes this bug, but has global consequences.

So I don't think this is the right way to fix this bug.  I think we  
have to look at the code that draws the non-antialiased text.

For now, the workaround for this is

(set-frame-parameter nil 'line-spacing 2)
(or setting defaut-frame-alist accordingly).

Message #27 received at 2836 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Caldwell <david <at> porkrind.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2836 <at> debbugs.gnu.org
Subject: Re: bug#2836
Date: Thu, 16 Jul 2009 16:49:33 -0700

On 4/27/09 3:52 PM, David Reitter wrote:

>> Reintroducing line spacing (which was removed for a reason) not only
>> fixes this bug, but has global consequences.

I'm curious what the reasons are since it wasn't really explained in the
check-in comments. I've been running with my patch now for 3 months and
haven't seen any visual oddities. But perhaps my anti-aliasing settings
are masking what the original change was for...

>> So I don't think this is the right way to fix this bug.  I think we
>> have to look at the code that draws the non-antialiased text.
>>
>> For now, the workaround for this is
>>
>> (set-frame-parameter nil 'line-spacing 2)
>> (or setting defaut-frame-alist accordingly).

This does fix the descenders being chopped off, but ends up making the
block cursor not cover the whole glyph it's highlighting--it's really ugly.

Any idea if we'll get a real fix (or one our workarounds) into CVS
before emacs 23.1 is released?

-David

Message #32 received at 2836 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: David Caldwell <david <at> porkrind.org>
Cc: 2836 <at> debbugs.gnu.org
Subject: Re: bug#2836
Date: Fri, 17 Jul 2009 00:54:35 +0100

[Message part 1 (text/plain, inline)]

On Jul 17, 2009, at 12:49 AM, David Caldwell wrote:
> I'm curious what the reasons are since it wasn't really explained in  
> the
> check-in comments. I've been running with my patch now for 3 months  
> and
> haven't seen any visual oddities. But perhaps my anti-aliasing  
> settings
> are masking what the original change was for...

One reason was that markings in the fringe are oddly divided if line  
spacing is used, rather than continuous.  The other one was to use the  
standard line spacing on the system, and the same line spacing as in  
Emacs 22 (Carbon).

>>> For now, the workaround for this is
>>>
>>> (set-frame-parameter nil 'line-spacing 2)
>>> (or setting defaut-frame-alist accordingly).
>
> This does fix the descenders being chopped off, but ends up making the
> block cursor not cover the whole glyph it's highlighting--it's  
> really ugly.

That per se is a bug and should be changed.  It's probably easier to  
fix.

> Any idea if we'll get a real fix (or one our workarounds) into CVS
> before emacs 23.1 is released?

If someone provides one and it is considered safe, maybe yes.
But I wouldn't worry too much about the release, given the long list  
of NS specific bugs that the release will have anyways.

[smime.p7s (application/pkcs7-signature, attachment)]

Previous Next

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