openmoji
openmoji copied to clipboard
hfg-gmuend
OpenMojis on dark background
☃️ Snowman is transparent, whereas ⛄ Snowman Without Snow is opaque white, so they don't match when the background isn't white.
thanks for the hint. at the moment we have a some problems with openmoji on a dark background (to the left of the snowman there is a snowflake ; ) we have to think about how we can handle this.
Many thanks for the bug report! I guess for the two snowmans it is easy to fix ... but as Daniel hinted there are quite a few cases like this, where we should find a general way of dealing with the background problem. You can either do a PR and fix the background or wait for the next official release, which aims to fix open issues and to introduce new special interest categories.
The simplistic solution for all emoji glyphs that have graphical elements that are thin and are monochrome is for a suitable contrasting colour outline around them so that it provides a background when the canvas onto which the glyph is painted is similar in colour as the original element...
@SlySven Yes, this is what was done with Google's Noto Color Emoji to make them work on yellow backgrounds.
A 6px wide white contour line underneath would be the simplest and most pragmatic solution. It doesn't disturb on light backgrounds and can be removed if necessary. Actually I even like the extra line. The emojis look bolder and more stable on dark backgrounds.
I think this would generally work, but there's a few factors involved here:
-
The template
Currently the margins are 4px, and I'm trying to make sure emoji fit in the margins
I think it's okay for emoji to overlap the template with the wider stroke -
I suggested in #112 that we decrease the template padding by 50%, so that emojis look similar in text to other platforms. However with the new outer stroke, that would mean that emojis would touch. I guess the alternative is to increase the size of the "smiley" circle in the template and increase the size of all emoji to be at least that width or height. Obviously this is a lot of work but I think that it would be worth it so that they are a practical size.
Overall, I think this is a good solution and I kinda like the "sticker" look.
A counter point I would suggest is that maybe not all emoji needs this treatment, I think lots of the emoji do fine without the background
or
and that maybe we only make them stickers if they are compromised in some way (like the paperclips)
maybe a rule is if there is any line without a stroke or fill? (like the needle in Syringe)
I am happy to accept that we need to be be consistent though :)
If we continue in this direction we should treat all emoji equal. Otherwise it could get complicated and inconsistent. The additional outline also helps for flags with black parts:
… and it would be really cool if we could somehow automate this whole thing ; )
yeah it would be very good to automate this, but I'm not sure what the best approach would be
I think adding a layer between grid and color/line-supplement with a union of the line+line-supplement with stroke of #fff and stroke width of 6 would be easiest. That makes sense in my head haha, I'll try see how easy that is
I've made a script which works fairly well :)
One thing to consider is that the quality of the outline is of course directly correlated to the quality of the existing line layer
Outline is not white for clarity
Very nice! Is there any way to also include open color areas (like in the tail of the skunk)? Btw. the other skunks also don't do well on dark backgrounds ; )
Hey all,
@b-g I finally found some time to get started on this 🙈 Thanks for the investigation @carlinmack, especially the collection, that was really helpful.
Approach:
As a starting point, I tried with the same (?) simple approach:
- I take all final SVGs (I actually just downloaded the zip from OpenMoji.org)
- I use Cheerio (which is basically Jquery in NodeJS and easier to use than JSDom) and then for each SVG ...
- ... I store all svg-nodes (all groups, paths, etc.) in memory, delete them from the SVG and add two groups (background and emoji) ...
- ... emoji gets all the svg-nodes completely unchanged ...
- ... and background gets also all the svg-nodes, but (a) all strokes are turned white and enlarged (important as not always consistent) by 4px and (b) all fills are turned white + either get a stroke with 4px or follow (a)
- Note: In my example I don't use white, but rose to make it clearer what was added
You can check out all emojis here: stephanbogner.de/openmoji-darkmode/
⚠ Not optimized website 😬
Special cases
1. Issues caused by outlining everything
If I outline every element, then sometimes due to the geometry the inner element's outline extends outside. → We should handle it in a smart way to not outline everything, but either (a) merge all elements and only outline once or (b) don't outline elements that lie inside other elements.
2. SVG viewport too small
Sometimes the content is cut off due to the now larger size. → An easy fix would be to enlarge the SVG viewport / SVG dimensions. Not sure if this would break anything somewhere else (e.g. font generation)? @b-g
3. How outlining works in SVG
I think that is the case with the skunk that was mentioned. Basically there is a path used instead of a closed polygon. That is fine with fill only, but it creates this effect, when a stroke is added. → This can either be fixed by adjusting the source file ... but I'd recommend to automate (= we "just" convert paths to polygons in that case) because I saw that in many emoji and it's likely a common way to design. Note: I haven't tested converting paths to polygons ... so not sure if that breaks something else visually.
4. The "hole problem"
Not actually a problem ... but sometimes it gets visually very messy if the holes are not filled up. → If holes should be filled we could probably find an algorithmic solution to this.
5. Design rules
These cases I found, I think it would make sense to adjust the source files. Not sure about the spiral but for the rest it might make sense to have special rules. E.g. design "transparent" elements as white or always fill (bike) wheels. If we decide in 4., that holes should always be filled (programmatically) then that would also fix many of the issues.
Please have a look and let me know what you think
Ok, regarding "3. How outlining works in SVG":
That's actually easier to fix than I thought. No need for polygons, you can just add a Z or z at the end of path coordinates-data which specifies that it's closed.
E.g.: <path fill="#F2DDF5" stroke-width="2" stroke="#F2DDF5" d="m250 10h80v80h-80z"/>
Side note: Cheerio is crazy fast ... it takes less than a minute to process all 3914 emojis 🏎 (Obviously only, because currently I don't do any geometry calculations with another framework ... it's just XML-manipulation at this moment)
Without adding "Z" to paths with fill:
With adding "Z" to paths with fill:
I updated the version on: stephanbogner.de/openmoji-darkmode/
A detail I noticed, related to "5. Design rules":
A few emojis – I encountered it at the jugglers (starting with 1F939) – use pastel colors without outlines. Especially the blue is hard to see. I personally always use accessible-colors.com to make sure the contrast is fine.
In theory this is also a problem without the dark mode but I struggle more with that when in dark mode (maybe due to surrounding contrast or my astigmatism 🤷).
this is ultra mega awesome! … thank you @stephanbogner
- SVG viewport too small – if it doesn't destroy anything i would also suggest to expand the viewport by 2 px
- the "hole problem" – sometimes i would keep the holes so i think we should rather fix it manually.
adding "z" to paths with fill – this saves us a lot of tedious work ; )
… and we should redo the jugglers: maybe with black outlines around the beanbags
Hello! I just came through this issue and then @stephanbogner 's comment, and I felt really lucky because it was just what I was looking for.
I'm developing a website for delivery of organic foods, and since I spend the whole day doing that, using a dark theme to take care of my eyes is a high priority. As I chose OpenMoji as my "font toolkit", the problem was what you had already been discussing here.
Could @stephanbogner 's custom dark set become an official OpenMoji set? And if not, could you @stephanbogner share a link to download it?
In my case, this is specially relevant for emojis of products, for example sprouts and wine, whose best representations are 1F331 (seedling) and 1F377 (wine glass), respectively. If I continued using the official "SVG color" set, these emojis would not make sense if used along a dark theme because all you can see is 1 or 2 coloured shapes which look like floating objects. Therefore my customers would need explicit mentions of those products names be it with title and alt attributes or a <p> element.
At the moment I cannot share a link to my website because it is in a very early stage of development. I haven't translated it to English yet, design is not consistent, and there are some broken links. But I'd gladly share the link when it's mature enough!
Besides the above, thanks a lot to all of you who developed and are developing this awesome project!!! I really feel it's the best one can use as a font toolkit, both because it's based on Unicode (the scope of the emojis is huge) and it has a coloured set (it makes everything more lively). By the way, is there any way I can donate or become a sponsor of the project?
Best!
Francisco.
Hey @6feriolimarco,
Great to hear, that it would be of use 🙂
And yes, it will become part of the official set. @b-g actually approached me to help out with this. (We are currently working on how to include the code in the build and the review process of the OpenMojis.)
But if the SVGs that I posted earlier are already sufficient for your use, I just uploaded them for you here.
By the way, is there any way I can donate or become a sponsor of the project?
dear francisco, we are working to set up a github sponsors account. would that be a practical option for you?
@stephanbogner Amazing!!! 🥳
Yes, I'll better use your set to get out of trouble quickly and then, when it becomes part of the official set, I'll change it.
@dnlutz I understand that GitHub is the website where you host your code and therefore would be easier to have sponsorships on the same place, but if it was for me, I'd rather donate through an open source website hosted in Europe, preferably not hosted by "the big five" (GAFAM).
The only one I know of this kind is Spanish "Goteo", which is hosted by Hetzner in Germany and is available in lots of languages, including English, German and Spanish of course.
There's lots of European crowdfunding websites, Goteo is just one of them, but still the best one I've found.
Otherwise there are self-hosted options which are listed as alternatives to PayPal and Patreon.
Hope you find this information relevant and useful.
Best!!!
Francisco.
@carlinmack yes, they are open source, but they are both hosted in US. 😕
Europe does not have something like CIA/NSA crawling your personal and sensible data, as far as I know.
And in many European countries you are not forced to disclose encryption keys.
Europe does not have something like CIA/NSA crawling your personal and sensible data, as far as I know.
Aren't many countries in Europe part of the five, nine, and fourteen eyes (https://en.wikipedia.org/wiki/UKUSA_Agreement#9_Eyes,_14_Eyes,and_other%22third_parties%22)?
And in many European countries you are not forced to disclose encryption keys.
There is no official law in the USA that says that one must disclose keys and the judicial precedent is murky (https://en.wikipedia.org/wiki/Key_disclosure_law#United_States). Regardless, you are correct that many European nations have better privacy protections than the United States.
@exaCORE42 @6feriolimarco
While the topic you are discussing is important, please open another issue for it and continue there, as it doesn‘t fit this issue‘s purpose – thanks a lot ❤️