[Egyptian] Two group joiners

[Stéphane polis]

Hi Bob,

> -> "possibly best known from Late Egyptian" (thinking e.g. tall narrow groups on the well-known Israel stela)? Doesn't really matter for point in hand so long as controls work well.

No, I agree, but it matters in terms of text/period frequency (see the comments made by Marwan): the way you describe it might lead UTC members to think that they are rather exceptional and limited to some hieroglyphic corpora. Quite to the contrary, they are very well documented (if admittedly not pervasive) from the FIP onwards. As such, the support of (several) levels of embedding is not just an adornment, but — in my view at least — a necessity for the arrangements of hieroglyphs in Unicode.

> Your example JSesh: m&&&(x:ib*Z1) falls into the "4 corners"/ligature topic.

Yes indeed.

> I don't think it features in the Ramses data you sent.

Certainly not: it comes from a Middle Kindgom stela (one of the BM collection, if I remember correctly). I repeated this enormous *caveat* several times regarding Ramses, but it’s worth probably saying it again: the data from Ramses are (close to be) comprehensive for *Ramesside hieratic* documents (with a small sample of hieroglyphic texts for the same period). For most of the hieroglyphic texts and for all the other periods, I’m afraid one has no way to query significant amounts of texts at the graphemic level at the moment: the only way to get an idea of what the encoding should cover is therefore, either by experience of the types of clusters attested or by going over publications a bit systematically. 

These kinds of groups are well attested in horizontal and vertical hieroglyphic texts as well; frequency? No precise idea, I would say 1 or 2 such groups by biographical texts on stelae during the MK to give you an idea. It’s productive and makes certainly quite a lot of them is you consider a broader corpus, but I would be unable to give you figures.

Now, this is a good illustration of my concerns regarding the coherence of the system and it’s later extension, and I would be really happy to have your opinion on what follows.

1) Let’s say that your group joiners are integrated in Unicode. (As I said, probably not a bad thing per se: it would allow to cover a lot of cases and other operators of the same nature could be added later for additional levels of embedding. One does not look at the broader picture in a first step, but let’s consider that it’s fine.)
2) We have groups such as m&&&(x:ib*Z1). We know they exist and are well attested, but we decide to ignore them for the time being. Fine.
3) We want to support them at some point in the future in a later extension, and let’s imagine that the ‘insert_Top_Right’ is available as an operator, we nevertheless need to find a way to say that it concerns a *group* of some sort and not only the ‘x’ coming after the ‘m’, for instance. Do you have an idea how to do this without some sort of parenthetical system? [this is a real question, no irony of whatever sort: I guess that one will not integrate as much INSERT operators as required by the priorities and possible combinations with respect to ‘:’ and ‘*’].
4) One could potentially decide to finally integrate some kind of parenthetical system for handling such cases in Unicode, m [top_right] (x:ib*Z1). However this would potentially lead to two ways of of encoding other (vertical and horizontal) groups. For instance, sin of your draft could be: <s [group_vertical_joiner] in : n> or <s * (in : n)>. 
5) The final decision is that such groups cannot be supported by Unicode (because of previous decisions as regards the syntax): it would mess up with the syntax previously defined for the group joiner and this is not acceptable. BAD.

I might completely miss something, but as we know that *making groups of signs* and *integrating them in various positions* (vertical, horizontal, corners) is part of the basic principles of the hieroglyphic script, there will probably be no huge discoveries in the years to come in this respect, why not trying to find a way to handle these grouping coherently directly in order to avoid problems that we’ll know we’ll have to face? 

I understood that parentheses are very difficult in Unicode, but can’t we think of a kind of ‘glue’ operator (precedence, as in Mark-Jan’s et al. proposal, p. 8-9), e.g. with the dot, <s * in :. n> or <m [insert_top_right] x :. ib *. Z1>, that would create groups by bounding signs together. What would be the problem of such an approach (it was initially suggested by Serge, not my idea, I insist)? Can you explain me why it would be problematic?

In my view, it has the advantage to deal with groups in a homogeneous way (and we know this is something that has to be supported), to avoid parenthesis (because the Unicode specialists seems to agree that it’s a bad idea), to be easily readable and understandable by the lay-egyptologist (if you want signs to stick together and they don’t, just add a dot), etc., etc. The number of cases with several levels of precedence are rarer and could be handled by the multiplication of such an operator (it becomes then admittedly a bit more difficult to read but it is still easily understandable by humans and machine alike). This solution is economic — addition of a single operator (that could be repeated; instead of opening/closing brackets or several types of groups joiners (as in your proposal) —, adequate (because it allows to cover all the kind of groups that we discussed so far); it won’t pollute the syntax — if you do not need it, don’t use it; etc., etc.

What’s the argument against such an approach (again, a real question)? 
As I said, I’m also eager to learn and understand the issues!

If one could build a consensus document that goes in this direction, I’m in.

Best wishes,

Stéphane



> Ultimately it ought to be a supported Unicode cluster. It was in the original proposal. In the revision I've had to make to take into account concerns raised in April (and since) it currently isn't available and you'd need a HLP for release 1. We can discuss that after I've finished writing it up today - there is some wiggle room!
> 
> Bob
> 
> 
> -----Original Message-----
> From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of Stéphane polis
> Sent: 26 July 2016 11:58
> To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
> Subject: Re: [Egyptian] Two group joiners
> 
> Dear Bob,
> 
> Thanks for this document! Some remarks. 
> 
> P. 1 - tall groups are not ‘best know from Late Egyptian’: probably rarer in Old Kingdom inscriptions (but this should be checked and I don’t know of studies about this aspect, Nigel?), they are everywhere in hieroglyphic inscriptions (and perhaps more and more systematically present) from the First Intermediate Period onward (down to the Late Period). Look for instance at the biographical texts on FIP and Middle Kingdom stelae; you’ll find several examples on every single document. The same remark applies to your note after the title ‘horizontal text’ obviously.
> 
> P. 1  - Note. 'The topic etc.’: I understand that you do not want to conflate the issues, but in a broader perspective why not acknowledging the fact that the same principles apply, namely make groups that are somehow scaled down for fitting in horizontal, vertical or diagonal arrangements. Your solution is probably convenient for vertical and horizontal grouping in most cases (even if it probably implies later additions of additional lower/higher level operators for more complex embedding), but could you explain how you intend to deal with e.g. groups like (in s*xm-ib*), frequent as well in the same context? Offering a solution to this issue would be a big step forward in my view! Best wishes, Stéphane
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com