bug#15273: 24.3.50; Combining character sequences are displayed weirdly

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

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

>>>>> On Sat, 7 Sep 2013 10:47:05 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> nsfont.m has problems with composition, there is even comments
>> about this in the code.  But from what I see on X11 and what you
>> reported from W32, no other platform does produce the correct
>> result (i.e. the ! and the triangle in the same place), so
>> comparing to those backends doesn't help.

> FWIW, I tested the mac port that has another font driver, and it
> doesn't work correctly either.  It does not find a good font for the
> triangle and only displays an empty square.  No composition happens.

That square is actually the glyph for U+20E4 in the PCMyungjo font.
Though it is not correct of course, but TextEdit.app also selects
PCMyungjo for U+20E4 by default and displays the square.

We need some tricks to make the composition happen for this case on
the Mac port.

(set-fontset-font t #x20e4 "STIXGeneral")
(set-char-table-range composition-function-table #x20e4
		      (cons ["!." 1 font-shape-gstring 0]
			    (aref composition-function-table #x20e4)))

The last element in the vector is an extension specific to the Mac
port, and it specifies the position of the character (relative to that
for the key) from which the font object is obtained.  It was
originally introduced to support Variation Selectors 15 (text-style)
and 16 (emoji-style).

The result may not be satisfactory, but its consistency with that of
TextEdit.app (upper window in the screenshot) indicates it is the
behavior of the standard text shaper on OS X.

The other latin example seems to work perfectly on the Mac port
without any settings.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: composition.png --]
[-- Type: image/png, Size: 181223 bytes --]