bug#3174: NS: greek glyph rendering incoherent

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Testing with a current build now shows that the greek letters (M-x  
view-hello-file) are rendered using "STHeiti" Light.  Perhaps the  
"light" is the problem.  The accented alpha is still missing.

Adrian  - can you take a look at this?

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3174



         character: λ (955, #o1673, #x3bb)
preferred charset: greek-iso8859-7
		   (Right-Hand Part of ISO/IEC 8859/7 (Latin/Greek): ISO-IR-126)
        code point: 0x6B
            syntax: w 	which means: word
          category:
		   .:Base, G:2-byte Greek, c:Chinese, g:Greek, h:Korean, j:Japanese
       buffer code: #xCE #xBB
         file code: ESC #x2C #x46 #x6B
		   (encoded by coding system iso-2022-7bit-unix)
           display: by this font (glyph code)
     nil:-apple-STHeiti-medium-normal-normal-Light-12-*-*-*-*-*- 
iso10646-1 (#x1B8)

Character code properties: customize what to show
   name: GREEK SMALL LETTER LAMDA
   old-name: GREEK SMALL LETTER LAMBDA
   general-category: Ll (Letter, Lowercase)

There are text properties here:
   charset              greek-iso8859-7

[back]


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[Adrian Robert]

On May 27, 2009, at 11:51 PM, David Reitter wrote:

> Testing with a current build now shows that the greek letters (M-x  
> view-hello-file) are rendered using "STHeiti" Light.  Perhaps the  
> "light" is the problem.  The accented alpha is still missing.
>
> Adrian  - can you take a look at this?

>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3174


I have a patch locally that changes font selection to be based on  
the :script and :lang properties the font backend requests (charset  
is harder -- I haven't figured out any way to access fonts by this  
information in Cocoa, but we can always create a lookup table).  It's  
not fully working yet though.

bug#3174: NS: greek glyph rendering incoherent

[Adrian Robert]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

I'm including a patch (*) here that redoes the font selection process  
in nsfont.m and removes some NS-specific code elsewhere.  Although  
it's a big change, I would say it is still under the bug-fix category  
because it causes the NS port to follow the others in this area, and  
it works a little better judging by the HELLO screen.  However it  
would be good to have some testing before checking it in.

Thai is much improved.

Greek, however, is still hosed, because emacs font backend core  
decides these characters should be rendered using script "symbol".  I  
don't know why, since it also knows about "greek", but it might be  
because many Greek letters are used in both unicode categories.

* Savannah is down now (in fact haven't been able to access for  
nearly a week), so I'm including the new nsfont.m, fontset.c (just  
one change to remove NS-specific code in fontset_from_font, and ns- 
win.el in full, together with ChangeLog.

--------------
	Changes to support :script/:lang/:otf in NS font driver.
	* nsfont.m (nsfont_escape_name, nsfont_unescape_name)
	(nsfont_get_family, nsfont_char_width): Rename to ns_ prefix to
	indicate not part of font driver interface, and change callers.
	(ns_get_family): Remove pointless null check.
	(nsfont_spec_to_traits, nsfont_fmember_to_entity): Replace with
	ns_spec_to_descriptor, ns_descriptor_to_entity.
	(nsfont_trait_distance, nsfont_make_fontset_for_font): Remove.
	(ns_attribute_value, ns_attribute_fvalue, ns_has_attribute)
	(ns_spec_to_descriptor, ns_descriptor_to_entity)
	(ns_charset_covers, ns_lang_to_script, ns_otf_to_script)
	(ns_get_req_script, ns_accumulate_script_ranges)
	(ns_script_to_charset, ns_get_covering_families, ns_findfonts):
	New functions.
	(nsfont_list, nsfont_match): Use ns_findfonts.
	(nsfont_open): Use font descriptor instead of traits.
	(nsfont_draw): Handle "automatic" (lookup-table) compositions.
	(dump_glyphstring): Rename to ns_dump_glyphstring.

	* term/ns-win.el (composition-function-table)
	(script-representative-chars): Don't alter.
--------------


[-- Attachment #2: nsfont_script_20090531.tbz --]
[-- Type: application/octet-stream, Size: 39601 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[Jason Rumney]

Adrian Robert wrote:
> Greek, however, is still hosed, because emacs font backend core 
> decides these characters should be rendered using script "symbol".  I 
> don't know why, since it also knows about "greek", but it might be 
> because many Greek letters are used in both unicode categories.

The default fontset contains this definition for greek (from 
lisp/international/fontset.el):

     (greek ,(font-spec :registry "iso10646-1" :script 'greek)
        (nil . "ISO8859-7"))

charset-script-alist contains a suspicious looking (greek-iso8859-7 . 
latin), but that still doesn't explain why greek characters would get 
assigned to the symbol script.

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 8309 bytes --]

On May 31, 2009, at 1:32 AM, Adrian Robert wrote:

> I'm including a patch (*) here that redoes the font selection  
> process in nsfont.m and removes some NS-specific code elsewhere.   
> Although it's a big change, I would say it is still under the bug- 
> fix category because it causes the NS port to follow the others in  
> this area, and it works a little better judging by the HELLO  
> screen.  However it would be good to have some testing before  
> checking it in.

With your patch, Emacs -Q crashes when doing M-x view-hello-file.

I've printed some probably relevant status info, see below.

- David



Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000080
0x0020d208 in ns_charset_covers (set1=0x0, set2=0x16982a0,  
pct=0.899999976) at nsfont.m:271
271                 if (*bytes1 == 0)  // *bytes1 & *bytes2 != *bytes2
(gdb) bt
#0  0x0020d208 in ns_charset_covers (set1=0x0, set2=0x16982a0,  
pct=0.899999976) at nsfont.m:271
#1  0x0020d953 in ns_get_covering_families (script=0x1676050,  
pct=0.899999976) at nsfont.m:427
#2  0x0020dae3 in ns_findfonts (font_spec=6320332, isMatch=0 '\000')  
at nsfont.m:476
#3  0x0020dddc in nsfont_list (frame=9293316, font_spec=6320332) at  
nsfont.m:591
#4  0x001802e1 in font_list_entities (frame=9293316, spec=23552020) at  
font.c:2823
#5  0x00181ecf in font_find_for_lface (f=0x8dce00, attrs=0x16737d0,  
spec=7235580, c=-1) at font.c:3374
#6  0x002111d0 in fontset_find_font (fontset=23711172, c=1047,  
face=0x1673790, id=15, fallback=0) at fontset.c:602
#7  0x0021163b in fontset_font (fontset=23735636, c=1047,  
face=0x1673790, id=15) at fontset.c:703
#8  0x00211cdf in face_for_char (f=0x8dce00, face=0x1673790, c=1047,  
pos=171, object=25165833) at fontset.c:921
#9  0x000291f4 in get_next_display_element (it=0xbfffd518) at xdisp.c: 
5954
#10 0x00042445 in display_line (it=0xbfffd518) at xdisp.c:16606
#11 0x0003bd2c in try_window (window=9292964, pos={charpos = 1,  
bytepos = 1}, check_margins=1) at xdisp.c:14057
#12 0x0003aa57 in redisplay_window (window=9292964, just_this_one_p=0)  
at xdisp.c:13680
#13 0x00036884 in redisplay_window_0 (window=9292964) at xdisp.c:12275
#14 0x00166146 in internal_condition_case_1 (bfun=0x36840  
<redisplay_window_0>, arg=9292964, handlers=4785701, hfun=0x36808  
<redisplay_window_error>) at eval.c:1560
#15 0x000367e6 in redisplay_windows (window=9292964) at xdisp.c:12254
#16 0x00035aa5 in redisplay_internal (preserve_echo_area=1) at xdisp.c: 
11830
#17 0x000361cf in redisplay_preserve_echo_area (from_where=2) at  
xdisp.c:12074
#18 0x0000eaf6 in sit_for (timeout=16, reading=0, do_display=2) at  
dispnew.c:6616
#19 0x000da64e in Fexecute_extended_command (prefixarg=25165833) at  
keyboard.c:10577
#20 0x00168b96 in Ffuncall (nargs=2, args=0xbfffe8b0) at eval.c:3045
#21 0x001634da in Fcall_interactively (function=25201761,  
record_flag=25165833, keys=6299772) at callint.c:868
#22 0x00168bf0 in Ffuncall (nargs=4, args=0xbfffebb0) at eval.c:3051
#23 0x001686ac in call3 (fn=25280129, arg1=25201761, arg2=25165833,  
arg3=25165833) at eval.c:2875
#24 0x000da134 in Fcommand_execute (cmd=25201761,  
record_flag=25165833, keys=25165833, special=25165833) at keyboard.c: 
10447
#25 0x000c9549 in command_loop_1 () at keyboard.c:1901
#26 0x00165fd8 in internal_condition_case (bfun=0xc778a  
<command_loop_1>, handlers=25205425, hfun=0xc6e93 <cmd_error>) at  
eval.c:1512
#27 0x000c73ba in command_loop_2 () at keyboard.c:1359
#28 0x00165969 in internal_catch (tag=25201545, func=0xc7385  
<command_loop_2>, arg=25165833) at eval.c:1248
#29 0x000c7343 in command_loop () at keyboard.c:1338
#30 0x000c6917 in recursive_edit_1 () at keyboard.c:953
#31 0x000c6b20 in Frecursive_edit () at keyboard.c:1015
#32 0x000c4e25 in main (argc=2, argv=0xbffff1bc) at emacs.c:1852
Current language:  auto; currently objective-c
(gdb) print bytes1
$1 = (const short unsigned int *) 0x80

