<div dir="ltr">
<p class="gmail-MsoNormal"><span lang="EN-GB">May I dare
to suggest another approach to the problem, suggesting a compromise solution
that could be at the same time easy and efficient and that could satisfy more
or less everyone?</span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Let’s start
from the assumption that at some point we will need a common archive or
database listing all the attested groups.</span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">This is
something that *will have to be done* at some point, whether you want to use 0
or 100 control characters, because groups will need to be inserted as
precomposed glyphs into the fonts to be displayed correctly, and the people who
will design the fonts will need a list of the groups they have to draw.</span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">This is a
must, such a reference list must be created at some point, whatever solution
for grouping will be decided.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">And I think
it should not be too difficult to set up something like this, and one could
think to an online database of reference, where a unified and generally
recognized list of reference with all the attested groups will be freely available.</span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">The list
will give information about the individual signs composing each group, and
about their spatial organization within the group itself.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">This can be
done by just writing for each group the list of signs composing it with the
relevant MdC operators.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Groups, or
sequences of texts could be searched also on the basis of their spatial
organization</span></p><p class="gmail-MsoNormal"><span lang="EN-GB"><br></span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Now, as for
the Unicode:</span></p><div></div><p></p>
<p class="gmail-MsoNormal">Yes about
control characters, but:</p>
<p class="gmail-MsoNormal"><span lang="EN-GB">What about
deciding that:</span></p><div></div><p></p>
<p class="gmail-MsoNormal">a)
sequences of signs that can be combined into only one attested groups (as many
Ramesside groups) will be rendered *only* with plain ligatures, without control
characters.</p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">The
advantages would be:</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpFirst" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">1)
complex groups could be rendered without the need of recursivity or complex
nested control characters, because it is logic to assume that the more complex
a group is, and the less likely it is that its composing signs will appear in
more than one spatial organization. So they can be dealt with plain ligatures
without the risk of ambiguity.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">2)
Because of the point above, this will probably solve the problem of nesting control
characters, or at least it will greatly reduce it. I doubt that there are many
sequences of signs with nesting features that can be combined in multiple
different groups.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">3)
If for some reason the group should not be rendered correctly by the browser/text
editor, it would not be a problem because the signs composing the group will be
displayed ungrouped, as plain text, without broken control characters among
them. The text would still be readable and usable</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpLast" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">4)
The syntax of the signs will not be affected by control characters, because
control characters will not be involved. The ligatures will be triggered jsut
by imputing the sign in their correct reading order.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Note that
there would not be any loss of information, because these groups would be unique
spatial compositions, i.e. the spatial organization of the signs within the
group will be implicit in the ligature itself (which could be named with the
string of signs + MdC operators describing the group), and will be available in
the database mentioned above. As long as the database will be used as a
reference for the creation of fonts, the ligature needed for the group will be
present and therefore the group itself will be displayed correctly.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">b)
sequences of signs that can be combined into more than one different group will
be rendered differently. In particular, one, the most common group (or the one
with the most complex organization?) will be rendered with a plain ligature.
Any other group will be rendered with control characters (whatever control
characters you prefer).</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">So for
instance the sequence: owl G17 + arm D36</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">The basic
group, rendered with the plain ligature could be the owl above the arm, that
will be automatically created by inputting owl + arm.<br>
Then there could be a secondary group, the arm across the owl (I know this is
already encoded as a distinct character, just for the sake of the example),
that will be created with a control character, so e.g. by inputting owl +
control character + arm.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">The
advantages would be:</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpFirst" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">5)
even if a text editor/browser will not be able to correctly render control
characters, there will always be one basic group with a plain ligature that can
be rendered (whether as a group or as a sequence of signs) without broken
control characters popping out here and there</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">6)
you can have as many variants as you want, and therefore the precision of the
spatial distribution will be preserved, because the less common spatial
organizations (i.e. the less common groups) will be distinguished by the basic
one through the use of control characters. If you don’t need spatial precision,
you can just use the plain basic ligature, if you want to be precise you can
select the specific organization you need.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">7)
short sequences of signs are more likely to have more than one possible spatial
organization, i.e. short sequences of signs are more likely to be composed in
more than one different group. Still, groups built from short sequences of
signs are much less likely to require features like nested control characters,
recursivity, etc., so it will probably be possible to deal with them with just
very simple sequences of control characters.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpLast" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">8)
if a new group for sequence of signs that until now would be combined into only
one group should be discovered, it could just be added to the list and rendered
with a control characters</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span>Because of
the point 7) here above, and because of the fact that complex groups will
likely be unique and therefore dealt with plain ligatures (point 1) above), it
is quite likely that this system could reduce (if not even solve) the problem
of the multiplication and nesting of too many control characters.</p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Now it
seems to me such a system would satisfy everyone’s needs and deal with a lot of
problems:</span></p>
<p class="gmail-MsoListParagraphCxSpFirst" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">searchability
will be granted because groups will be dealt mainly with plain ligatures, and
therefore the phonetic order can be respected in imputing the single sings</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">spatial
information will be preserved, because it will be either encoded in the
ligature itself, or in the variants using control characters. And will in any
case case be present in the basic database (that *has to be created* anyway).</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">The
system will allow to use control characters in a efficient way, that won’t
require tens of them, both because unique groups will be rendered with plain
ligatures, and because those groups that will must likely need control
characters will be relatively simple, based on short sequences of signs. This,
I think, is more in line with the basic principles of Unicode.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">Note
that the system is different from Bob’s original simplified Egyptian proposal,
as it suggests to use plain ligatures for all the sequences of signs that can
be combined in only one group, and for one of the possible groups for those
sequences that can be combined in more than one group.</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">At the same time the
system is relatively similar to how the emoji variants work, and to what we
were discussion with some of you during the workshop.</span></p><p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">- The use of plain ligatures for the most common/basic forms of the groups would solve the Dd problem pointed out by Michael: no need to chose between up/down or corner control character, because the pain ligature can be used</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpMiddle" style="margin-left:53pt"><span lang="EN-GB">-<span style="font-size:7pt;font-family:'times new roman'">
</span></span><span lang="EN-GB">It
would be very easy to create input methods for such a system</span></p><div></div><p></p>
<p class="gmail-MsoListParagraphCxSpLast" style="margin-left:53pt"><br></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Now, as we
are here to reach an agreement on a system that can work.</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">It seems to
me that such a system would solve a lot of the issues that are being discussed.<br>
So what do you think about it?</span></p><div></div><p></p>
<p class="gmail-MsoNormal"><span lang="EN-GB"> </span></p>
<p class="gmail-MsoNormal"><span lang="EN-GB">Marwan</span></p><div></div><p></p>
</div>