Talk:Combining grapheme joiner

(Redirected from Talk:Combining Grapheme Joiner)
Latest comment: 4 years ago by Spitzak in topic Hebrew example broken?

Contesting PROD edit

The deletion of this article was proposed with the explanation: "Overly technical article which doesn't provide sources to demonstrate this single unnotable unicode character is deserving of its own entry."

I contest this. It is not supposed to be overly technical, and if it is overly technical, please say where exactly and i'll try to fix it.

And this character is very notable for people who need to type Biblical Hebrew and other languages that require intricate typography. --Amir E. Aharoni (talk) 09:38, 23 January 2010 (UTC)Reply

of course, the prod was entirely misguided. A request for better sources and/or a merge suggestion may be arguable though. --dab (𒁳) 09:46, 23 January 2010 (UTC)Reply

I proposed the article for deletion. I would suggest that not every character in the whole typographical spectrum is notable. Clearly this article, like every other article, needs to show some references to demonstrate the notability of its subject. Dylanfromthenorth (talk) 00:20, 25 January 2010 (UTC)Reply

Hebrew example broken? edit

All three texts are being rendered identically in both Safari on OS/X and Linux with Pango, and directly by a Pango test program. Since these are supposedly the best layout engines out there is the example actually right, or is this something they all implement wrong?Spitzak (talk) 21:41, 29 January 2011 (UTC)Reply

There's a note in the article that special font is needed to view the example, perhaps a pre-rendered image is needed.

A bit OT, if I copy-paste these examples from browser to a terminal, the first two appear to consist of identical code point sequences, either there's a mistake in the article or perhaps browser and/or terminal corrects the second example?

>>> list(map(unicodedata.name, "ה"))
['HEBREW LETTER HE', 'HEBREW POINT PATAH', 'HEBREW POINT METEG']
>>> list(map(unicodedata.name, "ה"))
['HEBREW LETTER HE', 'HEBREW POINT PATAH', 'HEBREW POINT METEG']
>>> list(map(unicodedata.name, "ה"))
['HEBREW LETTER HE', 'HEBREW POINT METEG', 'COMBINING GRAPHEME JOINER', 'HEBREW POINT PATAH']

I too observed the same thing. The first two examples are identical. I think the cause is that when saving an edit in Wikimedia, in the absence of anything that would prevent it, the keyed text is normalized to NFC. The illustration requires correcting. There are some Hebrew fonts that do not render HE with METEG & PATAH correctly, but Ezra SIL SR is not one of them. DFH (talk) 15:22, 10 December 2015 (UTC)Reply
I have edited the three examples, by using HTML entities in the place of Hebrew Unicode. At the same time, I corrected the order of the diacritics in the second example. DFH (talk) 15:40, 10 December 2015 (UTC)Reply
In some applications (e.g. Microsoft Excel running in Windows 7), the font Ezra SIL SR renders example 2 the same as example 3. A lot depends on the text rendering engine built into each application. DFH (talk) 15:46, 10 December 2015 (UTC)Reply
There are also several Unicode fonts that do display Hebrew, but which do not support the CGJ. DFH (talk) 15:48, 10 December 2015 (UTC)Reply
On all browsers I try, all 3 render identically, even with the newest edit, ie the order and whether there is a CGJ do not make a difference. Not knowing Hebrew, I do not know if the image I am seeing (which looks like an 'n' with a '+' centered below) is correct or wrong. Is there any explanation for this? It may be necessary to come up with images showing what the expected results are.Spitzak (talk) 19:16, 15 December 2015 (UTC)Reply
I'd be grateful to see an image of how these are supposed to be rendered. ciphergoth (talk) 15:56, 3 July 2017 (UTC)Reply

Again it would be really nice if somebody who knows Hebrew would draw or render correct images. I suspect almost every browser is broken, and just maybe it will encourage browsers and font libraries to be updated if they had this visible example.Spitzak (talk) 19:12, 14 May 2019 (UTC)Reply