"GOT", but the "O" is a cute, smiling sun Index | Thread

Stefan Sperling <stsp@stsp.name>
Re: tog: don't embded utf8 glyphs in tog.c
Mark Jamsek <mark@jamsek.com>
Christian Weisgerber <naddy@mips.inka.de>, gameoftrees@openbsd.org
Sun, 25 Sep 2022 18:19:56 +0200

Download raw body.

On Mon, Sep 26, 2022 at 01:23:47AM +1000, Mark Jamsek wrote:
> On 22-09-24 03:17PM, Christian Weisgerber wrote:
> > Mark Jamsek:
> > 
> > > This fixes the problem stsp reported of making utf8 enabled editors
> > > necessary to browse the code.
> > > 
> > > I also found prettier single guillemets to wrap the control chars.
> > 
> > What are the chances of a font not containing those characters and
> > presenting the user with some replacement box?
> I'm not sure how to get a reliable measure on that, tbh, but will
> investigate further. According to stsp, gnome and xfce support it out of
> the box, I'll learn which other desktop environments also support it by
> default. I can't recall if base xterm did. A cursory search produced
> a couple lists of fonts that apparently support the glyph[0,1]. The
> lists, however, are neither exhaustive nor authoritative; for example,
> spleen also supports it, but spleen is not mentioned. If it were
> a browser app, apparently 95% of users could view it[2].
> > Why not simply use <...> everywhere?
> This is what we do if the user has not set a UTF-8 locale.  We also do
> this with borders, for example, and use one glyph if UTF-8 is enabled
> and another if not.

These borders are actually VT100-related, not UTF-8.

The ACS_VLINE and ACS_HLINE macros are defined by ncurses and can be
passed to routines like addstr() to make them appear on the terminal.
In fact, ACS_VLINE and ACS_HLINE look the same in a UTF-8 locale xterm
and in a C locale xterm.

The reason that our use of ACS_VLINE and ACS_HLINE is only enabled in
the UTF-8 locale is that those symbols don't look as they should on the
OpenBSD glass console. The font the console is using is very limited.
People usually leave UTF-8 disabled on the console, so the UTF-8 locale
check just works around the glass console font limitation.

There are ACS macros defined in ncurses.h which we could probably use
for the help view's purposes if we really wanted to avoid UTF-8.
For example, ACS_LEQUAL and ACS_GEQUAL.
I don't mind using UTF-8 for this, but if naddy has concerns then
the ACS macros might provide an alternative we could consider.
You can't write these ACS macros to a file and read them back, though.
They need to be passed directly into ncurses function calls.