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

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 15138 in the body.
You can then email your comments to 15138 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Toomim <toomim <at> cs.washington.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: Font rendering error on OSX
Date: Mon, 19 Aug 2013 19:37:28 -0700

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

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.

[Message part 2 (text/html, inline)]

[PastedGraphic-21.png (image/png, inline)]

[PastedGraphic-19.png (image/png, inline)]

[PastedGraphic-20.png (image/png, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Toomim <toomim <at> cs.washington.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: Font rendering error on OSX
Date: Mon, 19 Aug 2013 19:44:22 -0700

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.

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>

Message #11 received at 15138 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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>
> 
> 
> 

Message #14 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Michael Toomim <toomim <at> cs.washington.edu>
Cc: "15138 <at> debbugs.gnu.org" <15138 <at> debbugs.gnu.org>
Subject: Re: bug#15138: Font selection error on OSX
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 <jan.h.d <at> swipnet.se>:

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

Message #17 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Michael Toomim <toomim <at> cs.washington.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "15138 <at> debbugs.gnu.org" <15138 <at> debbugs.gnu.org>
Subject: Re: bug#15138: Font selection error on OSX
Date: Tue, 27 Aug 2013 12:08:29 -0700

That sounds very strange indeed!  Thank you very much for investigating this.  Where in the source are you looking?

On Aug 27, 2013, at 8:59 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> 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 <at> swipnet.se>:
> 
>> 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>
>> 

Message #20 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Michael Toomim <toomim <at> cs.washington.edu>
Cc: "15138 <at> debbugs.gnu.org" <15138 <at> debbugs.gnu.org>
Subject: Re: bug#15138: Font selection error on OSX
Date: Wed, 28 Aug 2013 06:55:01 +0200

Hi.

27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim <at> cs.washington.edu>:

> That sounds very strange indeed!  Thank you very much for investigating this.  Where in the source are you looking?
> 

Just tracing calls and parameters to functions in nsfont_driver in nsfont.m.

	Jan D.

> On Aug 27, 2013, at 8:59 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> 
>> 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 <at> swipnet.se>:
>> 
>>> 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>
>>> 

Message #23 received at 15138 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#15138: Font selection error on OSX
Date: Sun, 1 Sep 2013 12:00:56 +0200

Hello.

I've made a fix for this in the trunk, please try it.

Thanks,

	Jan D.

28 aug 2013 kl. 06:55 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

> Hi.
> 
> 27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim <at> cs.washington.edu>:
> 
>> That sounds very strange indeed!  Thank you very much for investigating this.  Where in the source are you looking?
>> 
> 
> Just tracing calls and parameters to functions in nsfont_driver in nsfont.m.
> 
> 	Jan D.
> 
>> On Aug 27, 2013, at 8:59 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>> 
>>> 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 <at> swipnet.se>:
>>> 
>>>> 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>
>>>> 
> 

Message #26 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Michael Toomim <toomim <at> cs.washington.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Sun, 1 Sep 2013 11:51:34 -0700

Fantastic!  I will try it out and let you know.

On Sep 1, 2013, at 3:00 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Hello.
> 
> I've made a fix for this in the trunk, please try it.
> 
> Thanks,
> 
> 	Jan D.
> 
> 28 aug 2013 kl. 06:55 skrev Jan Djärv <jan.h.d <at> swipnet.se>:
> 
>> Hi.
>> 
>> 27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim <at> cs.washington.edu>:
>> 
>>> That sounds very strange indeed!  Thank you very much for investigating this.  Where in the source are you looking?
>>> 
>> 
>> Just tracing calls and parameters to functions in nsfont_driver in nsfont.m.
>> 
>> 	Jan D.
>> 
>>> On Aug 27, 2013, at 8:59 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>> 
>>>> 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 <at> swipnet.se>:
>>>> 
>>>>> 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>
>>>>> 
>> 
> 

Message #29 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Mon, 02 Sep 2013 23:50:10 +0900

In article <B1058569-FA76-4B76-84DF-46A38916008F <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:

> I've made a fix for this in the trunk, please try it.

Do you mean this change?

	* fontset.c (face_for_char): Check char in the current face font first
	if HAVE_NS (Bug#15138).

I agree that this change improves font selection for
symbols, but it's not good for many scripts for which just
having a glyph is not enough.  For instance, if the default
font has Hindi glyphs but doesn't have the OTF features for
Hindi script, we must find another proper font for Hindi.

How about modifying the current fontset mechanism as this?

(1) Allow t for FONT-SPEC of set-fontset-font to tell that
    the default font should be tried.
(2) Modiyf the default fontset to include `t' as the
    font-spec for scripts/characters for which the default
    font is ok.

---
Kenichi Handa
handa <at> gnu.org

Message #32 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Kenichi Handa <handa <at> gnu.org>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Mon, 2 Sep 2013 17:57:14 +0200

Hello.

2 sep 2013 kl. 16:50 skrev Kenichi Handa <handa <at> gnu.org>:

> In article <B1058569-FA76-4B76-84DF-46A38916008F <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> I've made a fix for this in the trunk, please try it.
> 
> Do you mean this change?
> 
> 	* fontset.c (face_for_char): Check char in the current face font first
> 	if HAVE_NS (Bug#15138).
> 
> I agree that this change improves font selection for
> symbols, but it's not good for many scripts for which just
> having a glyph is not enough.  For instance, if the default
> font has Hindi glyphs but doesn't have the OTF features for
> Hindi script, we must find another proper font for Hindi.
> 
> How about modifying the current fontset mechanism as this?
> 
> (1) Allow t for FONT-SPEC of set-fontset-font to tell that
>    the default font should be tried.
> (2) Modiyf the default fontset to include `t' as the
>    font-spec for scripts/characters for which the default
>    font is ok.


libotf is genrelly not available on OSX, and probably not working with GNUStep either (unless they use it at a lower level).  So the OTF case is not relevant to HAVE_NS anyway.

For OSX the way to go is to use Core text for this.  I think GNUStep is looking at implementing Core text to replace their old display postscript implementation.  So this is basically a temporary fix.  Anyway, if you prefer OTF for some script, why not mark those scripts with "prefer-otf" and check if any otf-features are available?  HAVE_NS will not have any OTF features.

	Jan D.

Message #35 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Darren Hoo <darren.hoo <at> gmail.com>
To: 15138 <at> debbugs.gnu.org
Subject: revno: 114089 change causes cjk characters not shown correctly
Date: Tue, 3 Sep 2013 01:29:54 +0800

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

it causes wrong font selection, if revert this change, it shows ok.

[chinese-character-not-shown.png (image/png, attachment)]

Message #38 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Michael Toomim <toomim <at> cs.washington.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Mon, 2 Sep 2013 11:34:33 -0700

I just tried it out; this solves my problems with "•" characters.  Thanks!

Message #43 received at 15138-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Michael Toomim <toomim <at> cs.washington.edu>
Cc: 15138-done <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Mon, 2 Sep 2013 21:13:51 +0200

Hi.

2 sep 2013 kl. 20:34 skrev Michael Toomim <toomim <at> cs.washington.edu>:

> I just tried it out; this solves my problems with "•" characters.  Thanks!

Ok, closing, thanks for testing.

	Jan D.

Message #46 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Darren Hoo <darren.hoo <at> gmail.com>
Cc: "15138 <at> debbugs.gnu.org" <15138 <at> debbugs.gnu.org>
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Tue, 3 Sep 2013 09:00:24 +0200

Hello. 

I've checked in a fix, please test it. 

Thanks,

     Jan D. 

2 sep 2013 kl. 19:29 skrev Darren Hoo <darren.hoo <at> gmail.com>:

> it causes wrong font selection, if revert this change, it shows ok.
> <chinese-character-not-shown.png>

Message #49 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Tue, 03 Sep 2013 21:10:10 +0900

In article <2ADB2AAF-31B8-4271-B4C4-6A26EDFB5858 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:

> libotf is genrelly not available on OSX, and probably not
> working with GNUStep either (unless they use it at a lower
> level).  So the OTF case is not relevant to HAVE_NS
> anyway.

Hindi is just an example.  CJK characters are another
example.  We should select a proper CJK font depending of
the current language environment.

> For OSX the way to go is to use Core text for this.  I
> think GNUStep is looking at implementing Core text to
> replace their old display postscript implementation.  So
> this is basically a temporary fix.  Anyway, if you prefer
> OTF for some script, why not mark those scripts with
> "prefer-otf" and check if any otf-features are available?

?? The default fontset alreay has such a specification.  For
devanagari script, for instance, Emacs tries to find an OTF
font which support "rphf" OTF Feature for "deva" script.

     (devanagari ,(font-spec :registry "iso10646-1" :otf '(deva nil (rphf)))
		 (nil . "iso10646.indian-1"))

---
Kenichi Handa
handa <at> gnu.org

Message #52 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Darren Hoo <darren.hoo <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "15138 <at> debbugs.gnu.org" <15138 <at> debbugs.gnu.org>
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Tue, 3 Sep 2013 22:37:36 +0800

Hello,

I've tried it and  fixed for me.

Thanks.

On Tue, Sep 3, 2013 at 3:00 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> Hello.
>
> I've checked in a fix, please test it.
>

Message #55 received at 15138-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Darren Hoo <darren.hoo <at> gmail.com>
Cc: 15138-done <at> debbugs.gnu.org
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Tue, 3 Sep 2013 17:18:21 +0200

Hi.

3 sep 2013 kl. 16:37 skrev Darren Hoo <darren.hoo <at> gmail.com>:

> Hello,
> 
> I've tried it and  fixed for me.

Good, closing.

	Jan D.

Message #58 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Kenichi Handa <handa <at> gnu.org>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Tue, 3 Sep 2013 17:26:31 +0200

Hello.

3 sep 2013 kl. 14:10 skrev Kenichi Handa <handa <at> gnu.org>:

> In article <2ADB2AAF-31B8-4271-B4C4-6A26EDFB5858 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> For OSX the way to go is to use Core text for this.  I
>> think GNUStep is looking at implementing Core text to
>> replace their old display postscript implementation.  So
>> this is basically a temporary fix.  Anyway, if you prefer
>> OTF for some script, why not mark those scripts with
>> "prefer-otf" and check if any otf-features are available?
> 
> ?? The default fontset alreay has such a specification.  For
> devanagari script, for instance, Emacs tries to find an OTF
> font which support "rphf" OTF Feature for "deva" script.
> 
>     (devanagari ,(font-spec :registry "iso10646-1" :otf '(deva nil (rphf)))
> 		 (nil . "iso10646.indian-1"))

That is nice.  But rphf is totally ignored for HAVE_NS, it accepts any font with devanagari.

	Jan D.

Message #61 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Thu, 05 Sep 2013 21:57:30 +0900

In article <313DC5C9-7B2D-48B1-AF49-10540DF126E1 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:

> That is nice.  But rphf is totally ignored for HAVE_NS, it accepts any font with devanagari.

It should not be ignored.  Instead, the underlying font
driver should return nil for a font spec requiring an OTF
feature if the driver doesn't support OTF.  Then the fontset
mechanism fallbacks to the default fontset which has non-OTF
font spec for Devanagari.

---
Kenichi Handa
handa <at> gnu.org

Message #64 received at 15138-done <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15138-done <at> debbugs.gnu.org, darren.hoo <at> gmail.com
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Thu, 05 Sep 2013 22:49:55 +0900

In article <7FEF1248-81A6-4E06-8F08-29A02CE72E00 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:

> Good, closing.

I have another question about this change.

      /* Fonts often have characters in other scripts, like symbol, even if they
         don't match script: symbol.  So check if the character is present
         in the current face first.  Only enable for NS for now, but should
         perhaps be general?  */
      Lisp_Object font_object;
      XSETFONT (font_object, face->font);
      if (font_has_char (f, font_object, c)) return face->id;

With it, face->font may vary depending on the preceding
character.  So if you have these lines:
  abc•
  あいう•
the two "•"s will be displayed by different fonts.  Isn't it
better to try the font selected for ASCII as this:

      XSETFONT (font_object, face->ascii_face->font);

---
Kenichi Handa
handa <at> gnu.org

Message #67 received at 15138-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Kenichi Handa <handa <at> gnu.org>
Cc: 15138-done <at> debbugs.gnu.org, darren.hoo <at> gmail.com
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Thu, 5 Sep 2013 18:34:19 +0200

Hello.

5 sep 2013 kl. 15:49 skrev Kenichi Handa <handa <at> gnu.org>:

> In article <7FEF1248-81A6-4E06-8F08-29A02CE72E00 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> Good, closing.
> 
> I have another question about this change.
> 
>      /* Fonts often have characters in other scripts, like symbol, even if they
>         don't match script: symbol.  So check if the character is present
>         in the current face first.  Only enable for NS for now, but should
>         perhaps be general?  */
>      Lisp_Object font_object;
>      XSETFONT (font_object, face->font);
>      if (font_has_char (f, font_object, c)) return face->id;
> 
> With it, face->font may vary depending on the preceding
> character.  So if you have these lines:
>  abc•
>  あいう•
> the two "•"s will be displayed by different fonts.  Isn't it
> better to try the font selected for ASCII as this:
> 
>      XSETFONT (font_object, face->ascii_face->font);


I don't know, I never had that situation.  I guess if the goal is to show same glyphs, ascii_face->font is a better choice.  But if it is to have a consistent look with the surrounding text, it it not.

Consider a buffer where only  あいう• is entered.  I would assume the current font would be a better choice in this case.

	Jan D.

Message #70 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Kenichi Handa <handa <at> gnu.org>
Cc: toomim <at> cs.washington.edu, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: Font selection error on OSX
Date: Thu, 5 Sep 2013 18:56:31 +0200

Hello.

5 sep 2013 kl. 14:57 skrev Kenichi Handa <handa <at> gnu.org>:

> In article <313DC5C9-7B2D-48B1-AF49-10540DF126E1 <at> swipnet.se>, Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> That is nice.  But rphf is totally ignored for HAVE_NS, it accepts any font with devanagari.
> 
> It should not be ignored.  Instead, the underlying font
> driver should return nil for a font spec requiring an OTF
> feature if the driver doesn't support OTF.  Then the fontset
> mechanism fallbacks to the default fontset which has non-OTF
> font spec for Devanagari.

I guess the original author didn't know that, and tried to do the best font selection possible.  I'll fix that shortly.

	Jan D.

Message #73 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Kenichi Handa <handa <at> gnu.org>, darren.hoo <at> gmail.com, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Thu, 05 Sep 2013 13:04:11 -0400

> I don't know, I never had that situation.  I guess if the goal is to show
> same glyphs, ascii_face->font is a better choice.  But if it is to
> have a consistent look with the surrounding text, it it not.
> Consider a buffer where only  あいう• is entered.  I would assume the
> current font would be a better choice in this case.

Seeking a "consistent look" is good, but I think doing it this way is
a hack (consider the case where you have •あいう instead).


        Stefan

Message #76 received at 15138 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Kenichi Handa <handa <at> gnu.org>, darren.hoo <at> gmail.com, 15138 <at> debbugs.gnu.org
Subject: Re: bug#15138: revno: 114089 change causes cjk characters not shown
 correctly
Date: Thu, 5 Sep 2013 19:25:09 +0200

Hello.

5 sep 2013 kl. 19:04 skrev Stefan Monnier <monnier <at> IRO.UMontreal.CA>:

>> I don't know, I never had that situation.  I guess if the goal is to show
>> same glyphs, ascii_face->font is a better choice.  But if it is to
>> have a consistent look with the surrounding text, it it not.
>> Consider a buffer where only  あいう• is entered.  I would assume the
>> current font would be a better choice in this case.
> 
> Seeking a "consistent look" is good, but I think doing it this way is
> a hack (consider the case where you have •あいう instead).
> 

One can always construct cases that favors one or the other approach.
Let possible bug reports sort this out, one can hope they are based on real usage and not thought out examples.

	Jan D.

Previous Next

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