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

Improve/fix OpenMoji Colorfont (and Black) #93

Open
b-g opened this issue Dec 2, 2019 · 16 comments
Open

Improve/fix OpenMoji Colorfont (and Black) #93

b-g opened this issue Dec 2, 2019 · 16 comments
Assignees

Comments

@b-g
Copy link
Member

@b-g b-g commented Dec 2, 2019

The OpenMoji colorfont is currently just a proof of concept and only works in Firefox.

We hope to improve this to proper colorfont in the near future (or at least in the long run). Sorry + stay tuned and follow this thread for updates!

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Dec 2, 2019

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Dec 2, 2019

This is to gather a few links.

Currently we use https://github.com/hfg-gmuend/openmoji/blob/master/font/README.md basically SVGinOT Color Font Builder a 3-4 year old and stale project. The resulting Colorfont seem just partly to support the standard. They just work in Firefox :(

Other links:

@bohnacker

This comment has been minimized.

Copy link
Member

@bohnacker bohnacker commented Dec 3, 2019

To simplify the discussion:
Which format should we support? Right now, there are four:
PNG based: Google's CBDT/CBLC tables and Apple's SBIX table
Vector based: Microsoft's overlapped glyphs (COLR/CPAL tables) and Mozilla and Adobe’s SVG (SVG table)

