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