Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add buildsystem for Linux #167

Open
wants to merge 2 commits into
base: master
from

Conversation

@jbicha
Copy link

commented Nov 17, 2017

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 googlefonts/noto-emoji#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

This comment has been minimized.

Copy link

commented Nov 17, 2017

@jbicha emojione-android is built with maximbaz/docker-emojione-fonts-build. @Crissov already investigated/implemented a build system for EmojiTwo, see maximbaz/docker-joypixels-fonts-build#1

@jbicha

This comment has been minimized.

Copy link
Author

commented Nov 17, 2017

@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

This comment has been minimized.

Copy link

commented Nov 17, 2017

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

This comment has been minimized.

Copy link
Author

commented Nov 17, 2017

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

@maximbaz

This comment has been minimized.

Copy link

commented Nov 17, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 7, 2017

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

This comment has been minimized.

Copy link
Author

commented Dec 8, 2017

@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

This comment has been minimized.

Copy link

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Author

commented Dec 13, 2017

@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.

@Crissov Crissov referenced this pull request Jan 11, 2018
@hadess

This comment has been minimized.

Copy link

commented Jan 15, 2018

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

@jbicha jbicha force-pushed the jbicha:master branch from 4573e31 to 8a8e852 Jan 23, 2018

@jbicha

This comment has been minimized.

Copy link
Author

commented Jan 30, 2018

@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

This comment has been minimized.

Copy link

commented Jul 18, 2018

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.

@jbicha jbicha force-pushed the jbicha:master branch from 8a8e852 to feb7ca6 Oct 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.