(gdb) bt full
#0  0x0020d208 in ns_charset_covers (set1=0x0, set2=0x16982a0,  
pct=0.899999976) at nsfont.m:271
         bytes1 = (const short unsigned int *) 0x80
         bytes2 = (const short unsigned int *) 0x2408ea0
         i = 64
         off = 0
         tot = 1
#1  0x0020d953 in ns_get_covering_families (script=0x1676050,  
pct=0.899999976) at nsfont.m:427
         fset = (NSCharacterSet *) 0x0
         allFamiliesEnum = (NSEnumerator *) 0x1674950
         charset = (NSCharacterSet *) 0x16982a0
         family = (NSString *) 0x8f6f40
         fontMgr = (NSFontManager *) 0x8df6a0
         allFamilies = (NSArray *) 0x2059800
         scriptToFamilies = (NSMutableDictionary *) 0x8df3f0
         families = (NSMutableSet *) 0x16748d0
#2  0x0020dae3 in ns_findfonts (font_spec=6320332, isMatch=0 '\000')  
at nsfont.m:476
         tem = 25366633
         list = 25165833
         fdesc = (NSFontDescriptor *) 0x0
         desc = (NSFontDescriptor *) 0x1
         fkeys = (NSMutableSet *) 0x16d65c
         matchingDescs = (NSArray *) 0xbfffcb48
         dEnum = (NSEnumerator *) 0x1800009
         family = (NSString *) 0x189b67b
         cFamilies = (NSSet *) 0x171381
         foundItal = 0 '\000'
