Re: Entering emojis

[Gregory Heytings <gregory@heytings.org>]

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


>
> Like I said: the new way of formatting this script is not yet supported 
> widely enough.
>

Okay, so IIUC, Unicode has decided to do something that goes against the 
existing practice.  Given the limited available manpower in that narrow 
subfield, I'm not quite sure it was the best thing to do.  Using a font 
with predefined ligatures is much easier to enter text.

>> I just looked at section 11.4 of the Unicode Standard.  The first 
>> character sequence in figure 11-2 is not a valid quadrat.
>
> Why not?
>

I should have said: it's not a valid quadrat from the point of view of the 
Aegyptus font, which defines ~2500 valid quadrats.  Which probably means 
that this combination A1 above O1 (combining a man and a house) does not 
happen in practice (or happens rarely enough that it isn't yet included in 
the quadrats known by that font).

>
> And it isn't supposed to be a quadrat, AFAIU, anyway.
>

It is, a quadrat is a combination of two to four glyphs.

>> The second one are two characters that would normally be placed one 
>> above each other, so to obtain what is displayed in the Unicode 
>> Standard it's necessary to separate them with a zero-width non-joiner.
>
> AFAIU, U+13431 is the joiner to be used in that case.
>

But it's not a joiner, it's a non-joiner.  The logic is the opposite of 
what Unicode decided to do: known quadrats are automatically recognized 
and combined appropriately when their individual characters appear one 
after the other in a string.  It's only when you want to avoid this that 
you have to add a non-joiner.

>
> And you didn't answer my question: does LibreOffice with the Aegyptus 
> font display those sequences correctly?
>

I'm not sure what you mean by "those sequences".  The sequences in the 
patch are rendred correctly.  The sequences in figure 11-2 of section 11.4 
of the Unicode standard are not rendered correctly.  See the attached two 
pictures.

[-- Attachment #2: Type: image/png, Size: 13406 bytes --]

[-- Attachment #3: Type: image/png, Size: 2062 bytes --]