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

[Mark-Jan Nederhof]

Dear Stéphane,

> 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.

As we discussed before, I have considered splitting RES 'insert' into two primitives, called 'insert' and 'inserted'. 
They differ only in the order of the 'big sign' and the 'inserted sign'. So insert(A,B) could mean 'insert B into A' and
inserted(A,B) could mean 'A is inserted into B'. This would solve a long-standing problem in RES that
the reading order is out of sync with the notational order. What you propose goes in the same direction.

There are advantages and disadvantages of course.

> ****** 1. Insertion with a flexible syntax and ‘orientation’ operators *******
> [...]
> 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. 

I think it is feasible. It would require the encoder to actually ask themselves what the reading order is.

> ***** 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 don't think this works because what is inserted is a group in general, and then where do you 
place the '!' ? I think if you want to go down this route, it seems more attractive to introduce
a separate tier of annotation, in which you place indices at each sign, enumerating reading order.
This would be outside Unicode.

> 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.

I think we discarded this idea some weeks ago, but the general direction of thinking, that of trying 
to express the insertion-into-the-cobra differently from other insertions in the bottom-left corner, 
without introducing additional notational elements, might still be worth considering. 

I had my doubts about using [:_and_kerning] for this purpose, as it requires 'magic' 
from the font and/or rendering engine, to know that the cobra is special, and it is not
just pushing the two groups in the vertical arrangement together, but is actually
inserting the whole second group inside the first group. So we would get two ways of expressing 
what is really insertion, but expressed in two very different ways.

One option might be to use 'insert-into-the-middle' for the cobra combination. In the
current syntax, 'insert-into-the-middle' cannot be combined with some other 
insertion-into-a-corner, but this may not be needed. Because for 'insert-into-the-middle'  
the inserted sign comes after the main sign, the special case of the cobra would be solved,
with respect to reading order.

I believe we have assumed implicitly that 'insert-into-the-middle' is only used for signs
that more or less enclose some whitespace in the middle, whereas the cobra doesn't.
We have to drop this assumption of course for the above to work.

By the way, our decision in Cambridge to replace 'insertion-into-top' and 'insert-into-bottom'
by a suitable vertical grouping, plus 'kerning' (fitting, JOIN), and similarly for insertion into 
left and right, is not entirely unproblematic. Consider for example the two raised arms (kA). 
Inserted (from above?) might be a larger group, such as the bull's head with
Z1*Z1*Z1 underneath. Trying to encode this with:
bullshead:Z1*Z1*Z1 [:_and_kerning] raisedarms 
has the same problem as using kerning for the cobra combination, namely to require magic, 
to know to squeeze the three Z1 together and then to 'slide' the whole group into the raised 
arms, and to know that not only the three Z1 go into the cobra, but also the bull's head.

So how about we use 'insert-into-the-middle' for this as well? Does this then introduce
new problems with reading order? Sometimes, as in Hm-kA, but in other cases it is
fine as with t or nTr or nsw inside. We should accept that if we encode graphical order only
(whatever that means for the 2 dimensional writing system) we cannot guarantee to also
always perfectly capture reading order.

Best regards,
 Mark-Jan