#3  0x0020dddc in nsfont_list (frame=9293316, font_spec=6320332) at  
nsfont.m:591
No locals.
#4  0x001802e1 in font_list_entities (frame=9293316, spec=23552020) at  
font.c:2823
         copy = 6
         cache = 8211797
         f = (FRAME_PTR) 0x8dce00
         driver_list = (struct font_driver_list *) 0x8dcdd0
         ftype = 25165833
         val = 25165833
         vec = (Lisp_Object *) 0xbfffcb10
         size = 0
         need_filtering = 0
         i = 0
#5  0x00181ecf in font_find_for_lface (f=0x8dce00, attrs=0x16737d0,  
spec=7235580, c=-1) at font.c:3374
         work = 23552020
         frame = 9293316
         entities = 6291532
         val = 33840713
         props = {23674776, 23735632, 25165881, -1073754984, 2165913}
         size = 25165833
         foundry = {25369521, 25165833, 6291532}
         family = (Lisp_Object *) 0xbfffcbb0
         registry = {25366633, 6291532, 23674784}
         adstyle = {25165833, 6291532, 82904304}
         pixel_size = 12
         i = 0
         j = 0
         k = 0
         l = 0
         result = 7181484
#6  0x002111d0 in fontset_find_font (fontset=23711172, c=1047,  
face=0x1673790, id=15, fallback=0) at fontset.c:602
         rfont_def = 23551876
         font_def = 7147340
         font_entity = 25165833
         font_object = 25165833
         vec = 23674772
         font_group = 8191605
         i = 0
         charset_matched = -1
         f = (FRAME_PTR) 0x8dce00
