Voidrice: Without proper default fonts, emojis crash st

[LukeSmithxyz]

On some systems, the terminal, st will crash when trying to render emojis and other unique unicode characters. This problem generally arises when users lack emoji fonts or a bad emoji font is default; at least, that seems to be the cause.

The font packages below are installed by LARBS to give pretty much full unicode overage. If you are having terminal crashes when you clone and run my dotfiles, you will want to install these. That will in most cases solve the problem:

ttf-linux-libertine # probably not actually needed, only aesthetic
ttf-inconsolata # the monospace font
ttf-emojione
ttf-symbola

You might also want to install noto-fonts; I don't think that's necessary, but I have it on my machine.

If the problem persists, you should probably explicitly state what fonts to use. Here is the LARBS fontconfig file, which with these fonts seems to avoid this crash.

I'm making this issue here because there are at least a half dozen other issues on my repos about this. I'm aware of the issue, but the original cause might be something out of my control or ken.

I suspect it has something to do with how st or one of its libraries handles fontconfig errors. If that problem persists, I might drop fontconfig usage by st and have it manually specify fonts.

[Peter-JanGootzen]

I personally do not use your configs, but I was also having this exact issue after receiving an emoji in the subject of an email...
What fixed it for me was only to install https://github.com/eosrei/twemoji-color-font. The normal emojione font did not work for me.

This problem seems to be a recurring one for st in the last few years.
https://dev.suckless.narkive.com/Q3qjglud/st-emojis

[moham96]

I have all these fonts installed and the LARBS fontconfig file, and i still get crashes from time to time when running cat .config/emoji, sometimes it crashes instantly and sometimes it crashes when i scroll back to the first lines of the file

[kiprasmel]

Also related

• https://github.com/LukeSmithxyz/LARBS/issues/119 - exact same issue, still investigating if there's a work-around / fix available.
• https://github.com/LukeSmithxyz/st/issues/37

By the way - I'm experiencing this issue and the provided solutions, sadly, do not help..

[kiprasmel]

Update - I finally made it work for myself with some HUGE help from @pat-s!

Everything was discussed in the https://github.com/LukeSmithxyz/LARBS/issues/119 issue, but since Luke made LARBS read-only, the issue's no longer there...

I'm discussing the solution with @pat-s right now - we'll will provide it very soon - hopefully it works not only for us, but for all of you!

[pat-s]

This post should serve as a summary for what has been discussed in https://github.com/LukeSmithxyz/LARBS/issues/119 and via mail between @sarpik and me.

Introduction

The reason why st is crashing is that it tries to use an emoji font as fallback that provides colored emojis (which st cannot handle).

A "fallback" font is used when a specific glyph is requested that is not found within the font used by st.

The default font used by st is the default "monospace" font on the system OR the one set in .Xresources or .Xdefaults.
The latter will override whats being specified as the default monospace font in .config/fonts/fonts.conf.

LARBS installs ttf-symbola by default which is being used as the fallback font for emojis unless there is a different colored emoji font installed.
The exact order of the fallback fonts is not always clear.
However, for people experiencing st crashes this "order problem" of emoji fonts is (almost) always the reason.

Possible reasons for crashes

• A font with colored emojis is specified as the st font in .Xresources
• The first fallback font for emojis is a font with colored emoji support

Solutions

• Choose a different monospace font in .Xresources
• Delete all colorful emoji fonts AND their symlinks in /etc/fonts/conf.d and /etc/fonts/conf.d
• double check if ttf-symbola is installed

How to still get colored emoji support without st crashing

This post shows how to set noto-fonts-emoji as the default fallback font for any kind of font family on the system.
If you follow this post, you will have colored emoji support.
Now to prevent st from crashing, you need to remove the part for the "monospace" family

<match target="pattern">
  <test name="family"><string>monospace</string></test>
  <edit name="family" mode="append"><string>Noto Color Emoji</string></edit>
</match>

and the block which blocks ttf-symbola as a possible fallback font

    <!-- Block Symbola from the list of fallback fonts. -->
    <selectfont>
        <rejectfont>
            <pattern>
                <patelt name="family">
                    <string>Symbola</string>
                </patelt>
            </pattern>
        </rejectfont>
    </selectfont>

and the part which specifies using noto-fonts-emoji over ttf-symbola

<match target="pattern">
  <test qual="any" name="family"><string>Symbola</string></test>
   <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit>
</match>

There may be different approaches of how to get colorful emojis without st crashes and with different emoji fonts. However, I am happy to finally have a working solution and I am not keen on changing anything of the setup in the near future.

[LukeSmithxyz]

@pat-s
Now if that is true, do you think you could create a PR that will avoid the problem by editing the fontconfig file?

Frankly speaking I just don't understand the logic of fontconfig so if you've done the research, it might be better for you to give it a try. As long as st can render what monospace emojis exist and won't crash, it's fine with me. I would like to avoid adding dependencies though (including noto emojis), but if we have to, I can.

[pat-s]

I guess the most robust approach would be to add

  <!-- This sets Symbola as the final fallback font for the monospace font family. -->
  <match target="pattern">
        <test name="family"><string>monospace</string></test>
        <edit name="family" mode="append"><string>Symbola</string></edit>
    </match>

to .config/fonts/fonts.conf to hardcode the fallback font for the default monospace font to "Symbola". See #293

[omcho420]

This still happens to me even with the latest update of LARBS and having #293?

