From: Mark Jamsek <mark@jamsek.com>
Subject: Re: tog: don't embded utf8 glyphs in tog.c
To: Christian Weisgerber <naddy@mips.inka.de>, gameoftrees@openbsd.org
Date: Mon, 26 Sep 2022 02:26:10 +1000

On 22-09-25 06:19PM, Stefan Sperling wrote:
> 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.
> 

Oh, that's good to know! And, yes, if naddy wants to drop the
guillemets, then this might be a workable solution. Thanks, Stefan!

-- 
Mark Jamsek <fnc.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68