#7  0x0021163b in fontset_font (fontset=23735636, c=1047,  
face=0x1673790, id=15) at fontset.c:703
         rfont_def = 25165833
         base_fontset = 23324980
#8  0x00211cdf in face_for_char (f=0x8dce00, face=0x1673790, c=1047,  
pos=171, object=25165833) at fontset.c:921
         fontset = 23735636
         rfont_def = 23747876
         charset = 25484649
         face_id = 15
         id = 15
#9  0x000291f4 in get_next_display_element (it=0xbfffd518) at xdisp.c: 
5954
         pos = 171
         face = (struct face *) 0x1673790
         success_p = 1
#

frame 9
(gdb) print *face
$5 = {
   id = 0,
   gc = 0x16a4c00,
   stipple = 0,
   foreground = 2,
   background = 1,
   underline_color = 0,
   overline_color = 0,
   strike_through_color = 0,
   box_color = 0,
   font = 0x163d640,
   fontset = 3,
   pixmap_w = 0,
   pixmap_h = 0,
   box_line_width = 0,
   box = FACE_NO_BOX,
   use_box_color_for_shadows_p = 0,
   underline_p = 0,
   overline_p = 0,
   strike_through_p = 0,
   foreground_defaulted_p = 0,
   background_defaulted_p = 0,
   underline_defaulted_p = 0,
   overline_color_defaulted_p = 0,
   strike_through_color_defaulted_p = 0,
   box_color_defaulted_p = 0,
   tty_bold_p = 0,
   tty_dim_p = 0,
   tty_underline_p = 0,
   tty_alt_charset_p = 0,
   tty_reverse_p = 0,
   tty_blinking_p = 0,
   colors_copied_bitwise_p = 0,
   overstrike = 0,
   synth_ital = 0,
   lface = {25166169, 25802363, 2377955, 25190409, 960, 25190409,  
25190409, 25165833, 25165833, 25863083, 25863035, 25165833, 25165833,  
25165833, 25165833, 23320132, 25165833, 25802235},
   hash = 25194329,
   next = 0x1674170,
   prev = 0x16a3910,
   ascii_face = 0x1673790,
   extra = 0x0
}



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[Adrian Robert]

On May 31, 2009, at 9:05 PM, David Reitter wrote:

> With your patch, Emacs -Q crashes when doing M-x view-hello-file.
> ...
> (gdb) bt
> #0  0x0020d208 in ns_charset_covers (set1=0x0, set2=0x16982a0,  
> pct=0.899999976) at nsfont.m:271

This is the problem (set1=0x0).  I only have access to Tiger here, so  
I'm not sure if it's something with Leopard, or specific to a font on  
your system, but [font coveredCharacterSet] must be returning nil.   
If you can go up one (ns_get_covering_families) and run 'print-object  
family' you can see what the offending family is.

I'm not sure what to do about this.  If it's only for some fonts I  
guess we can just assume they cover ASCII only.  If it is for every  
font on Leopard, then the whole approach will need to be reconsidered.

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On May 31, 2009, at 10:26 AM, Adrian Robert wrote:
> This is the problem (set1=0x0).  I only have access to Tiger here,  
> so I'm not sure if it's something with Leopard, or specific to a  
> font on your system, but [font coveredCharacterSet] must be  
> returning nil.  If you can go up one (ns_get_covering_families) and  
> run 'print-object family' you can see what the offending family is.

