* bug#15138: Font rendering error on OSX
@ 2013-08-20 2:37 Michael Toomim
2013-08-20 2:44 ` Michael Toomim
2013-09-02 17:29 ` bug#15138: revno: 114089 change causes cjk characters not shown correctly Darren Hoo
0 siblings, 2 replies; 24+ messages in thread
From: Michael Toomim @ 2013-08-20 2:37 UTC (permalink / raw)
To: 15138
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
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.
[-- Attachment #2.1: Type: text/html, Size: 1635 bytes --]
[-- Attachment #2.2: PastedGraphic-21.png --]
[-- Type: image/png, Size: 31328 bytes --]
[-- Attachment #2.3: PastedGraphic-19.png --]
[-- Type: image/png, Size: 26433 bytes --]
[-- Attachment #2.4: PastedGraphic-20.png --]
[-- Type: image/png, Size: 24319 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font rendering error on OSX
2013-08-20 2:37 bug#15138: Font rendering error on OSX Michael Toomim
@ 2013-08-20 2:44 ` Michael Toomim
2013-08-26 16:14 ` Jan Djärv
2013-09-02 17:29 ` bug#15138: revno: 114089 change causes cjk characters not shown correctly Darren Hoo
1 sibling, 1 reply; 24+ messages in thread
From: Michael Toomim @ 2013-08-20 2:44 UTC (permalink / raw)
To: 15138
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@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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font rendering error on OSX
2013-08-20 2:44 ` Michael Toomim
@ 2013-08-26 16:14 ` Jan Djärv
2013-08-27 15:59 ` bug#15138: Font selection " Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-08-26 16:14 UTC (permalink / raw)
To: Michael Toomim; +Cc: 15138
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>
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-08-26 16:14 ` Jan Djärv
@ 2013-08-27 15:59 ` Jan Djärv
2013-08-27 19:08 ` Michael Toomim
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-08-27 15:59 UTC (permalink / raw)
To: Michael Toomim; +Cc: 15138@debbugs.gnu.org
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>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-08-27 15:59 ` bug#15138: Font selection " Jan Djärv
@ 2013-08-27 19:08 ` Michael Toomim
2013-08-28 4:55 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Michael Toomim @ 2013-08-27 19:08 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138@debbugs.gnu.org
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@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@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>
>>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-08-27 19:08 ` Michael Toomim
@ 2013-08-28 4:55 ` Jan Djärv
2013-09-01 10:00 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-08-28 4:55 UTC (permalink / raw)
To: Michael Toomim; +Cc: 15138@debbugs.gnu.org
Hi.
27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim@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@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@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>
>>>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-08-28 4:55 ` Jan Djärv
@ 2013-09-01 10:00 ` Jan Djärv
2013-09-01 18:51 ` Michael Toomim
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Jan Djärv @ 2013-09-01 10:00 UTC (permalink / raw)
To: Michael Toomim; +Cc: 15138
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@swipnet.se>:
> Hi.
>
> 27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim@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@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@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>
>>>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-01 10:00 ` Jan Djärv
@ 2013-09-01 18:51 ` Michael Toomim
2013-09-02 14:50 ` Kenichi Handa
2013-09-02 18:34 ` Michael Toomim
2 siblings, 0 replies; 24+ messages in thread
From: Michael Toomim @ 2013-09-01 18:51 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138
Fantastic! I will try it out and let you know.
On Sep 1, 2013, at 3:00 AM, Jan Djärv <jan.h.d@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@swipnet.se>:
>
>> Hi.
>>
>> 27 aug 2013 kl. 21:08 skrev Michael Toomim <toomim@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@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@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>
>>>>>
>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-01 10:00 ` Jan Djärv
2013-09-01 18:51 ` Michael Toomim
@ 2013-09-02 14:50 ` Kenichi Handa
2013-09-02 15:57 ` Jan Djärv
2013-09-02 18:34 ` Michael Toomim
2 siblings, 1 reply; 24+ messages in thread
From: Kenichi Handa @ 2013-09-02 14:50 UTC (permalink / raw)
To: Jan Djärv; +Cc: toomim, 15138
In article <B1058569-FA76-4B76-84DF-46A38916008F@swipnet.se>, Jan Djärv <jan.h.d@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@gnu.org
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-02 14:50 ` Kenichi Handa
@ 2013-09-02 15:57 ` Jan Djärv
2013-09-03 12:10 ` Kenichi Handa
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-09-02 15:57 UTC (permalink / raw)
To: Kenichi Handa; +Cc: toomim, 15138
Hello.
2 sep 2013 kl. 16:50 skrev Kenichi Handa <handa@gnu.org>:
> In article <B1058569-FA76-4B76-84DF-46A38916008F@swipnet.se>, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-08-20 2:37 bug#15138: Font rendering error on OSX Michael Toomim
2013-08-20 2:44 ` Michael Toomim
@ 2013-09-02 17:29 ` Darren Hoo
2013-09-03 7:00 ` Jan Djärv
1 sibling, 1 reply; 24+ messages in thread
From: Darren Hoo @ 2013-09-02 17:29 UTC (permalink / raw)
To: 15138
[-- Attachment #1: Type: text/plain, Size: 68 bytes --]
it causes wrong font selection, if revert this change, it shows ok.
[-- Attachment #2: chinese-character-not-shown.png --]
[-- Type: image/png, Size: 167609 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-01 10:00 ` Jan Djärv
2013-09-01 18:51 ` Michael Toomim
2013-09-02 14:50 ` Kenichi Handa
@ 2013-09-02 18:34 ` Michael Toomim
2013-09-02 19:13 ` Jan Djärv
2 siblings, 1 reply; 24+ messages in thread
From: Michael Toomim @ 2013-09-02 18:34 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138
I just tried it out; this solves my problems with "•" characters. Thanks!
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-02 18:34 ` Michael Toomim
@ 2013-09-02 19:13 ` Jan Djärv
0 siblings, 0 replies; 24+ messages in thread
From: Jan Djärv @ 2013-09-02 19:13 UTC (permalink / raw)
To: Michael Toomim; +Cc: 15138-done
Hi.
2 sep 2013 kl. 20:34 skrev Michael Toomim <toomim@cs.washington.edu>:
> I just tried it out; this solves my problems with "•" characters. Thanks!
Ok, closing, thanks for testing.
Jan D.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-02 17:29 ` bug#15138: revno: 114089 change causes cjk characters not shown correctly Darren Hoo
@ 2013-09-03 7:00 ` Jan Djärv
2013-09-03 14:37 ` Darren Hoo
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-09-03 7:00 UTC (permalink / raw)
To: Darren Hoo; +Cc: 15138@debbugs.gnu.org
Hello.
I've checked in a fix, please test it.
Thanks,
Jan D.
2 sep 2013 kl. 19:29 skrev Darren Hoo <darren.hoo@gmail.com>:
> it causes wrong font selection, if revert this change, it shows ok.
> <chinese-character-not-shown.png>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-02 15:57 ` Jan Djärv
@ 2013-09-03 12:10 ` Kenichi Handa
2013-09-03 15:26 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Kenichi Handa @ 2013-09-03 12:10 UTC (permalink / raw)
To: Jan Djärv; +Cc: toomim, 15138
In article <2ADB2AAF-31B8-4271-B4C4-6A26EDFB5858@swipnet.se>, Jan Djärv <jan.h.d@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@gnu.org
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-03 7:00 ` Jan Djärv
@ 2013-09-03 14:37 ` Darren Hoo
2013-09-03 15:18 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Darren Hoo @ 2013-09-03 14:37 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138@debbugs.gnu.org
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@swipnet.se> wrote:
> Hello.
>
> I've checked in a fix, please test it.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-03 14:37 ` Darren Hoo
@ 2013-09-03 15:18 ` Jan Djärv
2013-09-05 13:49 ` Kenichi Handa
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-09-03 15:18 UTC (permalink / raw)
To: Darren Hoo; +Cc: 15138-done
Hi.
3 sep 2013 kl. 16:37 skrev Darren Hoo <darren.hoo@gmail.com>:
> Hello,
>
> I've tried it and fixed for me.
Good, closing.
Jan D.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-03 12:10 ` Kenichi Handa
@ 2013-09-03 15:26 ` Jan Djärv
2013-09-05 12:57 ` Kenichi Handa
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-09-03 15:26 UTC (permalink / raw)
To: Kenichi Handa; +Cc: toomim, 15138
Hello.
3 sep 2013 kl. 14:10 skrev Kenichi Handa <handa@gnu.org>:
> In article <2ADB2AAF-31B8-4271-B4C4-6A26EDFB5858@swipnet.se>, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-03 15:26 ` Jan Djärv
@ 2013-09-05 12:57 ` Kenichi Handa
2013-09-05 16:56 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Kenichi Handa @ 2013-09-05 12:57 UTC (permalink / raw)
To: Jan Djärv; +Cc: toomim, 15138
In article <313DC5C9-7B2D-48B1-AF49-10540DF126E1@swipnet.se>, Jan Djärv <jan.h.d@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@gnu.org
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-03 15:18 ` Jan Djärv
@ 2013-09-05 13:49 ` Kenichi Handa
2013-09-05 16:34 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Kenichi Handa @ 2013-09-05 13:49 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138-done, darren.hoo
In article <7FEF1248-81A6-4E06-8F08-29A02CE72E00@swipnet.se>, Jan Djärv <jan.h.d@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@gnu.org
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-05 13:49 ` Kenichi Handa
@ 2013-09-05 16:34 ` Jan Djärv
2013-09-05 17:04 ` Stefan Monnier
0 siblings, 1 reply; 24+ messages in thread
From: Jan Djärv @ 2013-09-05 16:34 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 15138-done, darren.hoo
Hello.
5 sep 2013 kl. 15:49 skrev Kenichi Handa <handa@gnu.org>:
> In article <7FEF1248-81A6-4E06-8F08-29A02CE72E00@swipnet.se>, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: Font selection error on OSX
2013-09-05 12:57 ` Kenichi Handa
@ 2013-09-05 16:56 ` Jan Djärv
0 siblings, 0 replies; 24+ messages in thread
From: Jan Djärv @ 2013-09-05 16:56 UTC (permalink / raw)
To: Kenichi Handa; +Cc: toomim, 15138
Hello.
5 sep 2013 kl. 14:57 skrev Kenichi Handa <handa@gnu.org>:
> In article <313DC5C9-7B2D-48B1-AF49-10540DF126E1@swipnet.se>, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-05 16:34 ` Jan Djärv
@ 2013-09-05 17:04 ` Stefan Monnier
2013-09-05 17:25 ` Jan Djärv
0 siblings, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2013-09-05 17:04 UTC (permalink / raw)
To: Jan Djärv; +Cc: 15138, darren.hoo
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#15138: revno: 114089 change causes cjk characters not shown correctly
2013-09-05 17:04 ` Stefan Monnier
@ 2013-09-05 17:25 ` Jan Djärv
0 siblings, 0 replies; 24+ messages in thread
From: Jan Djärv @ 2013-09-05 17:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 15138, darren.hoo
Hello.
5 sep 2013 kl. 19:04 skrev Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2013-09-05 17:25 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-20 2:37 bug#15138: Font rendering error on OSX Michael Toomim
2013-08-20 2:44 ` Michael Toomim
2013-08-26 16:14 ` Jan Djärv
2013-08-27 15:59 ` bug#15138: Font selection " Jan Djärv
2013-08-27 19:08 ` Michael Toomim
2013-08-28 4:55 ` Jan Djärv
2013-09-01 10:00 ` Jan Djärv
2013-09-01 18:51 ` Michael Toomim
2013-09-02 14:50 ` Kenichi Handa
2013-09-02 15:57 ` Jan Djärv
2013-09-03 12:10 ` Kenichi Handa
2013-09-03 15:26 ` Jan Djärv
2013-09-05 12:57 ` Kenichi Handa
2013-09-05 16:56 ` Jan Djärv
2013-09-02 18:34 ` Michael Toomim
2013-09-02 19:13 ` Jan Djärv
2013-09-02 17:29 ` bug#15138: revno: 114089 change causes cjk characters not shown correctly Darren Hoo
2013-09-03 7:00 ` Jan Djärv
2013-09-03 14:37 ` Darren Hoo
2013-09-03 15:18 ` Jan Djärv
2013-09-05 13:49 ` Kenichi Handa
2013-09-05 16:34 ` Jan Djärv
2013-09-05 17:04 ` Stefan Monnier
2013-09-05 17:25 ` Jan Djärv
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).