On Sun, Sep 17, 2017 at 3:30 PM, Janne Heß <jannehess_AT_gmail.com> wrote:
> What I also found is that several unicode combine characters aren't
> detected properly. For example, a female black police officer (rarely
> used, but exists) is rendered as three different emojis (color, gender
> and police officer). I assume st doesn't does this processing, but which
> library does it so I can report a bug?
Agree that combiners probably should be supported if they could be.
Both terminals and command-line tools (all of them) rely heavily on
wcwidth() to do the right thing (and all seem to have collectively
decided to revert to width 1 if wcwidth() returns -1). On my system,
wcwidth() can't deal with combiners at all (wcwidth accepts an
unsigned long). (that is, it can't deal with more than 4 bytes, 'st'
could fake it, but then the underlying program (shell, mux, screen,
etc) would still break. That is, 'st' could reserve the space, but
when a shell-line edit is ready to happen, the shell gets confused and
editing/cursor is off by one for each emoji that appears. This
because the shell itself isn't expecting a double-width character. On
output alone (no edit) it sure looks nice. Once editing is required,
one quickly tires of this mismatch.
>
> On 09/17/2017 09:03 PM, ACE wrote:
>> On 09/17, Janne Heß wrote:
>>> It looks like the crash is caused by the font.
>>> Switching from noto emoji to emoji one fixes the crash. I'll try looking
>>> into the grid escaping bug...
>>
Similarly, if a character has a mis-match between wcwidth() and the
font's actual size for it (VERY common in Emoji), but also true for
some non-emoji characters, the overlap is going to just happen. The
character breaks out of grid, and over paints part or all of the
following character's grid-space. With the font Noto Sans Symbols,
this happens with Place of Interest:⌘(not actually an emoji). It
would be possible to clear out a new glyph's grid prior to painting
it, but doing so slows things down everywhere for the occasional
misbehaving over-wide glyph (and in some cases looks uglier than just
letting the overlap remain).
I noted in a previous thread [
https://lists.suckless.org/dev/1709/32306.html ] that wcwidth was
recently fixed/updated in Linux's glibc: [
https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html ].
Ultimately, this (and recompiling everything that links it statically)
is the RIGHT way to fix all of these issues.
For the future person finding this via web search: Graphical Web
Browsers do not have this issue because they are not fixed grid
systems. They are asking for the width of EACH individual glyph, and
painting it with the appropriate space. They are also not sharing
with underlying programs that expect a grid system or expect to be
able to rely on wcwidth() to know what is shown on the screen. Of
course, web browsers also have the additional functionality to deal
with full-color emoji fonts - which seems way beyond scope of any
terminal built to have less suck.
Thank you,
Gary Allen
Received on Mon Sep 18 2017 - 01:01:58 CEST