That gives me "Latin Modern Roman Slanted".  But:

(gdb) print-object families
{(
     Helvetica,
     Cochin,
     Code2000,
     Geneva,
     "Hoefler Text",
     "Arial Unicode MS"
)}

so that seems to indicate that it worked OK for 6 of them.

The missing charsets are:

2009-05-31 10:40:36.018 Emacs[81083:813] No charset for family: Latin  
Modern Roman Slanted
2009-05-31 10:40:36.411 Emacs[81083:813] No charset for family: Snell  
Roundhand

I've put in a condition to avoid adding the font if there is no charset.

Now we've got another crash:

(gdb) bt
#0  0x95d2a688 in objc_msgSend ()
#1  0x0020c76b in ns_attribute_value (fdesc=0xf355380,  
trait=0xa0248324) at nsfont.m:113
#2  0x0020dcc8 in ns_findfonts (font_spec=6320332, isMatch=0 '\0') at  
nsfont.m:507
#3  0x0020ddc5 in nsfont_list (frame=9293892, font_spec=6320332) at  
nsfont.m:596
#4  0x001802ad in font_list_entities (frame=9293892, spec=23718516) at  
font.c:2823
#5  0x00181e9b in font_find_for_lface (f=0x8dd040, attrs=0x1673a10,  
spec=7094524, c=-1) at font.c:3374
(gdb) frame 2
#2  0x0020dcc8 in ns_findfonts (font_spec=6320332, isMatch=0 '\000')  
at nsfont.m:507
507         if (family != nil && !foundItal && XINT (Flength (list)) > 0

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 944 bytes --]

On May 31, 2009, at 12:33 PM, Adrian Robert wrote:
> This one beats me as fdesc is used much before then.  However it  
> made me notice a typo just above: line 496 should be:
>
> 	if (ns_has_attribute (desc, NSFontSlantTrait))


OK, this helps.  No more crashes.
It can display more characters now, like the up-arrow in the  
screenshots I'm attaching.

However, it still uses the wrong fonts for symbols (and for greek) (- 
apple-MS_Mincho in my case).  I think that's what you pointed out  
earlier.

Following a posting here by Kenichi Handa here (and Jason's message in  
this thread):

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1399

I tried this:

