Add buildsystem for Linux

[jbicha]

Emoji One provides a font file named emojione-android.ttf. But the font also works on (very recent) Linux distributions using GNOME (or similar desktops). I don't know how the "Android" font version was built historically (the build system isn't specificied in the git repo) but I believe it is currently built using https://github.com/mxalbert1996/emojione-android/ which makes a few tweaks to the buildsystem provided by Noto Emoji.

It would be nice if Google would move the buildsystem part of Noto Emoji to a separate project from the Noto Emoji font sources. See https://github.com/googlei18n/noto-emoji/issues/9 but for now, I think this is the way we need to do it.

I used a separate directory for this to make the licensing easier to understand and to make it easier to compare with upstream Noto Emoji. The Linux buildsystem is licensed Apache-2.0.

[maximbaz]

@jbicha emojione-android is built with maximbaz/docker-emojione-fonts-build. @Crissov already investigated/implemented a build system for EmojiTwo, see https://github.com/maximbaz/docker-emojione-fonts-build/issues/1

[jbicha]

@maximbaz I am packaging Emoji Two for Debian and Ubuntu so Docker isn't really an option. The Fedora Workstation team would like to ship Emoji Two by default in Fedora 28 (the lack of a build system prevented it from being released in Fedora 27). Docker wouldn't work for Fedora either.

[maximbaz]

That's a pity. The idea with docker image was to use it in Travis, so that Travis automatically compiles the font every time a new release is made on Github - that's what I did for EmojiOne. But if there is a requirement to be able to recompile from sources without using any external tools, then there is nothing else to do 🙂

[jbicha]

I don't see how this merge proposal will cause a problem for you using Travis.

[maximbaz]

No issues at all, I only wanted to warn you that you are reimplementing something that already exists - but since you have reasons to do so, please proceed 🙂

[Crissov]

Sorry, I saw this PR, but somehow totally forgot about it.

I have to say I don’t understand everything this would be adding and doing. It also seems like some of it is still specific to Google’s Noto Color Emoji.

Since we not yet fully implement Emoji 4 and 5, on the one hand, but support several chars that are not emoji by Unicode’s Reckinnung for compatibility with Samsung, Microsoft and HTC (and for some special flavor), I expect that the build process will yield warnings for missing files on the one hand and completely ignore some resources on the other hand, unless we update the metadata files accordingly.

In other words, I tend to wanting to accept this PR, but I’m not sure about its benefits and consequences yet.

[jbicha]

@Crissov The only warning I see during the build is cannot process alias fe82b -> unknown_flag

I assume you'll want to check emoji_aliases.txt and emoji_annotations.txt when adding new emoji (and to verify that it includes emoji you've added so far).

A problem with non-standard emoji is that normal apps and libraries may not recognize them either (I'm thinking particularly of emoji chooser widgets).

You're welcome to check out the font I produced with this script yourself. It is EmojiTwo.ttf at https://people.ubuntu.com/~jbicha/

[mavit]

Rather than importing these build components from noto-emoji into emojitwo, does it make more sense to split them out into their own project? They could then be used to build other fonts, such as twemoji.

I'll add, it's also possible to build emojitwo using noto-emoji's build tools directly. See this Fedora RPM. I'm waiting to see whether this approach passes Fedora's package review process.

[jbicha]

@mavit Yes, I agree it would be better if the Noto Emoji build system would be split into a separate package. See the 2nd paragraph of my original post for this issue.

Meanwhile, I think it makes more sense to have the build system here instead of requiring an extra tarball with a whole different emoji font just to build.

[hadess]

@jbicha could you update and force-push your PR again, so that the CI is relaunched?

[jbicha]

@hadess I did but Travis still failed.

This pull request is basically blocking inclusion of this font in Debian & Ubuntu since I'm uncomfortable with distro-patching a patch like this that hasn't been accepted upstream.

[hackerb9]

Hi @Crissov, is there any reason this pull request can't be accepted? It looks like it's useful and wouldn't break anything. Also, once emojitwo can be included in Debian and other GNU/Linux systems, there may be more interest from people to contribute graphics to complete the font.