UTF-8 Unicode operators vs digraphs

Dlighted test at example.com
Thu Aug 13 07:20:08 UTC 2026


On Wednesday, 12 August 2026 at 19:50:18 UTC, Walter Bright wrote:
> I suppose one could adapt their code editor to display != as ≠, 
> but then aligned columns may not work well.
> So they stretch out ≠ to be two characters wide? Code editors 
> tend to use monospace fonts.

Today a monospace font is often not actually monospaced. The font 
determines the width of each letter. And it can use an opentype 
ligature glyph that is simply two columns wide. It also means 
that it does not break up the ligature when it reaches the end of 
the screen but puts the whole operator >= on the next line when 
visual line wrapping is enabled. I checked in the Kate text 
editor with Fira Code just now.

> Another one of my major gripes about Unicode - characters that 
> render identically but are completely different.

> Putting the notion of normalized Unicode into Unicode was one 
> of the most execrable decisions ever.

I hope I don't misunderstand or sound rude.
It is unavoidable for letters from different scripts to look the 
same in some fonts when supporting many scripts.
However the problem is far older than Unicode. I (i) and l (L) in 
English fonts of the last centuries are often stylized to look 
the same.
Historically capital I (i) and capital J (j) were the same letter 
in handwriting and old fonts because j was merely a calligraphic 
variant of i (and often only for lowercase) used in front of 
vocals just like "r rotunda" (ꝛ) and r. It wasn't supposed to 
change pronunciation but indicate it. It was not supposed to be 
an own letter.
In fact some alphabetic enumerations in German books still skip 
the letter j! a) b) c) d) e) f) g) h) i) k)
Here's a picture of it:
https://www.praxis-foerderdiagnostik.de/wp-content/uploads/2021/02/neu_Klammerreg_Ue1-scaled.jpg
There are also many names with I or J variants that are actually 
the same name! Spoken the same way.
I guess you'd have to _normalize_ them to find out.

 From my understanding normalization does not apply to ≥. It 
doesn't change when normalized to any representation because it 
has a fixed unique representation.


More information about the Digitalmars-d mailing list