UTF-8 Unicode operators vs digraphs

[Walter Bright]

P.S. I am well aware that nobody agrees with me on this. It's me against the 
universe! Tally ho!

On 8/13/2026 6:17 PM, H. S. Teoh wrote:
> The problem isn't as simple as you imagine.  Some scripts have the
> *same* logical glyph look differently in different contexts, a *subset*
> of which looks like a subset of a different glyph in another language.

The mistake stems from thinking that a code point has semantic meaning. It does 
not. It gets its meaning from the context in which it is used. Like the text in 
a book. I have no trouble discerning a German letter a from an English letter a, 
for example.

> Take for example, the Cyrillic т.  The cursive form looks like this: m.
> To a native speaker, they are EXACTLY THE SAME LETTER, just differently
> styled.  The same way an English speaker sees the same letter whether
> the glyph is an upright M or a cursive M.  This is a variation that a
> different font face would give you.

Unicode should never have gotten into the font business. Fonts are selected by 
style sheets.


> Here's the problem: suppose Unicode does as you propose: represent the
> glyph m as a single codepoint.  Now you have a problem: т and m now must
> be represented as two different codepoints, even though they are EXACTLY
> THE SAME LETTER.  Because in English, t and m are different letters with
> different glyphs, so you can't have just a single codepoint for т and m.
> It makes no sense for an English word like "mama" to be represented the
> same way as Cyrillic "тата".  The only sane solution is to code the
> Cyrillic т/m and the English M/m differently.  Otherwise you still have
> the same problem that multiple codepoints map to the same logical
> character.

These are all problems resulting from assigning semantic information. People who 
print books do not have these problems, because individual letters have no 
semantic meaning.


> Another example is the Cyrillic п which in some fonts look like n.  You
> can't seriously be proposing that we represent the Cyrillic п with the
> same codepoint as the English n.  In Cyrillic, that's a stylistic
> difference, in English, that's a completely different glyph.

Yes, I am serious. There is no such thing as a Cyrillic n and an English n. 
There is only n and n.

> If you
> insist that the same glyph shapes must share the same codepoint, then
> the Greek π should be represented as the English n too, since п and π
> are equivalent,

This only becomes a problem when semantic meanings are assigned to glyphs.

> and in some fonts look identical.

The font selected is (or should be) irrelevant to Unicode.

> If you argue that
> since п and n are visually distinct shapes, they must be separate
> codepoints,

Yes.

> then I could also argue that English upright letters should
> be coded differently from italics, since they *are* visually distinct,
> and in many fonts involve actually different glyph shapes.

Italics are a creature of style sheets and should not be in Unicode. After all, 
are we talking a doubling of the number of code points in order to support italics?


> This doesn't even begin to scratch the surface of the issues that arise
> when you're dealing with languages like Arabic, where the same letter
> can appear in completely different shapes depending on where it occurs
> in a word, and in what context it's used.

I know nothing about Arabic, but it looks like this could be handled with the 
code that renders the Unicode code points. Don't get me started with the insane 
code points that reverse the direction of the text! (It's a fine way to inject 
malicious code into source code.)

> tl;dr: the issues involved are much more complex than what an English
> speaker may imagine.  Unicode isn't without its silly points and
> arguably backwards decisions, but given the complexity of the issue,
> it's doing not too bad.

It's incomprehensible, and grows worse every time the committee meets and adds 
more trinkets to it. Rikki added something like 5000 lines of code just to deal 
with C Unicode identifiers.