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

[Mark-Jan Nederhof]

Dear Stéphane,

> >> ***** 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?

Sorry, I misread the first time around. The way I understand it now, it might be an unambiguous syntax,
at least if we rule out groups with more than one core_group in which to insert. I have an uneasy feeling 
though about the interpretation of the [insert_bottom_left] depending on some mark somewhere else
to the left or to the right. And would it be possible to have no marked element at all, and what would 
that mean? (Defaulting to the left-most or right-most element?)

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

Yes, I see problems there. As Michael reminded us, the font designer needs instructions to know 
what to do. If the instructions are few, this is easier than if there are many instructions, with many 
special rules and exceptions. I also would hope to keep open the possibility of doing the rendering 
totally automatically, certainly outside the context of OpenType, in applications where general-purpose 
programming languages can be used. Having an encoding where every primitive has a simple 
procedural interpretation (or, as simple as possible) would therefore be a tremendous advantage. 

And as you suggested, the encoder needs to know how to encode. Having many special cases 
makes it more difficult to decide.

There are trade-offs, as many times before.

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

We could keep this open. My working hypothesis is that where one would feel the need for insert-top or insert-bottom 
there is usually some case to be made for either vertical+kerning or insert-inside, which would avoid having more primitives. 
After having gone through a fair number of original inscriptions, I have seen few exceptions. But by all means we
should keep looking and perhaps our views might change.

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

I would agree it is best to have sharp distinctions where sharp distinctions can be made. This said, we
are dealing with an extraordinarily complex writing system. We need not be under the illusion there is only
one correct way to encode a text, at least if we are working from an original inscription. (If we take JSesh as
input, the choices have been made already.)

For example take Dd=f, with cobra + hand + viper. Sometimes you see hand:viper clearly entirely 
inside the bounding box of the cobra. Sometimes you see the hand in the cobra, while the viper 
is entirely below, with the tail of the viper extending below the tip of the tail of the cobra. Sometimes, 
the head of the viper is inside the bounding box of the cobra, while the tail of the viper extends 
below the tail of the cobra. 
So how should this then be encoded?
(d insert-left-corner cobra) :[fit] f 
or 
(d:f)  insert-left-corner cobra
? 
My view is that both should be allowable. [Modulo the notation, which might or might not be in sync
with reading order.] Would you agree?

Best regards,
 Mark-Jan