clipka <ano### [at] anonymousorg> wrote:

> Noooooooo - they don't have much in terms of support for non-ASCII
> characters at all, let alone Unicode.

Yesssssssssssssss - because I haven't dissected and designed fonts since I was
doing it in 8-bit bitmap fonts on a VIC-20....   :P


> ?? - 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/

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.
Unless of course some are in decimal and the others are in hex (or oct)
(Can the alt-method be used with hex???)


> No surprise there. Providing glyphs for all Unicode codepoints defined
> so far would be a ton of work (remember, you'd want to define all of
> them in the same style; and you'd need to know at least some basics
> about the typography of each and every script in the world to get it
> right; for example, a lot of fonts get the Euro sign typographically
> wrong, and the fonts that provide an uppercase variant of the German
> sz-ligature often get that one wrong as well) and also require tons of
> storage space. So fonts typically cater to a particular set of
> languages, and leave all others empty.

Yes, "Noto" fonts and "code2000" were referenced in my readings, as well the
fact that there's SO much information covered by the unicode standard that you
can't fit it all into a single font file, and it has to be split.

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

> There are scenarios though where perfectly valid fonts would end up
> garbled by POV-Ray. Fortunately they seem to be rare with high-quality
> fonts.

We work with what we have, right?  And for the moment, everything that I need is
moving along, so I will consider that and some additional learning under my belt
to be a win.  :)

Post a reply to this message