[Egyptian] On "A system of control characters for Ancient Egyptian hieroglyphic text" (2016-07-23)

[Stéphane polis]

> Apart from Mark-Jan et al (in http://www.unicode.org/L2/L2016/16210-egyptian-control.pdf)  who propose that a "Cobra with group tucked inside" should be encoded with the group preceding the Cobra. For the common and simple example 'Dd' (Cobra containing hand) he proposes the 'd' hieroglyph comes before the 'D' in the code sequence. I'm actually quite shocked that several experienced Egyptologists want to do this.

The issue of the reading order is a real one and probably not an easy one to solve; but it should be tackled and integrated in the discussions, I definitely agree.

In a first place, I was of the opinion to stick strictly to the graphemic order (as some clusters are not always easy to interpret in terms of reading; and this is the conclusion that we reached with Michael at the pub and discussed with Mark-Jan, Serge and others), but a second thought made me understand why it would not be ideal and very practical in Unicode (notably for searches), and admittedly weird for Egyptologists: encoding Dd as <d [insert_bottom_left] D> is not natural, to say the least. This is why Serge suggested to deal with such case as <D [:_and_kerning] d>, if I remember correctly, but not an ideal solution either of course.
 
In order to cover both the graphemic and reading order, I see at the moment two options (there might be other ones and I’m carefully listening to what you guys think).

****** 1. Insertion with a flexible syntax and ‘orientation’ operators *******

I mean here insertion operators that you could position before or after a sign depending on the reading order.
Let’s take a basic example. I agree that you would like to read Dd 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-7.pdf
Type: application/pdf
Size: 2393 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160728/8ee97b93/attachment.pdf>
-------------- next part --------------
 as <D [insert_bottom_left] d>, with the inserted sign coming after.
On the other hand, for tA (the feminine article) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-8.pdf
Type: application/pdf
Size: 2396 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160728/8ee97b93/attachment-0001.pdf>
-------------- next part --------------
, you would like to have <t [insert_bottom_left] A>, with the inserted sign coming before.

For this to be possible, we would have to define two operators that ‘orient’ the insertion: one such as ‘>’, saying that the sign is inserted in what follows, and one such as ‘<‘ saying that the inserted sign goes in the sign before (see the signs used in Bob’s draft). So for Dd and tA, respectively:
D [insert_bottom_left]< d
t [insert_bottom_left]> A

Possible, but probably not ideal given the problems that you would face for multiple insertions. 
Let’s take, for instance, (i)w.t 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-9.pdf
Type: application/pdf
Size: 2541 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160728/8ee97b93/attachment-0002.pdf>
-------------- next part --------------
 (t&w&D54). Ideally, you would like to read something which is not t&w&D54, but rather:
w [insert_bottom_left]< t [insert_top_right]< D54, in order to stick somehow to an ideal reading order (even if the sequential reading is questionable in such cases). 
However, it is unclear how one knows that the target of the insertion of D54 is ‘w’ and not the ’t’, with such a syntax.

An elegant solution for handling this could be to use:

***** 2. A single ‘scope operator’ ****

I mean here an operator that marks one sign as the scope of all the insertions around. Let’s say we use ‘!’ as a scope marker, then the examples above would become:

D! [insert_bottom_left] d
t [insert_bottom_left] A!
w! [insert_bottom_left] t [insert_top_right] D54

The graphemic order is explicit and the reading order is respected.

I do not know if this is manageable or practical from an IT/font point of view (it does not seem terrifically problematic though), but this second solution has the advantage of being economic (a single operator), graphically explicit (one knows exactly which sign goes into which and at which position), and ‘linguistically’ searchable (the reading order is respected). For instance, xm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-10.pdf
Type: application/pdf
Size: 3314 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160728/8ee97b93/attachment-0003.pdf>
-------------- next part --------------
 as <x [insert_top_right] m!>, respects the reading order and is graphically explicit.

There will be ambiguous cases, I have no doubt, but this is unavoidable if one wants to make any room to the ‘reading’ order in the encoding of ligatures.

What do you think?

Best wishes,

Stéphane



> 
> Bob
> 
> -----Original Message-----
> From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of Michael Everson
> Sent: 27 July 2016 18:29
> To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
> Subject: Re: [Egyptian] On "A system of control characters for Ancient Egyptian hieroglyphic text" (2016-07-23)
> 
> On 25 Jul 2016, at 17:16, Bob Richmond <bobqq at live.co.uk> wrote:
>> 
>> Congratulations for being the first to (heartfully) express public support for a representation of MdC X1:R1 that uses  3 control characters. 
> 
> Well, I don’t.
> 
> “Ligate X with Y” does not tell font developers anything. This is why the five controls are superior, and why a generic ligator is dangerous, because if you end up with six controls then you will have multiple spellings for many many many clusters.
> 
> Michael. 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com