[Egyptian] Two group joiners

[Bob Richmond]

Hi Stéphane

Thank you for suggesting what you’d find useful as the basis for attempting to find a possible consensus. 

Lets see what can be done.

If you've had time to read my earlier document about Word Processing I hope you now have a clearer idea of why I'm holding firm on complexity and the interests of Egyptologists in general.

As far as I can tell there is a consensus for

1) Vertical [:] // Already in MdC and in Bob’s proposal
2) Horizontal [*] // Already in MdC in Bob’s proposal

So it would be helpful if further discussions started from this point. Does anyone disagree or can we take this and move on? 

[However interesting the evolving http://www.unicode.org/L2/L2016/16210-egyptian-control.pdf is as a theoretical model against which other concepts may be tested].

I'd also like to add another potential consensus item:

0) Any representation of the Westcar Papyrus (as in the WP doc as a fairly typical hieratic transcription) should not be significantly more complex in  a consensus system unless there is a compelling reason.

Again, does anyone disagree?

If we can be settled on these points I can try to map something out on the other items.

On 4 corners etc. it's more complicated, partly because not all corners are equal. [I think Mark-Jan and myself might agree there's mileage in treating the Cobra-pattern distinctly for instance.] 

But lets come to that once we've a basis to move forward. 

If we can be settled with points 0-2 I'm happy to try to map out what I think are the next steps (taking into account your other points). And great if anyone else wants to contribute their take.

Bob


-----Original Message-----
From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of Stéphane polis
Sent: 28 July 2016 11:38
To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
Subject: Re: [Egyptian] Two group joiners

Dear Mark-Jan,

Yeap, I do agree.

As you can see, I’m simply trying to be imaginative and to think about the better possible consensus before the very close deadline (in order not to take the chance for everything to collapse or to go in unwarranted territories, because I do care). As such, I understand perfectly the cost of getting rid of parenthesis; my point is that, as we know that we need to make clusters (and there is not much room for discussion about this basic principle), the only alternative would be this ‘glue-precedence’ operator, discussed in Section 9 of the document, that has not yet been discussed by others. 

It’s one or the other, but there are logically no third option as far as I understand.
 
I would like to hear what you and others think about the ‘scope operator’ for the insertion, but to sum up, a basic consensus document for control characters could in my view contain only 8 control characters (and we know that we could handle most [if not all] of the cases discussed so far with these characters, that the scheme will be coherent, that it will be easy to expand with others operators without destroying everything, etc.), namely:

1) Vertical [:] // Already in MdC and in Bob’s proposal
2) Horizontal [*] // Already in MdC in Bob’s proposal

3) Groups (precedence operator) [.] // Needed for clusters (insertion, vertical, horizontal) and for avoiding the multiplication of group-joiners of various level in the future.

4) Top-left [⸥] // Agreed on by most (if not all)
5) Bottom-left [⸣] // Agreed on by most (if not all)
6) Top-Right [⸤] // Agreed on by most (if not all)
7) Bottom-Right [⸢] // Agreed on by most (if not all)

8) Scope operator [!] // A suggestion to be discussed

Maybe that a quadrat separator [-] should be added in order to avoid issues, e.g. with multiple corners insertions following one another (but this should be tested of course), and because after all, the basic unit of this writing system is the quadrat (not the sign, even if it happens that 1 sign = 1 quadrat).

These operators correspond to a very ‘flat’ and linear syntax (without ‘begin’ and ‘end’ markers that seem to be so problematic), which is a requirement from the Unicode specialists as I understand it.

If needed, I am ready to leave out of this ‘consensus’ document:
- The join
- The insert-center
- The stack
- The empty

Not because I think we don’t need them (I think it would be great to have), but (1) because I would like the discussion to focus on the 8/9 operators above, (2) because these additions are easy to make in a second step and will not impedes much for short term encoding.

That’s about it for me at the moment. I leave the floor to you, Bob and others. 

Let me stress that it’s probably difficult for me/us to make more steps in the direction of a consensus. At this stage, everyone should probably try and understand other’s point of view and accept that compromises are needed rather quickly...

As you can see in the summary above, the central point is about the group/precedence operator. 
Then the ‘scope’ operator and what you think about it.
The rest should be easily agreed on.

Unicode is not a one time thing, as Bob said, sure, but one decision can affect all the future developments.

Take care,

Stéphane

------------------------------------------------------
Chercheur qualifié F.R.S.-FNRS

Université de Liège
Service d'Égyptologie
Département des sciences de l’Antiquité
Place du 20-Août,
B-4000 Liège

http://www.egypto.ulg.ac.be
------------------------------------------------------



> Le 28 juil. 2016 à 11:32, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> a écrit :
> 
> Dear Stéphane,
> 
> To support to what you wrote on coherence: A long time ago we passed 
> beyond the stage of knowing we need certain primitives. The main 
> question is how to fit them together into a coherent scheme with a 
> syntax that is consistent and unambiguous, without sacrificing (too much) of the power of these primitives and how they can be combined.
> 
>> 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?
> 
> With respect to the discussion in Section 9 of:
> http://www.unicode.org/L2/L2016/16210-egyptian-control.pdf
> the '.' above is a notational variant of the 'levels' of operator 
> precedence, there achieved by having several copies of each primitive, 
> for different levels. Here, for every '.' added behind an operator one goes up one level of operator precedence.
> 
> Some trick using operator precedence, either using the '.' or using 
> several control characters per primitive with different binding 
> values, would be an alternative to having brackets. There is a 
> relatively straightforward mechanical mapping from one notation to the 
> other, so there should be no difference to the expressive power and I don't think that among us (TLA/Ramses/St Andrews) there is any firm commitment to brackets or otherwise.
> 
> But as explained in Section 9, there are costs to abandoning brackets. 
> Specifying the syntax with operator precedence formally would be a bit 
> tricky, it might not be easy for the human to know when to use :... or 
> *.. or insert_top_right. , and OpenType cannot really parse, as it is 
> not a general purpose programming language, and trying to implement 
> about a dozen different binding values
> (4 primitives times 3 levels of operator precedence) might be pushing our luck. 
> My working assumption is that an input method editor would be used to 
> edit hieroglyphic text in practice, so the actual syntax should not matter too much, as long as it is hidden from the user.
> 
> Best regards,
> Mark-Jan
> 
> _______________________________________________
> 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