From Newsgroup: comp.unix.shell

On 2024-12-20, Richard Harnden wrote:

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 "rue" "Left Seven Eighths Block" is often displayed as the i-don't-know-what-this-is glyph.

Thanks.

There is ftdump, e.g.:

$ ftdump -C testfile.ttf
...
0x2589 => 539 leftSevenEighthsBlock
...

(It's part of the freetype2-demos package on my system)

Tavis
--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

UTF-8 is a text encoding, itrCOs not something that fonts have to support or even know about. Font encoding tables contain Unicode code points.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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

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.

I don't think I said anything that contradicts that...?

If you're asking for a tool to print the codepoint, I would just use
uconv, e.g. uconv -f utf-8 -x 'any-hex/unicode'.

Tavis.
--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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 thatrCOs relevant to issues of font query APIs.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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 thatrCOs 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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 thatrCOs 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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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 thatrCOs 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.

Maybe.

A terminal emulator, or some code that it uses, has to know, at some
level, whether it's able to render a given character in the font it's
currently using. It's easy to imagine that a terminal emulator might
provide a way to query that information. I don't know whether any
actually do so.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2