Am 07.07.2021 um 12:28 schrieb Bald Eagle:

>> ?? - That's quite a surprise there. The Alt+X input method in Word
>> (4-digit/letter hexadecimal code followed by Alt+X) is _specifically_
>> designed to enter Unicode codepoints using hexadecimal notation, and
>> `\uXXXX` is _specifically_ designed to specify Unicode codepoints using
>> hexadecimal notation. If they deviate, something is wrong.
>>
>> (At least for 4-digit/character codes. Those with more digits/letters
>> are another matter.)
> 
> Well, all I can say is that plug-and-chug with the "let me just use the \u
> method to implement the ALT-NNNN notation" didn't work.
> Here's the site which has those and other codepoints.
> https://altcodeunicode.com/alt-codes-miscellaneous-technical-symbols/

Ah, no - that's not what I meant. What I was talking about are the "NNNN 
Alt+X" codes.

As for the 4-digit "Alt+NNNN" codes, they're just the decimal equivalent 
of the `\uXXXX` hexadecimal codes.

Only the 3-or-fewer-digit codes are a genuine mess.

> It didn't make any sense to me that they were different, except for the fact
> that the original article recommended 2 different ways to invoke those glyphs -
> if the unicode method worked like that, then why even mention the ALT method.

The "ALT+NNNN" method has the advantage that it is a Windows feature 
that works in all programs, but the disadvantage that it uses decimal 
notation. The "NNNN Alt+X" method has the disadvantage that it is a 
proprietary feature that only works in MS Word, but the advantage that 
it uses hexadecimal notation.

The canonical notation to specify Unicode codepoints (i.e. character 
codes, if you will) in human-readable free-form text is "U+NNNN", where 

lower-case 'a' with grave accent). You rarely see Unicode codepoints 
specified by their decimal value.


>> Software that does a lot of text displaying (most notably browsers)
>> solve this problem by using a system of fallback fonts (none of which
>> cover all of Unicode individually, but in total they do) to display
>> characters that aren't available in the primary font of a web page.
> 
> Maybe for 4.0 or 5.0, text {} could take a _list_ of fonts, and start with the
> first entry, to do a similar thing.

I'd slap a "v4.1" label on that feature for now.

I'm also pondering a syntax to supply a list of custom objects to use as 
a character set.

> Also maybe a font-freak would decide that creating a (few) custom font(s) for
> POV-Ray would be a great project...  ;)

I don't know; in my book, v4.0 should bundle a handful of reasonably 
good run-of-the-mill free fonts cobbled together from the internerds. 
I'd argue for providing (1) a serif font, a sans-serif font and a 
monospace font, each covering the entire Latin/Cyrillic/Greek family of 
scripts; and (2) as many additional fonts as needed to cover the entire 
Base Multilingual Plane (16-bit subset of Unicode).

There are so many free fonts out there that it would be ridiculous to 
design yet another one from scratch. We'll also have OpenType fonts to 
choose from, as v4.0 will definitely support those as well.

I also wouldn't go too fancy in terms of italics or boldface fonts, as I 
expect v4.0 to provide means to auto-generate oblique and bold fonts 
from regular ones, and also to provide easy access to fonts installed in 
the system. (At least for Windows, the latter is a given.)


(What we _could_ do is create "watered-down" versions of existing fonts, 
stripping away any hinting information, to save memory; we don't need 
our fonts to be hinted, as we're not rasterizing them in the traditional 
sense. But the fact that we could doesn't necessarily mean we should.)

Post a reply to this message