Could Unicode deliver the level of paleographic detail needed for encoding ancient Egyptian hieroglyphs?

[James Kass]

On 2024-03-06 4:30 PM, Peter Constable via Unicode wrote:
> There is a further misconception here: glyph outlines are defined as
> Bezier splines, which get represented as a sequence of (x,y) Cartesian
> coordinates for Bezier control points. However, some glyph IDs can
> describe the outline by reference to other glyph IDs - these are
> referred to as composite glyph descriptions. A composite glyph
> description can apply a 2x2 matrix for an affine transformation.
> ("Affine" means that parallel lines remain parallel.) The 2x2 matrix can
>   be used to specify a rotation. So, while the outline of a hieroglyph
> might involve a large number of control points, to have a separate glyph
>   that is a rotation of that hieroglyph requires only a small amount of
> additional data.
>
> Of course, if there were 10,000 rotational variants, that would add a
> lot of data. But the statement from that document didn't suggest a large
>   number of rotational variants. It makes a generic statement, "Rotations
>   entail...", which suggests one or more additional variants. Since it is
>   commenting on L2/21-248 which proposed three rotational variants
> (possibly extended in the future to 7), it has 3 in mind, not 10,000.
> Adding 3 rotational variants using composite glyph descriptions would be
>   a fairly small increase in data.
>
>
> (I'm commenting here only on the OpenType font format, not on the
> encoding of rotational variants of hieroglyphs.)
Exactly.  I'm commenting here only on fine rotation for any glyph 
because the Egyptologists apparently neither want nor need such 
granularity.  But the concept of handling any glyph was brought up by 
the OP.  If anybody wanted such a feature, it would already have been 
accomplished.  And it would most likely have been relegated to rich-text.

Adding even only three rotational variants to a large font, like a CJK 
font, would be non-trivial.  Adding the gamut of possible degrees to a 
font would be absurd.  So any fine rotation support would of necessity 
be handled by the font engine instead of the font file in this scenario.

My apologies for jumping into this rabbit hole; I should have exercised 
a little self-restraint.