These formats are supported as follows at the time (source: https://pixelambacht.nl/2014/multicolor-fonts/):
Bildschirmfoto 2019-12-03 um 19 30 53
Bildschirmfoto 2019-12-03 um 19 30 43

Checking with https://pixelambacht.nl/chromacheck/ there also seems to be supported SBIX in Chrome.

My opinion: there's no way around SVG because it's much more powerful than COLR. I guess, sooner or later all browsers will support SVG Color Fonts.

Our situation:
Bildschirmfoto 2019-12-03 um 19 23 40
From left to right: Chrome, Firefox, Safari (I'm on Mac, so no quick check for Edge, ...)

Safari should support SVG Color Fonts. So, that's a bug.

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Dec 3, 2019

Hi @bohnacker, many thanks for putting this together. I'm agnostic and happy to support a single standard e.g. SVG properly ... just it should be 100%. Currently our colorfont is just rendered in Firefox, but should also usable in Safari, Adobe CC, Sketch, Affinity ... which is not the case. Also @dnlutz is strongly in favor of SVG ... Hence I think SVG is the best bet, however I couldn't find a good tooling for it back at the beginning of 2019. Also note: Google Noto Emoji tooling is PNG based.

@AndydeCleyre

This comment has been minimized.

Copy link

@AndydeCleyre AndydeCleyre commented Dec 6, 2019

I don't know what joypixels (emojione) is doing, but their color font seems to display nicely in browsers and qt apps (including konsole) on Arch linux with the repo package, which fetches joypixels-android.ttf.

@danielleontiev

This comment has been minimized.

Copy link

@danielleontiev danielleontiev commented Dec 6, 2019

The b/w font looks damaged as well for me in LaTeX:
uwSWqRS

@b-g b-g changed the title Improve/fix OpenMoji Colorfont Improve/fix OpenMoji Colorfont (and Black) Dec 9, 2019
@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Dec 9, 2019

Hi @bohnacker, https://www.glyphrstudio.com/online/ a free online font editor might be interesting in terms of debugging the black font. (But also no colorfont support currently glyphr-studio/Glyphr-Studio-1#270)

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Dec 9, 2019

Related font issue from #96:

Not sure how valid this is but using the black openmoji font and vscode, it shows ones we support as a single character and others as multiple characters

However we do have a pirate flag emoji so maybe this is also an issue with the font that we haven't realised?

image

@b-g b-g added the bug label Dec 9, 2019
@bohnacker

This comment has been minimized.

Copy link
Member

@bohnacker bohnacker commented Jan 3, 2020

I checked a few things with our color and black fonts and compared it with the fonts "EmojiOne Color" and "Twitter Color Emoji". I chose those because they are not from a vendor of operating systems (Apple, Windows, Google). EmojiOne is an Opentype font while the one from Twitter is Truetype. Ours is Truetype too.

It appears that our fonts are not that bad in general, but there are quite some things to improve.

The following screenshot is made in InDesign on Mac and it seems to handle the Openmoji Color font perfectly. Openmoji Black has some problems. The conversion from SVG to Truetype glyphs ignores stroke-linecap="round" and stroke-linejoin="round" (most obvious on the smiley and the TM-sign). Also, overlapping paths are not converted well (hand, soccer ball, santa claus).
Screenshot InDesign Mac

For the black font I see two possible solutions:

  1. Remove all strokes from all our source emojis and convert it to filled areas.
  2. Find a better conversion algorithm.
    The first solution is not very practical and desirable. I think it's good to have line elements in the source files as much as possible. Otherwise improving the source emojis will be a hassle.

I found another problem with our fonts in InDesign. Ligatures sometimes are split into parts when text gets wrapped. It happend with the hand and the horse but not with the dark santa claus and the flags. I'll try to find out why.
Screenshot InDesign wrapping


Comparision of the behaviour in browsers:

Firefox (Mac and Windows):
Some problems with our color font shows up. Some strokes are not scaled correctly. I'm mot complete sure why. Maybe it's because there are elements on the color layer that have both a fill color and a stroke color. Or it has something to do with transforms that are still in some emojis. Edit: Quite sure it's the first guess... the hand with yellow skin is displayed correctly, all others not because they get a stroke color while building.
Screenshot Firefox Mac

Safari (Mac):
Only EmojiOne works (maybe because it's Opentype):
Screenshot Safari Mac

Edge (Windows):
Handles our color emojis perfectly.
Screenshot Edge Windows

@bohnacker

This comment has been minimized.

Copy link
Member

@bohnacker bohnacker commented Jan 5, 2020

Maybe we could use some other libraries like this to convert all strokes in the black SVGs to areas before creating the truetype glyphs:
https://www.npmjs.com/package/js-clipper

It seems to support all we need (stroke-linecap="round" and stroke-linejoin="round"). The fact that it is not developed further on is not a problem in my opinion because it has no dependencies.

Or has anybody good experiences with other libraries for path operations?

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Jan 5, 2020

Hi @bohnacker! A belated happy new year + many thanks for the investigation! That sounds a lot more promising than I've anticipated! Yay! A few comments/thoughts:

OpenMoji Black

  • I would vote to introduce a dedicated build process which converts all problematic strokes to shapes ... but not to alter the src svg files
  • Instead of js-clipper I would rather bet on paper.js (in node.js) with the paperjs-offset plugin. (See also the discussion on Parametrized stroke outlining / expanding / offsetting with paper.js)
  • Q: Would we have to convert every stroke or just the ones with stroke-linecap="round" and stroke-linejoin="round" attributes?

OpenMoji Color

  • Q: Is the issue with svgs which have both a fill color and a stroke color a Firefox bug only? If so ... should we simply ignore it?
  • Q: Should we ditch current color font generator or stick with it? I can offer to improve the generator "scfbuild" to support properly generating the two fonts without the current hustle ... but this makes only sense if the scfbuild is worth the invest. (I guess it won't be possible to generate a colorfont in opentype flavor with scfbuild, or?)
@bohnacker

This comment has been minimized.

Copy link
Member

@bohnacker bohnacker commented Jan 6, 2020

Hi @b-g, some answers to your questions and suggestions:

I would vote to introduce a dedicated build process which converts all problematic strokes to shapes ... but not to alter the src svg files

Yes, I think so too. That's the only approach that makes sense.

Instead of js-clipper I would rather bet on paper.js (in node.js) with the paperjs-offset plugin. (See also the discussion on Parametrized stroke outlining / expanding / offsetting with paper.js)

I also agree. I had a look at js-clipper and found that it converts all curves to polygons. The result will be glyphs that will look bad when scaling them up a lot. Still we have to check if paperjs is doing everything correctly.

Would we have to convert every stroke or just the ones with stroke-linecap="round" and stroke-linejoin="round" attributes?

Best would be to convert every stroke beforehand because scfbuild (or whereever this is done) has also problems with paths that are crossing itself (see hand and soccer ball in the above examples). In the end (as a glyph) everything will be areas.

Q: Is the issue with svgs which have both a fill color and a stroke color a Firefox bug only? If so ... should we simply ignore it?

As far as I've seen, it's a Firefox only bug. Maybe we could ignore it and hope for a bug fix on the Firefox side.

Q: Should we ditch current color font generator or stick with it? I can offer to improve the generator "scfbuild" to support properly generating the two fonts without the current hustle ... but this makes only sense if the scfbuild is worth the invest. (I guess it won't be possible to generate a colorfont in opentype flavor with scfbuild, or?)

I think we could stick with scfbuild. In general it is doing a good job as far as I've seen. I don't know if it is possible to switch to opentype using scfbuild. I think the truetype glyph creation is done with the fontforge library which should also be capable of generating opentype glyphs. But there might still be a lot more things to change...

@mikemaccana

This comment has been minimized.

Copy link

@mikemaccana mikemaccana commented Jan 6, 2020

Note this image is 5 years out of date (it's from 2014):

70079230-9e50d800-1604-11ea-843c-20e66e936bfe

COLR works fine in Chrome now

https://pixelambacht.nl/chromacheck/

@b-g

This comment has been minimized.

Copy link
Member Author

@b-g b-g commented Jan 7, 2020

@mikemaccana Thanks for the heads up! :)

@bohnacker Many thanks + agree! Should I go ahead and improve scfbuild with a dedicated --black-only flag so that we can streamline the font build process, or is this too earlier and currently not helpful?

@mikemaccana

This comment has been minimized.

Copy link

@mikemaccana mikemaccana commented Jan 7, 2020

PS is there a webpage we can see openmoji rendered in COLR format, as a webfont?

@bohnacker

This comment has been minimized.

Copy link
Member

@bohnacker bohnacker commented Jan 8, 2020

@b-g: If you want you can streamline the font building but it's not urgent from my side. I'll start testing paperjs stroke conversion and exploring the other bugs.

@mikemaccana: We haven't build the font in COLR format (and I'm quite sure that we can't do that in the near future). We concentrate on debugging the SVG color font.

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