[Egyptian] Preliminary proposal to encode Möller's Egyptian Hieroglyphs in the SMP of the UCS

Thu Sep 22 14:11:15 BST 2016

Hi Michael

I agree with Mark-Jan Moeller 259 v1 looks like it can be identified with K004 . The v2 and v3 versions identify with the well-known later form (HG-K4A) so should probably be separately encoded as K004A.

(To list - I expect Michael will be pleased to receive more detailed feedback on specifics from Egyptologists and other as requested in N4741 section 5).

Bob

From: Mark-Jan Nederhof<mailto:mn31 at st-andrews.ac.uk>
Sent: 19 September 2016 12:21
To: Egyptian Hieroglyphs in the UCS<mailto:egyptian at evertype.com>
Subject: Re: [Egyptian] Preliminary proposal to encode Möller's Egyptian Hieroglyphs in the SMP of the UCS

With the 1071 signs in Unicode, there may at present be roughly two ways of
encoding texts:

(1) There are not-quite-so-serious users like me who, perhaps from a misplaced
sense of being principled, refuse to use dubious, ill-documented,
ill-standardized sign lists derived from the Hieroglyphica, and who therefore
only use the Unicode set, as that is at least stable. Whenever they come
across a sign that is not in Unicode, they have to use a place holder. (I then
tend to use a question mark in my encoding, with a footnote describing what
the sign depicts.)

(2) Then there are serious users, like TLA and Ramses, who cannot afford to
leave place holders in their encoding. They use one from an infinite supply of
extended sets, and won't bother with Unicode, because that is much too
restrictive. They realise fully well of course what is wrong with the extended
sets, but at present there is no other alternative given their requirements.

Neither of these types of users is happy with the status quo. The solution
could be a thoroughly designed extended set in Unicode, properly researched
and documented.  A solid list is in the making, in the form of the
Thot sign list.  The problem is that this takes time and a lot of effort, and
apparently some people are not patient enough to wait for the project to be
completed, or at least for the project to be advanced enough to cover most
signs.

So what is to be done in the short term? For the people in (2) only
a very comprehensive collection of signs in Unicode will suffice, and
make them switch from their own sign lists to Unicode. But this is not
forthcoming. For the people in (1), what would help tremendously are
incremental additions with the most frequent signs not yet in Unicode.
The most frequent signs also happen to be the ones that are best understood.
But incremental additions cost extra time and detract from the purpose of
building a more complete set.

In contrast, random small additions will be pointless and even harmful, because:

* Adding rare signs will not noticeably decrease the frequency of having
to leave place holders while encoding typical texts.

* The more unbalanced a sign list is, the more difficult it is for users to find their
way, and choose the most appropriate signs for an encoding.

* Premature additions may interfere with more additions later. Thorough and
systematic investigations will be needed for deciding between say graphical
variants and characters, and these investigations benefit from having a broad
view over the collection of signs in a comprehensive collection of texts, so
that the most appropriate choice can be made which shapes deserve to become
code points and be representatives of a range of variants.

Trying to fish accidental glyphs from Moeller that, probably for good reason,
didn't make their way into the Gardiner set leads exactly to an addition that
we don't need.  Sure, some font designers who have nothing better to do will
be happy to be able to draw a few more signs for their Unicode fonts, but the
extension will have zero benefit for people who are actually encoding texts.

What further bothers me is a repetition of mistakes from the past. What we
need is not only cross references, but a thorough and justified description of
what signs depict and mean. Only then can one answer the question how a sign
relates to other signs. I'm reminded of e.g. sign L008, a hapax sign (only one
obscure occurrence is known, with uncertain reading) that has been put under
the insects, for no reason that anyone can remember, and probably incorrectly.
Such things should never have happened. But if the same procedures are
followed for the next addition to the Unicode sign list, such calamities will
happen again.

By including even signs from Moeller that are in footnotes one is scraping the
barrel. Are we really so desperate to add as many signs as possible, no matter
for how bad a reason?

For example, 13458 refers to v3p4n1, a footnote for Moeller 36, which is
clearly identifiable with Gardiner A008. Those who can read German see that
the footnote says that the dots above the sign in some graphical variants are
"filler points", and that the sign should _not_ be associated with another
sign that is not known from hieratic, and that other sign I would read as the
man sowing seeds (A060), an existing sign. Why then that 13458 is proposed as
addition is beyond me.

As I wrote earlier, you need to analyse the meaning of signs. Only then can
you make informed decisions whether a sign is new. In many cases this requires
expert knowledge of hieratic and/or looking at signs in context in the
original hieratic documents. Two examples I spotted during superficial inspection:

* Consider 13482 for Moeller 257. If this is _not_ K4 (as it obviously is
according to Goedicke and the reading "XA" in Moeller) then you need to
explain why not. What reading, use or purpose would set this sign apart from
this or any other existing sign?

* I suspect all of us may have made wrong guesses based on appearances.  For
example, A051 for Moeller 27 (here proposed as a new sign 13452) may be wrong.
Goedicke associates this with A042 instead. Because A51 and A42 share some
uses, e.g. first-person ending, looking at one or two occurrences in hieratic
texts may not even suffice to decide which is which.

Are we aware that obtaining any certainty on such matters will require serious
effort? Then the next question is, is it worth it? Or does it do more harm
than good?

Mark-Jan

On Friday 16 Sep 2016 14:58:19 Deborah W. Anderson wrote:
> Dear list members,
> Michael has submitted a preliminary proposal for additional characters,
> building on what he circulated at the Cambridge meeting.
> The document is located at:
> http://www.unicode.org/L2/L2016/16250-n4741-moller-egyptian.pdf
>
> I have sent it on to the group at Mainz, and they will be able to comment on
> it by early October. I have also send it to Barbara Lüscher in Basel.
>
> The proposal document mentions: "Experts are needed to carefully check
> Vervloesem's suggested mappings against Nederhof's
> and Richmond's suggested mappings."
>
> To assist in this endeavor, I created a spreadsheet showing the suggested
> mappings by Vervloesem, Richmond, and Nederhof for the newly proposed
> characters, as well as other characters in Moeller.
>
> The Excel spreadsheet is available at:
> http://www.unicode.org/L2/L2016/16251-n4742-moller-mapping.xlsx
> FYI: Grey highlighting in the spreadsheet indicates the newly proposed
> characters for which Vervloesem, Richmond, and/or Nederhof have proposed a
> mapping to Gardiner (/Unicode).
> Yellow highlighting indicates newly proposed characters for which there is
> no proposed mapping.
>
> A document describing the spreadsheet is posted at:
> http://www.unicode.org/L2/L2016/16251-n4742-moller-mapping.pdf  . (This
> document contains the spreadsheet but in very tiny print.)
>
> Let me know if there are others whom you suggest I send this message to.
>
> With best wishes,
> Debbie
>
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160922/98e456aa/attachment.htm>