GNU bug report logs - #15138
Font rendering error on OSX

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Michael Toomim <toomim <at> cs.washington.edu>
Cc: 15138 <at> debbugs.gnu.org
Subject: bug#15138: Font rendering error on OSX
Date: Mon, 26 Aug 2013 18:14:47 +0200

Hello.

20 aug 2013 kl. 04:44 skrev Michael Toomim <toomim <at> cs.washington.edu>:

> A simple way to reproduce this bug is to press option-8 (inserts a bullet on a mac) anywhere in a text buffer. You can see the line grow taller.
> 
> In default OSX settings, you'll need to (setq ns-alternate-modifier 'none) before you can use option-8.
> 

It is strictly not a font rendering error, but a font selection error.  The bullet is from a different font than the surrounding text.

	Jan D.

> On Aug 19, 2013, at 7:37 PM, Michael Toomim <toomim <at> gmail.com> wrote:
> 
>> Some extended characters are rendered incorrectly in the new Cocoa 24.3 emacs on OSX. They are rendered:
>>   - too small
>>   - too tall (forcing an increase in line-height of a pixel or two)
>> 
>> The result is that some lines are too tall, and monospace layouts (like ASCII art) lose alignment.
>> 
>> Here is an example in three screenshots, where the "•" bullet character is rendered incorrectly. The first screenshot shows the bug on the current release. You can see that the center line takes up too much vertical space, and not enough horizontal space. This is a monospace font (apple monaco).
>> 
>> The second and third show the correct rendering. The second is an older emacs build I have that rendered text with Carbon. The third is Apple's native TextEdit.app, for reference.
>> 
>> 
>> <PastedGraphic-21.png>
>> <PastedGraphic-19.png>
>> <PastedGraphic-20.png>
> 
> 
> 

Previous Next

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