[Egyptian] Some general considerations

Mon Jul 25 11:49:55 BST 2016

On Mon, Jul 25, 2016 at 12:11 PM, Stéphane polis <s.polis at ulg.ac.be> wrote:

> Yes, Marwarn, I agree that we should indeed stop here.
>
> The vertical text that you produce is nothing even close to what could
> have been an ancient Egyptian vertical text, even less a ’nice example’ (or
> was it ironic?).
>

Stéphane, I am sorry to disappoint you, but you are not an ancient Egyptian
scribe and I am sorry to disappoint you, but your perception of egyptian
writing is not the "truth".

Your aim is not to *produce* an ancient egyptian text.

The aim is, or should be, to analyze what ancient Egyptian wrote in a way
to transcribe what ancient Egyptian wrote in an precise and efficient way.
Not to determine what according to some abstract concept is the "true
nature" of a text and trying to encode this "true nature".

And the aim of that "vertical rendition" was not to produce a "real"
ancient egyptian vertical text. it was to explicit and explain one specific
step (and its advantages) the inputting procedure and approach that i am
suggesting.

And my approach allows to transcribe it as precisely as yours. But more
efficiently.
Perhaps you should try to understand how it works (because clearly you
don't) before stating what is possible and what is not.
And perhaps you should try to understand a bit better how fonts, ligatures,
layouts, and unicode in general work because you seem to believe that is
possible/practical to do things that are actually impossible/impractical
(stacking in hieroglyphs, using tens of control characters to display 3
hieroglyphs), and you seem to believe that is impossible/impractical to do
things that are instead very possible/practical (as coding spatial
information in ligatures - you can give names to ligature, so you can call
your p*w-ligature "p*w" and you have your spatial information that you can
retrieve from your font whenever you want)

Let alone your comments about non-western non-latin scripts or your tw/wt
example (which is a non-existing problem that has *already* been solved in
the *current* current unicode set, where t&w is *already* coded as an
independent character. So if you want to display tw = /tw/ you just input t
+ w, if you want to display wt = /wt/ you just input w + t, and if you want
to display t&w = /wt/-/tw/ leaving the ambiguity of the pronunciation you
just input the unicode character tw (u13172) which was probably encoded
*exactly* for this purpose - pretty smart idea btw… - you should find some
other common examples that cannot be solved in this very easy and practical
way to explain why coding position is important, because arguing for a
proposal on the basis of a problem that has *already* been solved in the
current unicode set, well.. and btw, if you knew how ligatures work, you
would see that in the case of the wt/tw problem it is actually possible to
code *more* information, about the spatial organization *AND* about the
reading order of the signs, by using ligatures, than by using control
characters.. but I assume you are not really interested in that right?)

So well..

All the best with your work with ancient Egyptian as well

Marwan

> Le 24 juil. 2016 à 18:15, Marwan Kilani <odusseus at gmail.com> a écrit :
>
> Just one comment:
>
> And all the parallels from other scripts are pointless (and admittedly
>> funny in the framework of this discussion), since none of these scripts are
>> based on a quadratic structure that is close in any respect to Egyptian.
>>
>
> Funny to read such a comment while at that meeting in Cambridge a Japanese
> linguist and Egyptologist explained, by referring to scientific
> publications, that Japanese (and chinese and korean) are indeed based on
> quadratic structures that are indeed very close in many respect to Egyptian.
>
> There were many things that could be said as a reply to your email, but
> let be honest: with these premises, it won't make any sense.
>
> p.s.:
> No, actually, i am going to add something:
> Look what happens (image 1 below) if you cut your ramesside line in small
> columns (which is just a way of analyzing the text, as it is yours taking
> them as groups, but as we are not egyptians it is not "truth", it is not
> and don't want to be the "true nature of the text"), I was saying: Look
> what happens (image 1 below) if you cut your ramesside line in small
> columns and you put them one under the other..
>
> Such a nice example of Egyptian vertical text, isn't it? :-)
>
> And now, count how many groups you would need to compose such a text with
> a vertical font within a vertical layout.
> You can see the result in the second image: the groups you will need are
> marked in green: 7 groups. That's all.
> Note that you will not need to combine the D snake and the ns tongue as a
> group with the following signs, because with a vertical font you could put
> the baseline of the sign under its "horizontal" bit, and you could consider
> the tail as hanging below the baseline, as it is for the latin letters "q",
> "g" "p" and so on. And consider that the "30" is already a single character
> in unicode (as the t&w, btw.. so i would suggest you to find a more
> relevant example to argue for the importance of the relative position of
> signs..)
>
> So if you use my way of interpreting ramesside texts as short vertical
> strings of texts within an main horizontal layout, you would just need 7
> (sic!!!), in general very basic, groups to display it correctly. All the
> other signs could just be inputted one after the other, without control
> characters, without ligatures, without anything, within short columns one
> next to the other. And you could just use basic layout algorithm to make
> them with the space in a nice way (you know, like when you expand or to
> squeeze the letters within a line to make you text look better? exactly the
> same thing, but vertically).
>
> Instead, with your way of interpreting ramesside writing, which assumes
> that every "tall group" is a real "group" that need to be built and
> displayed within a single purely horizontal layout, and with your system of
> control characters, you would need 15 (sic!!!) groups, many of them very
> rare in not even unique, and you would need tens of control characters
> nested one into the other to correctly build and correctly display each of
> them.
>
> I really wonder which approach would be more efficient, more economic and
> more easily implemented..
>
> Image 1:
>
> <image_1.png>
>
>
>
> Image 2:
> <image_2.png>
>
>
>
> _______________________________________________
> 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/20160725/7ec86340/attachment.htm>