Hi,

Is there anyway I can tell whether a particular uft8 code-point is
actually implemented in my terminal's current font?

For example, 0xe2 0x96 0x89 "▉" "Left Seven Eighths Block" is often
displayed as the i-don't-know-what-this-is glyph.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Harnden <[email protected]d> wrote:

Hi,

Is there anyway I can tell whether a particular uft8 code-point is
actually implemented in my terminal's current font?

The only way I know is to write a small program to
print it. That is what I did for various UTF-8
characters I like to use.

For example, 0xe2 0x96 0x89 "?" "Left Seven Eighths Block" is often
displayed as the i-don't-know-what-this-is glyph.

FWIW, 7/8 does not print for me on Linux and *BSD, but
on all systems Emacs will print it plus many more that
does not show up on xterm and other terms.

Thanks.

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Dec 2024 13:55:18 +0000, Richard Harnden wrote:

Is there anyway I can tell whether a particular uft8 code-point is
actually implemented in my terminal's current font?

You need some utility to dump out the font’s character-mapping table.

E.g. I wrote a Python script called “code_coverage” here <https://gitlab.com/ldo/python_freetype_examples/>, which will list
the code blocks defined for any specified font.

In this repo <https://gitlab.com/ldo/python_fontconfig_examples/>,
there is a tool called “coverage_list”. This will scan all the fonts
that fontconfig on your system knows about, to find those that cover a
given code block.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

UTF-8 is a text encoding, it’s not something that fonts have to support or even know about. Font encoding tables contain Unicode code points.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 7 Jul 2025 02:45:01 -0000 (UTC), I wrote:

Font encoding tables contain Unicode code points.

Actually no, I think they have to contain character codes. Not sure if determining the equivalence between composed and decomposed forms has to
be dealt with in OpenType or not.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/07/2025 01:29, Lawrence D'Oliveiro wrote:

On Mon, 7 Jul 2025 02:45:01 -0000 (UTC), I wrote:

Font encoding tables contain Unicode code points.

Actually no, I think they have to contain character codes. Not sure if determining the equivalence between composed and decomposed forms has to
be dealt with in OpenType or not.

Actually, I wanted to detect whether the font that happens to be in use
(which I can't control) has a particular glyph available. I have no
problem choosing a suitable font for myself.

I thought that maybe there'd be some kind of ioctl call.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 8 Jul 2025 10:20:49 +0100, Richard Harnden wrote:

Actually, I wanted to detect whether the font that happens to be in use (which I can't control) has a particular glyph available. I have no
problem choosing a suitable font for myself.

I thought that maybe there'd be some kind of ioctl call.

ioctl(2) calls are for device drivers, which are part of the kernel. What
you want is a call in the font APIs, which run entirely in userland.

On Linux systems, the two relevant subsystems would be Fontconfig and
FreeType. Fontconfig lets you query your system/user setup to find out
what fonts are available, and what their capabilities are. FreeType not
only takes care of low-level glyph rendering, it also lets you pry into
the innards of a particular font in more detail.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-08, Lawrence D'Oliveiro wrote:

On Tue, 8 Jul 2025 10:20:49 +0100, Richard Harnden wrote:

Actually, I wanted to detect whether the font that happens to be in use
(which I can't control) has a particular glyph available. I have no
problem choosing a suitable font for myself.

I thought that maybe there'd be some kind of ioctl call.

ioctl(2) calls are for device drivers, which are part of the kernel. What
you want is a call in the font APIs, which run entirely in userland.

On Linux systems, the two relevant subsystems would be Fontconfig and FreeType. Fontconfig lets you query your system/user setup to find out
what fonts are available, and what their capabilities are. FreeType not
only takes care of low-level glyph rendering, it also lets you pry into
the innards of a particular font in more detail.

In this case, wouldn't a more appropriate route be introducing a
terminal escape sequence for this (or is there one already in use
somewhere?).

What I wonder about is speed, how would this be made efficient, a
library caching responses? Because UCS isn't small...

--
Nuno Silva

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 10 Jul 2025 09:40:58 +0100, Nuno Silva wrote:

In this case, wouldn't a more appropriate route be introducing a
terminal escape sequence for this ...

Not sure why that’s relevant to issues of font query APIs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-10, Lawrence D'Oliveiro wrote:

On Thu, 10 Jul 2025 09:40:58 +0100, Nuno Silva wrote:

In this case, wouldn't a more appropriate route be introducing a
terminal escape sequence for this ...

Not sure why that’s relevant to issues of font query APIs.

Because the font rendering is a property of the terminal or terminal
emulator. I don't see a reason why a program running inside a terminal
device ought to access directly the rendering library, at least not
without some prior interaction with the terminal device confirming it's
ok to do so. (It could go via termcap/terminfo, but even then, what if a terminal emulator can use different ways to render fonts? Some dynamic
check might be necessary for that.)

If what you want is just a font query, go ahead. But if what you want is
a font query regarding what the terminal device is currently using, then
I'd say that ought to go via the terminal, and it seems to me that
escape sequences would be a much more fitting way to do that?

--
Nuno Silva

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11 Jul 2025 08:45:32 +0100, Nuno Silva wrote:

On 2025-07-10, Lawrence D'Oliveiro wrote:

On Thu, 10 Jul 2025 09:40:58 +0100, Nuno Silva wrote:

In this case, wouldn't a more appropriate route be introducing a
terminal escape sequence for this ...

Not sure why that’s relevant to issues of font query APIs.

Because the font rendering is a property of the terminal or terminal emulator.

The question was about a property of the font. The fact that the font
happens to be used by a terminal emulator is irrelevant.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)