(set-fontset-font
   "fontset-default"
   'symbol
   '("Lucida Grande" . "iso10646-1"))

This works great for Lucida, but I couldn't get Monaco or Courier New  
to work.

As has been pointed out the greek characters probably shouldn't be  
"symbol" in the first place.



[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 5630 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]



[-- Attachment #1.4: pastedGraphic.png --]
[-- Type: image/png, Size: 9573 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[Adrian Robert]

Should I check this in?  I believe it monotonically improves the  
situation from before from the user perspective, and it's definitely  
a step forward from the code perspective.  The Greek symbol problem  
is still there, but at least wasn't made worse.


On Jun 1, 2009, at 12:57 AM, David Reitter wrote:

> On May 31, 2009, at 12:33 PM, Adrian Robert wrote:
>> This one beats me as fdesc is used much before then.  However it  
>> made me notice a typo just above: line 496 should be:
>>
>> 	if (ns_has_attribute (desc, NSFontSlantTrait))
>
>
> OK, this helps.  No more crashes.
> It can display more characters now, like the up-arrow in the  
> screenshots I'm attaching.
>
> However, it still uses the wrong fonts for symbols (and for greek)  
> (-apple-MS_Mincho in my case).  I think that's what you pointed out  
> earlier.
>
> Following a posting here by Kenichi Handa here (and Jason's message  
> in this thread):
>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1399
>
> I tried this:
>
> (set-fontset-font
>   "fontset-default"
>   'symbol
>   '("Lucida Grande" . "iso10646-1"))
>
> This works great for Lucida, but I couldn't get Monaco or Courier  
> New to work.
>
> As has been pointed out the greek characters probably shouldn't be  
> "symbol" in the first place.
>
>
> <pastedGraphic.png>
> <pastedGraphic.png>

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Jun 6, 2009, at 11:46 PM, Adrian Robert wrote:

> Should I check this in?  I believe it monotonically improves the  
> situation from before from the user perspective, and it's definitely  
> a step forward from the code perspective.  The Greek symbol problem  
> is still there, but at least wasn't made worse.

Yes, I'd say check it in.  I didn't have time to review the code, but  
as said, I tried it and think its a definite improvement.
- David

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#3174: NS: greek glyph rendering incoherent

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Apr 30, 2009, at 11:21 AM, Mac Pigman wrote:

> 2.  The display of Greek is off.  The default font won't display  
> accented
> characters at all.  The font I've been using,
> -apple-monaco-medium-r-normal--12-120-72-72-m-120-iso10646-1, does  
> display
> all of the characters, but the accented ones are a different size,  
> and the
> Greek in general looks like a comic book.

Hmm.  With M-x view-hello-file, I can see them (in Monaco).
Switching to text-mode will make it use Lucida Grande (the default),  
but, as shown below, this works for me.  I started Aquamacs with -q  
(e.g., see Help->Diagnose menu).  Could you try that too, just so we  
make sure we're talking about the same "default font"?

As for the actual glyphs and also the accented alpha in the example, I  
fully agree: they're ugly, both in Monaco and in Lucida.

I think there's something wrong...  I'm attaching a screenshot of  
Emacs/22 (Carbon), where the greek glyphs are rendered coherently.

The last screenshot shows Emacs 23 (NS) again, started with -Q and in  
the default font.  There, the accented alpha isn't rendered at all.






[-- Attachment #2: pastedGraphic.png --]
[-- Type: image/png, Size: 11056 bytes --]

[-- Attachment #3: Type: text/plain, Size: 3 bytes --]





[-- Attachment #4: pastedGraphic.png --]
[-- Type: image/png, Size: 13098 bytes --]

[-- Attachment #5: Type: text/plain, Size: 2 bytes --]




[-- Attachment #6: pastedGraphic.png --]
[-- Type: image/png, Size: 10734 bytes --]

[-- Attachment #7: Type: text/plain, Size: 2297 bytes --]





ά character:

In Emacs 23 (Cocoa/NS):

         character: ά (940, #o1654, #x3ac)
preferred charset: greek-iso8859-7
		   (Right-Hand Part of ISO/IEC 8859/7 (Latin/Greek): ISO-IR-126)
        code point: 0x5C
            syntax:
		   w 	which means: word
          category:
		   .:Base, g:Greek, j:Japanese
       buffer code: #xCE #xAC
         file code: ESC #x2C #x46 #x5C
		   (encoded by coding system iso-2022-7bit-unix)
           display:
		   by this font (glyph code)
     nil:-apple-Lucida_Grande-medium-normal-normal-Regular-13-*-*-*-*- 
*-iso10646-1 (#x1AF)

Character code properties: customize what to show
   name: GREEK SMALL LETTER ALPHA WITH TONOS
   old-name: GREEK SMALL LETTER ALPHA TONOS
   general-category: Ll (Letter, Lowercase)
   decomposition: (945 769) ('α' '́')

There are text properties here:
   charset              greek-iso8859-7


In Emacs 23 (Cocoa/NS), with the default font (Monaco):

         character: ά (940, #o1654, #x3ac)
preferred charset: greek-iso8859-7 (Right-Hand Part of ISO/IEC 8859/7  
(Latin/Greek): ISO-IR-126)
        code point: 0x5C
            syntax: w 	which means: word
          category: .:Base, g:Greek, j:Japanese
       buffer code: #xCE #xAC
         file code: ESC #x2C #x46 #x5C (encoded by coding system  
iso-2022-7bit-unix)
           display: by this font (glyph code)
     nil:-apple-Monaco-medium-normal-normal-Regular-12-*-*-*-*-*- 
iso10646-1 (#x00)

Character code properties: customize what to show
   name: GREEK SMALL LETTER ALPHA WITH TONOS
   old-name: GREEK SMALL LETTER ALPHA TONOS
   general-category: Ll (Letter, Lowercase)
   decomposition: (945 769) ('α' '́')

There are text properties here:
   charset              greek-iso8859-7






In Emacs 22 (Carbon):
   character: ά (2908, #o5534, #xb5c, U+03AC)
     charset: greek-iso8859-7 (Right-Hand Part of Latin/Greek Alphabet  
(ISO/IEC 8859-7): ISO-IR-126.)
  code point: #x5C
      syntax: w 	which means: word
    category: g:Greek
buffer code: #x86 #xDC
   file code: ESC #x2C #x46 #x5C (encoded by coding system  
iso-2022-7bit-unix)
     display: by this font (glyph code)
      -apple-lucida grande-medium-r-normal--14-140-72-72-m-140- 
iso10646-1 (#x3AC)

bug#3174: NS: greek glyph rendering incoherent

[Alan Third]

David Reitter <david.reitter@gmail.com> writes:

>> 2.  The display of Greek is off.  The default font won't display
>> accented
>> characters at all.  The font I've been using,
>> -apple-monaco-medium-r-normal--12-120-72-72-m-120-iso10646-1, does
>> display
>> all of the characters, but the accented ones are a different size,
>> and the
>> Greek in general looks like a comic book.
>
> Hmm.  With M-x view-hello-file, I can see them (in Monaco).
> Switching to text-mode will make it use Lucida Grande (the default),
> but, as shown below, this works for me.  I started Aquamacs with -q
> (e.g., see Help->Diagnose menu).  Could you try that too, just so we
> make sure we're talking about the same "default font"?
>
> As for the actual glyphs and also the accented alpha in the example, I
> fully agree: they're ugly, both in Monaco and in Lucida.
>
> I think there's something wrong...  I'm attaching a screenshot of
> Emacs/22 (Carbon), where the greek glyphs are rendered coherently.
>
> The last screenshot shows Emacs 23 (NS) again, started with -Q and in
> the default font.  There, the accented alpha isn't rendered at all.

Hi David, this all looks fine to me in Emacs 25, and the NS port now
uses the Mac port font backend, so I'd be surprised if these issues
still persist.

Am I OK to close this bug?
-- 
Alan Third

bug#3174: NS: greek glyph rendering incoherent

[Alan Third]

Alan Third <alan@idiocy.org> writes:

> David Reitter <david.reitter@gmail.com> writes:
>
>>> 2.  The display of Greek is off.  The default font won't display
>>> accented
>>> characters at all.  The font I've been using,
>>> -apple-monaco-medium-r-normal--12-120-72-72-m-120-iso10646-1, does
>>> display
>>> all of the characters, but the accented ones are a different size,
>>> and the
>>> Greek in general looks like a comic book.
>>
>> Hmm.  With M-x view-hello-file, I can see them (in Monaco).
>> Switching to text-mode will make it use Lucida Grande (the default),
>> but, as shown below, this works for me.  I started Aquamacs with -q
>> (e.g., see Help->Diagnose menu).  Could you try that too, just so we
>> make sure we're talking about the same "default font"?
>>
>> As for the actual glyphs and also the accented alpha in the example, I
>> fully agree: they're ugly, both in Monaco and in Lucida.
>>
>> I think there's something wrong...  I'm attaching a screenshot of
>> Emacs/22 (Carbon), where the greek glyphs are rendered coherently.
>>
>> The last screenshot shows Emacs 23 (NS) again, started with -Q and in
>> the default font.  There, the accented alpha isn't rendered at all.
>
> Hi David, this all looks fine to me in Emacs 25, and the NS port now
> uses the Mac port font backend, so I'd be surprised if these issues
> still persist.
>
> Am I OK to close this bug?

I'm going to close this now. As always, feel free to re-open if you're
still seeing it.
-- 
Alan Third