Open DeeDeeG opened 7 years ago
Ah I wish I could! It feels like half the time I've worked on these two emoji fonts has been dealing with fontconfig. There are a number of relevant issues regarding this. The starting point if you want to read all about it is: https://github.com/eosrei/emojione-color-font/issues/2
I think this whole fontconfig issue needs a short list of testing/QA steps. (Maybe there really is a better fontconfig option out there? Also, as new versions of software come out, they get better at handling emoji (especially since they have become standardized in OpenType). So there might eventually be a better fontconfig option, but it would be too hard to verify if it works as well as the current one, without a QA checklist.) In terms of GitHub, that might look like a "tracking issue" with the little checkboxes and links to the remaining issues.
E.G. (example QA checklist):
(I can see how it gets out of hand quickly, and maybe becomes too much of a hassle to make any headway. So this is just a friendly suggestion for making fontconfig stuff more manageable.)
When I first learned of all of these issues. I started researching how it all worked on Windows and MacOS/OSX. I actually started looking into what would be involved with forking DejaVu and making a separate emoji and symbol fonts like Windows has.... but realized that was going to be a massive job which I didn't want. Using Bitstream Vera is a hack. It works, but causes it's share of problems for the surprising number of applications which have re-implemented fontconfig.
I wish I could do some sort of automated tests.
Hi...
Background info: Someone filed an emoji-related bug with Firefox, and he attached a simple fontconfig as part of ensuring his Steps to Reproduce were, well, reproducible. It ensures the specified emoji font is used preferentially over other fonts, in the most general way possible.
It is very simple, and seems to be working for me so far. You might want to take a look, and maybe copy his approach?
David Baron's fontconfig file (as a bug attachment): https://bug1267909.bmoattachments.org/attachment.cgi?id=8745837
(and the Firefox bug page itself, for context: https://bugzilla.mozilla.org/show_bug.cgi?id=1267909 )