Re: Standaridized variation sequences for the Desert alphabet?

From: Michael Everson <everson_at_evertype.com>
Date: Sun, 26 Mar 2017 17:20:04 +0100

On 26 Mar 2017, at 16:45, Asmus Freytag <asmusf_at_ix.netcom.com> wrote:
>
> The priority in encoding has to be with allowing distinctions in modern texts, or distinctions that matter to modern users of historic writing systems. Beyond that, theoretical analysis of typographical evolution can give some interesting insight, but I would be in the camp that does not accord them a status as primary rationale for encoding decisions.

Our rationales are NOT ranked in the way you suggest. A variety of criteria are applied.

> Thus, critical need for contrasting use of the glyph distinctions would have to be established before it makes sense to discuss this further.

Precedent for such needs is well-established. Consider the Latin Extended-D block. Sometimes it is editorial preference, and that’s not even always universal.

> I see no principled objection to having a font choice result in a noticeable or structural glyph variation for only a few elements of an alphabet. We have handle-a vs. bowl-a as well as hook-g vs. loop-g in Latin, and fonts routinely select one or the other.

Well, Asmus, we encode a and ɑ as well as g and ɡ and ᵹ. And we do not consider ɑ and ɡ and ᵹ to be things that ought to be distinguished by variation selectors. (I am of course well aware of IPA usage.) Whole-font switching is well understood. But character origin has always been taken into account. Consider 2EBC ⺼ CJK RADICAL MEAT and 2E9D ⺝ CJK RADICAL MOON which are apparently really supposed to have identical glyphs, though we use an old-fashioned style in the charts for the former. (Yes, I am of course aware that there are other reasons for distinguishing these, but as far as glyphs go, even our standard distinguishes them artificially.)

> (It is only for usage outside normal text that the distinction between these forms matters).

What’s “normal” text? “Normal” text in Latin probably doesn’t use the characters from the Latin Extended-D block.

> While the Deseret forms are motivated by their pronunciation, I'm not necessarily convinced that the distinction has any practical significance that is in any way different than similar differences in derivation (e.g. for long s-s or long-s-z for German esszett).

One practical consequence of changing the chart glyphs now, for instance, would be that it would invalidate every existing Deseret font. Adding new characters would not.

> In fact, it would seem that if a Deseret text was encoded in one of the two systems, changing to a different font would have the attractive property of preserving the content of the text (while not preserving the appearance).

Changing to a different font in order to change one or two glyphs is a mechanism that we have actually rejected many times in the past. We have encoded variant and alternate characters for many scripts.

> This, in a nutshell, is the criterion for making something a font difference vs. an encoding distinction.

Character identity is not defined by any single criterion. Moreover, in Deseret, it is not the case that all texts which contain the diphthong /juː/ or /ɔɪ/ write it using EW 𐐧 or OI 𐐦. Many write them as Y + U 𐐏𐐋 and O + I 𐐄𐐆. So the choice is one of *spelling*, and spelling has always been a primary criterion for such decisions.

>> This is complicated by combining characters mostly identified by glyph, and the fact that while ä and aͤ may be the same character across time, there are people wanting to distinguish them in the same text today, and in both cases the theoretical falls to the practical. In this case, there are no combining character issues and there's nobody needing to use the two forms in the same text.
>
> huh?

He’s wrong there, as I pointed out. A text in German may write an older Clavieruͤbung in a citation alongside the normal spelling Klavierübung. The choice of spelling is key.

Michael Everson
Received on Sun Mar 26 2017 - 11:21:04 CDT

This archive was generated by hypermail 2.2.0 : Sun Mar 26 2017 - 11:21:04 CDT