Subject: bug#15138: Font selection error on OSX

From: Jan Djärv <[email-masked]>
Date: Tue, 27 Aug 2013 17:59:46 +0200

Hello. 

This seems to be in the general font code. It does not even try to check if that glyph is present in the current font (it is), but instead asks for a font with script symbol. The logic seems strange to me. 

     Jan D. 

26 aug 2013 kl. 18:14 skrev Jan Djärv <[email-masked]>:

> Hello.
> 
> 20 aug 2013 kl. 04:44 skrev Michael Toomim <[email-masked]>:
> 
>> 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 <[email-masked]> 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.
>>> 
>>> 
>