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

[Stéphane polis]

Dear Mark-Jan,

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

Good, that’s already something to consider then.

>> ***** 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 '!’ ?

Sorry, I’m tired, slow, and not sure I understand… Could you give an example of what you mean here?

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

Agreed.

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

This could be a practical solution of course, but this would stretch quite a bit the definition of the ‘insert-into-the-middle’ (as you say below actually) for no good reason (except to solve a reading issue), and would lead one to use ‘insert-into-the-middle’ in unprincipled way. I mean, what would be the rationale for choosing ‘bottom-left’ and ‘middle’? The only one is a graphic one, and I’m not sure that a reading motivation is good. But an option to keep in mind of course.

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

Nope, that’s for sure. For the cases that you mention, I wonder whether we should not collect more evidence and prepare a later addition with ‘insert-top’ and ‘insert-bottom’ based on this (for insert bottom, one can think of the combination of ‘pt (sky)’ with several signs, etc.), rather than to stretch the definition of ‘insert-middle’. But this remains certainly an open debate. 

As a general point: mixing insertion and kerning (or join) for a single phenomenon annoys me a bit to be honest. And I think this is also you view, right?

Best wishes,

Stéphane

> 
> Best regards,
> Mark-Jan
> 
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com