When emojis or album images (smh, like in rhythmbox plugin) displayed in tab's title, they become unlimitedly large. It can be "a feature, not a bug", but it would be nicer to set fixed tabs' size after processing configuration.
https://imgur.com/a/hs5uiog
sway version 1.0-beta.1-172-g7fa7f4f4 (Nov 10 2018, branch 'master')
Yeah I think this is not a bug. You should specify the size of your emoji font in your font configuration.
Yeah I think this is not a bug. You should specify the size of your emoji font in your font configuration.
But there are still cases where we don't need fixed-size emojis? Eventually, since programs can load any garbage into their titles, it would be an issue not only for displaying emojis.
Most garbage won't render at such a crazy size. There's no unicode codepoint for extra large. It's an issue with your local configuration.
This is not only a bug, it's a regression. This issue did not exist in 0.15. I have specified my emoji font size and Firefox happily ignores it.
In ~/.config/sway/config:
font Dina 8, "Noto Sans Emoji" 8
In Firefox:

@tidux, turns out it's really a problem with fonts configuration. If we'll open Rhythmbox' SoundCloud plugin for the case, it would screw up all the native GTK tabs, showing there album covers beside emojis. As far as I remember, it can be fixed with one simple line:
sudo ln -s /etc/fonts/conf.avail/10-scale-bitmap-fonts.conf /etc/fonts/conf.d.
Or use your local configurations' directory to apply this for your user:
/home/$USER/.config/fontconfig/conf.d
No, that configuration is already in place and the problem persists.
On February 13, 2019 9:44:36 AM PST, chzzzh notifications@github.com wrote:
@tidux, turns out it's really a problem with fonts configuration. If
we'll open Rhythmbox' SoundCloud plugin for the case, it would screw up
all the native GTK tabs, showing there album covers beside emojis. As
far as I remember, it can be fixed with one simple line:
sudo ln -s /etc/fonts/conf.avail/10-scale-bitmap-fonts.conf /etc/fonts/conf.d.Or use your local configurations' directory to apply this for your
user:
/home/$USER/.config/fontconfig/conf.d--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/swaywm/sway/issues/3114#issuecomment-463296042
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
@tidux, try out prioritizing an emoji font ahead (and don't forget to install noto-fonts-emoji package):
sudo $EDITOR /etc/fonts/local.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<alias>
<family>serif</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
<alias>
<family>sans-serif</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
</fontconfig>
That worked, thanks.
Follow-up: I don't think this is a bug with the configuration as much as the Noto Emoji font itself. Switching my emoji font to Twemoji Mozilla was a more robust fix.
Could you elaborate on what part of the 'local configuration' is wrong that causes this? I just want to use Fira Sans in my tab titles so I have font Fira Sans Medium 9 in my sway config. Originally I had fonconfig configured to use Droid Sans Fallback as a fallback font but that was causing the sway tabbar resize with any CJK text, even when Droid Sans Fallback was specified with a size in the sway config like font Fira Sans Medium, Droid Sans Fallback 9. So I removed that fonconfig setting and sway then used some other font as fallback and the issue stopped for CJK, but persisted for emojis. The above configuration options didn't help and I was only able to make it stop by uninstalling Symbola and Noto Emoji fonts and installing Twemoji. Now I have noticed that the issue still persists with Thai characters. I'm not sure how to fix it this time, specifying font Fira Sans Medium, Noto Sans Thai 9 doesn't help.
@sammoth, it seems a pretty strange behaviour, cause the 10-scale-bitmap-fonts.conf setting does not scale non-color symbols, and they should not be:
Note that color bitmap fonts have scalable=true, while
non-color ones have scalable=false. Both groups have outline=false.
Speaking of resize with any CJK text, looks like Droid Sans Fallback doesn't handle these characters, so it switches to next installed by alphabet (not sure), which hasn't specified font sizes and use cases (or other meta stuff out there). And while non-color fonts are non-scalable, according to configuration unit, to smaler sizes, they are smh shown as huge, as possibly could be. And what happened when you removed it is sway still used the same font next to Droid Sans Falback for CJK, but now was allowed to scale it, while vice-versa did not do it for emojis.
The possible way I see to fix this is to tell fontconfig all characters are scalable, not only non-color by default. Try out changing bool to true in <test name="scalable" compare="eq">. If it will work out, it maybe considers to be an incorrect fontconfig behaviour.
Yet I'm pretty certain, would be nice to have an extra feature in configuration, that restricts tab size to prevent further issues with it since it's unusual behaviour to have bigger tab size.
would be nice to have an extra feature in configuration, that restricts tab size
I would like to see this feature, too!
Eventually, I don't understand why sway chooses to resize tabs based on the maximum text height. Since when using Unicode the text height is unlimited (think combining marks).
I have an expectation that it would either follow some setting in the config (a-la bar height) or use an inter-line height (x-height+ascender+descender heights?) as a base.
Currently I have this added to my sway config to force the title bar to be same size always
for_window [title=".*"] title_format 鈻笍 %title 鈻笍
@artizirk interesting! How does it work?
I will check if it resolves my issue.
it adds a black emoji box to every window title and that in turn sets the window title height to be always atleast the height of the emoji box character.
This issue should not be closed. The issue is with Sway, not with emojis installed. I've tried both for_window [title=".*"] title_format 鈻笍 %title 鈻笍 and switching to Twimoji as my emoji font. Neither of which works.
Also having this issue not only with emojis. When VSCode has a dirty/unsaved file, it shows a circle in the title bar for that file, which goes away when saving he file. That causes the bar to grow/shrink a pixel or two (which causes the windows to flicker sometimes).
Why is this bug closed? It is a bug on sway. No WM should have the window size jump depending on what the app decides to place there.
Most helpful comment
Yet I'm pretty certain, would be nice to have an extra feature in configuration, that restricts tab size to prevent further issues with it since it's unusual behaviour to have bigger tab size.