http://bugzilla.opensuse.org/show_bug.cgi?id=1092737 http://bugzilla.opensuse.org/show_bug.cgi?id=1092737#c14 --- Comment #14 from Marguerite Su --- Hi, Just kind of progress report: I identified the problem: Noto Color Emoji. It contains weird space characters. If it was prepended first, it applied a large whitespace. It didn't work even if I blacklisted all space characters. So I thought some modifier characters caused this. They can't be blacklisted or emoji support will be broken, since we know some emojis consist of 3 or 4 unicode character plus a modifier character. So I have to find another way to support color emoji on openSUSE. Nowadays seldom web pages specified the generic name "emoji" or specific emoji font, so emoji fonts have to fight with "sans-serif" to get used. And we can't append emoji fonts to sans-serif sequence, because it's just wrong and you will not know what emoji font a user may install. So we have to make sure every other non-emoji font (like DejaVu/Libration fonts) contains no emoji characters on any user's system. I did this in fonts-config level and I implemented some early demos. To apply on "any user's system", I need to redefine %reconfigure_fonts_prereq so every time the user installs a new font, emoji characters will be blacklisted on the new font unless the new font is an emoji font. Then I need an easy-distributable binary to do such calculations. Besides, some developer send a merge request to enable subpixel-rendering on openSUSE. I neeed fonts-config to be able to fetch DPI and better know the RGBA style of the user's screen. So in short, I am implementing the new fonts-config, it will need some time. I just finished the existing features in current fonts-config on my branch. -- You are receiving this mail because: You are on the CC list for the bug.