[pat-s]

• Have you run fc-cache -fv?
• Any font in /etc/fonts/conf.d or /etc/fonts/conf.d that could possible override the setting in .confing/fonts/fonts.conf (even though the latter should be higher prio)
• ttf-symbola installed?
• any font specified in .Xresources that specify a different font for _st_?

[omcho420]

• Yeah
• I don't think so but here's a screenshot
  [ https://i.imgur.com/qrxlUb8.png ]
• Yeah
• No

[pat-s]

Did you also follow all points in https://github.com/LukeSmithxyz/voidrice/issues/284#issuecomment-487404752?

My .config/fonts/fonts.conf looks like this

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>

 <alias>
    <family>serif</family>
    <prefer><family>Fira Sans</family></prefer>
  </alias>
  <alias>
    <family>sans-serif</family>
    <prefer><family>Fira Sans</family></prefer>
  </alias>
  <alias>
    <family>sans</family>
    <prefer><family>Fira Sans</family></prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer><family>Mononoki</family></prefer>
  </alias>

  <!-- This sets Symbola as the final fallback font for the monospace font family. -->
  <match target="pattern">
        <test name="family"><string>monospace</string></test>
        <edit name="family" mode="append"><string>Symbola</string></edit>
    </match>

</fontconfig>

[kroppt]

If you really can't get it to work, you can try using another terminal in the meantime, like gnome-terminal (color emoji support). Although I'm sure the keybindings will screw up the setup.

[omcho420]

Mine looks like this
```shell

serif
Linux Libertine


sans-serif
Linux Biolinum


sans
Linux Biolinum


monospace
Inconsolata

monospace
Symbola

[marcthe12]

The presise cause of the issue is not st itself but xft. Xterm had the same issue a while back. And dmenu and DWM also has the same issue. There is a work around for DWM in the mailing list. Maybe the patch can be ported to st. The link is below

https://lists.suckless.org/dev/1610/30720.html

EDIT: spelling error due to autocorrect

[kvannotten]

I changed return utfbyte[i] | (u & ~utfmask[i]); on line 349 to just return utfbyte[i] and that seems to work for now. Thanks @marcthe12

[LukeSmithxyz]

Are there any other people for whom this eliminates the problem? If so, I might make the change @kvannotten has in my st repository.

[kvannotten]

Don't merge this change, it has some weird downsides with certain shortcuts no longer working.

[marcthe12]

Update.
Updteam has added an FAQ on this.
https://git.suckless.org/st/file/FAQ.html
Also xft issue is https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6

Should be solved in line 1289

[omcho420]

@LukeSmithxyz you can close this one, a patch has been added for those who haven't fixed it yet

• https://st.suckless.org/patches/font2/

[willem66745]

For anyone ending up here I found a very hacky solution to avoid crashes in st (lukesmithxyz/st#37):

In the function xdrawglyphfontspecs (in x.c), change:

XftDrawGlyphFontSpec(xw.draw, fg, specs, len);

into:

FcBool b = FcFalse;
FcPatternGetBool(specs->font->pattern, FC_COLOR, 0, &b);
if (!b) {
    XftDrawGlyphFontSpec(xw.draw, fg, specs, len);
}

The change prevents that any colorized glypth (character) to be rendered and will only fill a blank space. The other (discussed above) avoid the mapping of colorized glyphs.

I think this could be optimized, but I lack time to investigate this. Bit confused how the caching mechanism works in st.

[tbergeron]

https://github.com/LukeSmithxyz/voidrice/issues/284#issuecomment-534297661

This doesn't fix the crashes for me.

[kiprasmel]

@tbergeron there have been some important updates on this issue just recently - see https://youtu.be/f9qNXV01yzg.

I've had my crashes fixed prior to the video, but it should now help you not get them in the first place.

It also allows you to have colorful emoji in xorg (including st, dmenu etc.),

but I myself have not managed to get them to work.. I think there might be some important steps Luke might've forgotten to mention, or I'm messing stuff up myself. Either way, no colorful emoji for me so far :c

[goldcoders]

I manage to make it work the emoji
first i install the colored emoji

yay  ttf-joypixels

then

sudo ln -sf /etc/fonts/conf.avail/75-joypixels.conf /etc/fonts/conf.d/

this will add a fallback to all emoji ....
install libxft-bgra , this will help prevent st from crashing

then i edit my st build
x.c

/* Render the glyphs. */
    XftDrawGlyphFontSpec(xw.draw, fg, specs, len);

i remove the conditionals for rendering the glyp to just render it

and i change my .config/font-config/fonts.conf

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>

 <alias>
    <family>serif</family>
    <prefer><family>Linux Libertine</family></prefer>
  </alias>
  <alias>
    <family>sans-serif</family>
    <prefer><family>Linux Biolinum</family></prefer>
  </alias>
  <alias>
    <family>sans</family>
    <prefer><family>Linux Biolinum</family></prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer><family>Inconsolata</family></prefer>
</alias>
</fontconfig>

then i edited dmenuunicode script , and change font to Monospace

Dmenu Shows None Colored Emoji while St , VSCODE allows you to see emojis

@LukeSmithxyz can u confirm this is the same process as you did?

The only problem im facing now is the initial dmenuunicode options shows no emoji
only after i start typing it will load the emojis...

Hope we can find better solution to this ....

for now i will revert back to the old config i have its better and faster even if no color emoji