bug#15138: Font selection error on OSX

[Jan Djärv]

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 <jan.h.d@swipnet.se>:

> Hello.
> 
> 20 aug 2013 kl. 04:44 skrev Michael Toomim <toomim@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@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>
>