[Egyptian] Ligature joiners - evidence needed please

[Bob Richmond]

Hi Simon

Thanks for the examples.

Just to be clear to all. I’d like to make a good case for controls and identify/illustrate any variations or issues needing discussion.

If anyone has time to create a doc/PDF with a bunch of graphic illustrations of clusters showing awkward cases this would save me time – I’ve plenty else to do on this ASAP so help appreciated.

Bob

From: Simon Schweitzer<mailto:schweitzer at bbaw.de>
Sent: 21 July 2016 08:40
To: Egyptian Hieroglyphs in the UCS<mailto:egyptian at evertype.com>
Subject: Re: [Egyptian] Ligature joiners - evidence needed please

Hi all,

concerning the one ligature joiner vs. the four corner ligature joiner:

> I’ve not yet seen any data, evidence or rationale about the suggested 5 positional ligature system discussed at Cambridge. I don’t have unlimited time to research all this myself and I’m not an Egyptologist. Technically such a system can be added to current controls but it needs to be well-defined, detailed and justified if it is to be submitted. [This is what I’m doing with the group-joiners].

Why should one use four instead of one ligature joiner?
Because the encoding with four control characters offers more
information. It is readable for the egyptologist and for the font
developer. Cf. my example from the last week: In the temple of Kom Ombo,
there are two ligatures with the knife T31 and the bread X1. We can
encode this in RES with insert[bs](T31,X1) and insert[te](T31,X1). The
position of the X1 is obvious. But if we have T31&X1, one cannot decide
the position of X1. And a font developer could create such ligature with
the "corner control character" even if he do not see the original
reference, but he cannot do anything if he only has T31&X1. But what
about T31&N29 or T31&O49, ligatures, that occurs in the Kom Ombo temple?
We (the egyptologists, the font developers, the fonts) cannot interpret
the ligature only with this encoding.

Okay, the Kom Ombo temple belongs to the ptolemaic and not to the
"classical" writing system. But the encoding of this temple is important
for the TLA project, because the Kom Ombo project wants to encode their
data in our system, so that we will have such encodings in our material.
But there are such problems in more classical data, too:

For example the ligatures with E6. Bob, you offers three ligatures in
your EGPZ 1.0 BETA Specification (August 2007): U+eb13 E6&Z2d, U+eb14
E6&X1, and U+eb15 E6&Z1. These ligatures could be encoded as
insert[te](E6,Z2), insert[te](E6,X1), insert[b](E6,Z1) in RES. But there
are examples where the plral strokes are in another corner. These
examples (DZA 24.607.440
<http://aaew.bbaw.de/dza/24/24605000/24607440.gif> or DZA 28.723.300
<http://aaew.bbaw.de/dza/28/28720000/28723300.gif>) could be encoded as
insert[bs](E6,Z2) in RES. As in T31&X1, the encoding of E6&Z2 is
ambiguous. The three ligatures which E6 use different corners.
Therefore, it is not clear how to interpret E6&D2 or E6&X1&Z2. But if we
have the four corner control characters, we could encode something like
the RES code insert[te](E6,D2) instead of E6&D2 in DZA 28.722.290
<http://aaew.bbaw.de/dza/28/28720000/28722290.gif>. The E6&X1&Z2 would
be the readable insert[bs](E6,X1*Z2) in RES (DZA 28.722.530
<http://aaew.bbaw.de/dza/28/28720000/28722530.gif>). BTW, this example
is an argument for the special grouping character "g*" which Michael
wrote on the whiteboard last week: X1 g* Z2 insert_bs E6 and the
g*-group has to be parsed first. But this is another topic...

Best regards,

Simon

_______________________________________________
Egyptian mailing list
Egyptian at evertype.com
http://evertype.com/mailman/listinfo/egyptian_evertype.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160721/5b7012fe/attachment.htm>