GNOME Bugzilla – Bug 787365
With the recent emoji related changes in pango and fontconfig, it is not possible to select a font to be used for emoji anymore from an application
Last modified: 2018-05-22 13:27:17 UTC
Created attachment 359272 [details] pango-emoji-test.txt See also: https://bugzilla.redhat.com/show_bug.cgi?id=1488096 With pango 1.40.12 and fontconfig from git master, it is not possible to choose the font used for emoji from pango anymore. For example if I have the fonts "Emoji One", "Noto Color Emoji", and "Symbola" installed and try this: pango-view --font='Symbola 50' pango-emoji-test.txt & pango-view --font='Noto Color Emoji 50' pango-emoji-test.txt & (where pango-emoji-test.txt is the attached test file containing U+1F600 GRINNING FACE). Then I get the emoji displayed using "Emoji One" always. That I specified different fonts with pango-view is ignored. When I delete the "Emoji One" font, "Noto Color Emoji" is used. Instead of deleting the "Emoji One" font, I could also edit fonts.conf to make fontconfig prefer the "Noto Color Emoji" font. But editing fonts.conf is quite difficult for normal users. I think it should be possible somehow to specify the desired emoji font using a pango setting. That would be especially useful for applications which offer emoji selectors. But also for other applications, for example it used to be possible to have a setting like font pango: DejaVu Sans, Symbola 12 in the config file for the i3 window manager (~/.config/i3/config) to force black and white emoji from the Symbola font to be displayed in the i3 status bar. But now this is ignored, instead of “Symbola” “Emoji One” or “Noto Color Emoji” are used, depending on which of these is installed. The latest version of “Noto Color Emoji” seems to work better for me than “Emoji One” because it contains all the emoji which have recently been added to Unicode 10.0.0. So it would be nice to choose “Noto Color Emoji” as the emoji font in the setup or on the command line of an application using pango without having to edit fonts.conf.
Created attachment 359762 [details] [review] proposed patch adding new API to set/get the emoji font description to PangoContext.
Ideally I like to avoid adding new API and make it such that if the selected font does support emoji language (und-zsye), then be picked up over our fallback emojis. But don't know how to do that exactly.
Hmm, well, the objection here is that emoji font in pango isn't controllable by users regardless of what a font pango select to draw emojis. dunno, it may looks more like important for testing/debugging purpose only though, I have no idea how to do that without adding API. or how about accepting changes of emoji fonts from markup only?
I don't think this needs app-level control. We can discuss adding tweak tool ui for selecting the system-wide emoji font
For testing/debugging, using a custom fontconfig configuration seems fine to me.
Would be good to hear from reporters what use-case they have for this.
I don't think that allowing desktop-level selection of the default emoji font is completely ludicrous. We already allow overriding the default fonts.conf defined "Sans" for the desktop, so one could expect a configuration option in the same place for the emoji font. This would require much more work than simply the above patch for pango. On top of my head we'd need: - gsettings-desktop-schemas: adding a key for it - GTK+: adding a new GtkSettings/XSettings key - gnome-settings-daemon: hooking the above 2 in the xsettings plugin - GTK+: adding an emoji selection mode to the font selection, so that only emoji fonts actually show up in the selection dialogue.
Do we really want to go through all that work, for what is essentially a global setting ? I would find it a lot more appealing to just make gnome-tweaks tweak the users font configuration. On the downside, that requires touching fontconfig...
Doesn't require touching fontconfig, just dropping something in ~/.local/etc/fonts/conf.d/ I think Akira had some tool that would do those kind of things. Also have seen KDE do that.
See: https://lists.freedesktop.org/archives/fontconfig/2014-March/005138.html https://bugs.freedesktop.org/show_bug.cgi?id=76538
(In reply to Matthias Clasen from comment #8) > Do we really want to go through all that work, for what is essentially a > global setting ? It's not a ton of work, but I'm not really interested in taking the time to do it either. I know what the patches would look like though, and it might be a good first contribution for somebody that doesn't know this part of the system. > I would find it a lot more appealing to just make > gnome-tweaks tweak the users font configuration. > > On the downside, that requires touching fontconfig... That would also work, though I half expect it to break because of underlying system configuration changes sooner rather than later.
> - GTK+: adding an emoji selection mode to the font selection, so that only > emoji fonts actually show up in the selection dialogue. Initial designer reaction to this one: Don't expose Emoji in the font chooser at all. Its an implementation detail that they're fonts. Make a custom chooser.
(In reply to Behdad Esfahbod from comment #6) > Would be good to hear from reporters what use-case they have for this. One use case is to make it possible for an emoji selection tool to switch fonts when browsing emoji. Like this tool http://mike-fabian.github.io/ibus-typing-booster/documentation.html#emoji-picker has a font selector which used to work but doesn’t work anymore now. It was useful to compare how certain emoji look in different fonts. Another use case is that some programs have problems when using certain emoji fonts. One problem I encountered was that the status bar "i3status" of the "i3" window manager doesn’t work correctly if the status bar contains emoji and either "Emoji One" or "Noto Color Emoji" are used. The statusbar draws correctly from the right side of the screen until the first emoji appears, every thing left of that emoji disappears. This problem does not occur when a black and white emoji font like "Symbola" is used. This might be a bug in i3status but I could not yet find out what causes this. The workaround used to be to specify "Symbola" as the first fallback font in the font settings line in ~/.config/i3/config like this: font pango: Liberation Sans, Symbola 12 but that doesn’t work anymore, for emoji this is completely ignored. That "Emoji One" and "Noto Color Emoji" don’t work in the i3status bar might be a bug. But even without such bugs I think it is desirable sometimes to choose a different emoji font for a certain program, just like one sometimes wants to choose a different sans-serif font for a certain program and is not forced to use the same sans-serif font all over the desktop.
Hi folks, I was forwarded here by kou from this issue: https://github.com/ruby-gnome2/ruby-gnome2/issues/1111 To add in the details kou asked for: I'm using cairo gem (1.15.10 x64-mingw32) in both situations The output of the code snippet has asked for was "#<Pango::CairoWin32FontMap:00000000031D6CA0 ptr=00000000039B4BA0>"
So, it occurs to me that indeed if we take the requested font (eg. "My New Emoji") and stuff that in a pattern with weak binding, followed by "emoji" as strong binding, and set lang correctly, then the "My New Emoji" font will be selected if it supports emoji charset; otherwise we fallback to "emoji". This has to be verified. If it works, then the next question is how to wire this through in Pango. We can probably come up with an adhoc family name syntax for PangoFontDescription. Eg. "[My New Emoji],emoji" will then be processed by pangofc to add the "My New Emoji" part with weak binding. Other backends should just remove the brackets and proceed...
(In reply to Behdad Esfahbod from comment #15) > So, it occurs to me that indeed if we take the requested font (eg. "My New > Emoji") and stuff that in a pattern with weak binding, followed by "emoji" > as strong binding, and set lang correctly, then the "My New Emoji" font will > be selected if it supports emoji charset; otherwise we fallback to "emoji". To get things working like so, the requested font has to be with the strong binding and "emoji" with the weak binding. because the requested font won't be selected as long as emoji fonts that fontconfig will replaces "emoji" family name is installed on the system.
Created attachment 363672 [details] test code for requested font with weak binding $ ./a.out "Noto Emoji" /usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: "Noto Color Emoji"
Created attachment 363673 [details] test code for emoji with weak binding $ ./a.out "Noto Emoji" /usr/share/fonts/google-noto-emoji/NotoEmoji-Regular.ttf: "Noto Emoji"
Oh, and with the invalid font: $ ./a.out "foo" /usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: "Noto Color Emoji"
I get weird results with attachment from comment 18: behdad:mozilla_behdad0 0$ fc-match emoji NotoColorEmoji.ttf: "Noto Color Emoji" "Regular" behdad:mozilla_behdad0 0$ ./a.out noto /usr/share/fonts/truetype/ancient-scripts/Symbola_hint.ttf: "Symbola" behdad:mozilla_behdad0 0$ ./a.out 'noto color emoji' /home/behdad/.fonts/NotoColorEmoji.ttf: "Noto Color Emoji" behdad:mozilla_behdad0 0$ ./a.out 'noto emoji' /usr/share/fonts/truetype/ancient-scripts/Symbola_hint.ttf: "Symbola" behdad:mozilla_behdad0 0$ ./a.out 'dejavu sans' /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: "DejaVu Sans" behdad:mozilla_behdad0 0$
works for me. do you have any config file causing that result?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/289.