[Egyptian] On "A system of control characters for Ancient Egyptian hieroglyphic text" (2016-07-23)

[Marwan Kilani]

"For example take Dd=f, with cobra + hand + viper. Sometimes you see
hand:viper clearly entirely
inside the bounding box of the cobra. Sometimes you see the hand in the
cobra, while the viper
is entirely below, with the tail of the viper extending below the tip of
the tail of the cobra. Sometimes,
the head of the viper is inside the bounding box of the cobra, while the
tail of the viper extends
below the tail of the cobra."

Sorry, to go back to the same thing, but.. what is the practical need of
encoding such a distinction?

having the inside or outside the cobra has (I guess I should say "as far as
I know") no meaning and no importance whatsoever. There is no linguistic,
no semantic, nothing..

it is just a graphical variant, a calligraphic choice of the scribe.

Unicode should be about standardized transcriptions, not about paleographic
details. The important thing here is that the "f" comes after "D+d". That's
all.
Why should we encode such calligraphic variants in the first place?

What is the utility of that?

Marwan




On Thu, Jul 28, 2016 at 5:03 PM, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk>
wrote:

> Dear Stéphane,
>
> > >> ***** 2. A single ‘scope operator’ ****
> > >>
> > >> I mean here an operator that marks one sign as the scope of all the
> insertions around. Let’s say we use ‘!’ as a scope marker, then the
> examples above would become:
> > >>
> > >> D! [insert_bottom_left] d
> > >> t [insert_bottom_left] A!
> > >> w! [insert_bottom_left] t [insert_top_right] D54
> > >>
> > >> The graphemic order is explicit and the reading order is respected.
> > >
> > > I don't think this works because what is inserted is a group in
> general, and then where do you
> > > place the '!’ ?
> >
> > Sorry, I’m tired, slow, and not sure I understand… Could you give an
> example of what you mean here?
>
> Sorry, I misread the first time around. The way I understand it now, it
> might be an unambiguous syntax,
> at least if we rule out groups with more than one core_group in which to
> insert. I have an uneasy feeling
> though about the interpretation of the [insert_bottom_left] depending on
> some mark somewhere else
> to the left or to the right. And would it be possible to have no marked
> element at all, and what would
> that mean? (Defaulting to the left-most or right-most element?)
>
> > > One option might be to use 'insert-into-the-middle' for the cobra
> combination. In the
> > > current syntax, 'insert-into-the-middle' cannot be combined with some
> other
> > > insertion-into-a-corner, but this may not be needed. Because for
> 'insert-into-the-middle'
> > > the inserted sign comes after the main sign, the special case of the
> cobra would be solved,
> > > with respect to reading order.
> >
> > This could be a practical solution of course, but this would stretch
> quite a bit the definition of the ‘insert-into-the-middle’ (as you say
> below actually) for no good reason (except to solve a reading issue), and
> would lead one to use ‘insert-into-the-middle’ in unprincipled way. I mean,
> what would be the rationale for choosing ‘bottom-left’ and ‘middle’? The
> only one is a graphic one, and I’m not sure that a reading motivation is
> good. But an option to keep in mind of course.
>
> Yes, I see problems there. As Michael reminded us, the font designer needs
> instructions to know
> what to do. If the instructions are few, this is easier than if there are
> many instructions, with many
> special rules and exceptions. I also would hope to keep open the
> possibility of doing the rendering
> totally automatically, certainly outside the context of OpenType, in
> applications where general-purpose
> programming languages can be used. Having an encoding where every
> primitive has a simple
> procedural interpretation (or, as simple as possible) would therefore be a
> tremendous advantage.
>
> And as you suggested, the encoder needs to know how to encode. Having many
> special cases
> makes it more difficult to decide.
>
> There are trade-offs, as many times before.
>
> > Nope, that’s for sure. For the cases that you mention, I wonder whether
> we should not collect more evidence and prepare a later addition with
> ‘insert-top’ and ‘insert-bottom’ based on this (for insert bottom, one can
> think of the combination of ‘pt (sky)’ with several signs, etc.), rather
> than to stretch the definition of ‘insert-middle’. But this remains
> certainly an open debate.
>
> We could keep this open. My working hypothesis is that where one would
> feel the need for insert-top or insert-bottom
> there is usually some case to be made for either vertical+kerning or
> insert-inside, which would avoid having more primitives.
> After having gone through a fair number of original inscriptions, I have
> seen few exceptions. But by all means we
> should keep looking and perhaps our views might change.
>
> > As a general point: mixing insertion and kerning (or join) for a single
> phenomenon annoys me a bit to be honest. And I think this is also you view,
> right?
>
> I would agree it is best to have sharp distinctions where sharp
> distinctions can be made. This said, we
> are dealing with an extraordinarily complex writing system. We need not be
> under the illusion there is only
> one correct way to encode a text, at least if we are working from an
> original inscription. (If we take JSesh as
> input, the choices have been made already.)
>
> For example take Dd=f, with cobra + hand + viper. Sometimes you see
> hand:viper clearly entirely
> inside the bounding box of the cobra. Sometimes you see the hand in the
> cobra, while the viper
> is entirely below, with the tail of the viper extending below the tip of
> the tail of the cobra. Sometimes,
> the head of the viper is inside the bounding box of the cobra, while the
> tail of the viper extends
> below the tail of the cobra.
> So how should this then be encoded?
> (d insert-left-corner cobra) :[fit] f
> or
> (d:f)  insert-left-corner cobra
> ?
> My view is that both should be allowable. [Modulo the notation, which
> might or might not be in sync
> with reading order.] Would you agree?
>
> Best regards,
>  Mark-Jan
>
> _______________________________________________
> 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/20160730/f8333cf0/attachment.htm>