Sprite sheet generator to facilitate emoji picker development

[axelpale]

I made a sprite sheet generator for OpenMoji emojis. It aims to help web developers to compose the hundreds of emoji images into a few compact image files. Such a step is needed before building almost any kind of emoji picker because web pages will choke up if every emoji has to be loaded separately. I have been sad because of this hardship and I want to fix it.

The generator is available at: https://github.com/axelpale/openmoji-spritemap-generator

It is a working proof-of-concept and will require some more work from my part and input from the community and developers. It is still not a simple enough to fix the hardship. I dream of a dedicated web service where users could visually choose which emojis or emoji groups to include to the sprite sheet and download the results for their usage. This generator is not like that. This generator is just a programming library. However, the dream service could be built on top of this generator.

I would love to know what you think.

As a footnote, the issue has been brought up at least twice before, once by me:

• https://github.com/hfg-gmuend/openmoji/issues/123
• https://github.com/hfg-gmuend/openmoji/issues/30#issuecomment-553879352

[carlinmack]

Wow very nice!

Are you thinking of a website that interacts with your generator on the backend? I might be interested in working on this

[axelpale]

@carlinmack Thanks! Yes, that is exactly what I dream of! I am happy to hear that.

As a side note, I am planning to add the CSS sprite sheet as the fourth type of file to generate. A CSS sprite sheet would allow web developers to render a single emoji from the PNG sprite sheet just by using HTML classes like this: <span class="openmoji-emoji openmoji-emoji-1F600"></span>

[carlinmack]

So I'm looking at the code used to generate the list of emojis for openmoji.org/library and I think the mark up could be edited to allow for selecting categories, emoji etc. I imagine that this generator could be developed in the following steps:

1. Allow for selecting in the interface:
   1. of individual emojis
   2. of categories
   3. of subcategories
2. Send that choice to the back end server
3. Backend server generates spritesheet
4. Sends spritesheets to the browser

Does this sound reasonable? any steps I've missed?

[b-g]

... And let me add that a SVG sprite sheet might be even better than a very big PNG sprite sheet.

1. iv. sprite sheet PNG or SVG or COLORFONT (generate a font with only the selected glyphs)

Such a step is needed before building almost any kind of emoji picker because web pages will choke up if every emoji has to be loaded separately.

I can't confirm this :) I have to say that we don't have any problems on OpenMoji.org with too many request. Simply lazy load the svg files and the problem is mostly solved. + You might find also #123 "Chrome extension emoji picker" interesting.

[axelpale]

Hi @b-g! Thanks for the insight. Some further comments:

And let me add that a SVG sprite sheet might be even better than a very big PNG sprite sheet.

I agree. A SVG sprite sheet can provide better quality per megabyte than a PNG sprite sheet, especially when emojis are larger than 72x72. For reference to this thread, here below are the file sizes of the current OpenMoji packages after uncompression, each containing 3445 individual emojis. We can see that while a SVG emoji has, on average, almost double the file size of 72x72 PNG, it is only a third of the file size of an average 618x618 PNG.

• openmoji-72x72-color, 5.9 MB
• openmoji-svg-color, 11 MB
• openmoji-color.ttf, 12.7 MB
• openmoji-618x618-color, 35.8 MB

However, I doubt an emoji picker would need anything larger than 72x72. A picker could even do well with just 36x36 for each emoji. Of course, retina displays and variable viewport scaling ratios would favour higher resolutions to avoid mushy PNG, like in #123. A SVG gives the absolute best quality in those cases, but might double the file size. People how develop for the third world and for areas with slow internet access might not want to make that sacrifice. Therefore...

1. iv. sprite sheet PNG or SVG or COLORFONT

...having options is a great goal to aim, I agree.

I can't confirm this :) I have to say that we don't have any problems on OpenMoji.org with too many request. Simply lazy load the svg files and the problem is mostly solved.

I need to disagree you on this although I appreciate the interesting insight. I want to emphasise how vastly different use case a general-purpose emoji picker has. Where OpenMoji.org is dedicated to display emojis, an emoji picker is just a tiny button at the corner of a comment form. The picker is only a small piece of a possibly resource-heavy host application. Any negative effect caused by the picker either on server load or on client app performance will negatively affect the browsing experience. But ok, the latter can be solved by lazy loading the picker, given that the developer has time and means to implement the laziness.

Furthermore, a good emoji picker must work instantly. Modern instant messaging apps make emoji input almost as frictionless as typing in a letter. Users expect that. If their internet connection is poor and they need to browse through multiple tabs of hundreds of emojis, they rather leave the emoji out than wait multiple seconds for the emojis to load so they can find the desired one. Their browsers will cache the emojis for the next time, that helps, but the first impression is important. Especially so on comment forms. Most users probably post only a single comment during their visit, although I do not have hard data to support this.

The OpenMoji library viewer initially loads 36 emojis on my desktop browser and loads more when I scroll down. To put that into the context, that 36 amounts to first 4.5 rows out of 48 rows in WhatsApp emoji picker's smileys and people section. The 36 is only a tenth what should be immediately visible in a picker. In my WhatsApp, there is 8 emojis per row, amounting to 384 emojis for smileys and people. As a web developer, choosing between 384 HTTP requests versus 1 or 2 HTTP requests is a very simple decision. For details on why the number of HTTP requests should be kept small, see for example this SO answer.

Forgive me the lengthy answer and strong opinions. I'm just a random guy from the web. I just strongly believe that an ability to build an efficient emoji picker is an important matter for OpenMoji's future growth and adoption, which translates to improved communication in the world.

[axelpale]

Hi all! I worked on this little further. Here is a page where web developers can download pre-generated sprite sheets for their benefit. I would love to see something like this adopted into the official OpenMoji site, a bit further developed of course. @carlinmack Would you be interested to help me developing this further?

https://axelpale.github.io/openmoji-sprites/

Roadmap:

• [ ] Set up a runner file that generates the designed sheets.
• [ ] Crop sheet images to content; auto-adjust height.
• [ ] Design semantically grouped emoji subsets that produce lightweight-enough files.
• [ ] Table of contents to facilitate quick page navigation.

Here also the link to the project's github.

[carlinmack]

1. do you mean every release of openmoji?
2. do you just mean like CSS on this website?
3. do you mean more specific than the current groupings?
4. easy enough 👍

btw I think this would be better in terms of UX if possible

[axelpale]

@carlinmack Thanks for the questions!

1. do you mean every release of openmoji?
2. do you mean more specific than the current groupings?

You are right. It would truly be hell-of-a-job to redesign the custom groupings after every release. The current OpenMoji groups are good but the problem for sprite sheets is that some groups contain over 1000 emojis and some just a few what makes the direct use of groups a bit unsuitable for sprite sheets. Fortunately there are subgroups. They are more atomic. We could build on those.

Maybe we, over time of course, could manually write down (in JSON) sets of subgroups that produce nicely sized (~200 kb) sheet files. I could work on the runner program that generates sheets from this JSON config file, and I could also lay out an initial structure for such file.

btw I think this would be better in terms of UX if possible

Yes, I agree! There is lots of room for improvement. All improvements, like that accordion approach, are welcome. Pull requests are highly appreciated. But no pressure, good things mature over time.

Maybe further openmoji-sprites related discussion should took place in openmoji-sprites/issues? I created a couple of issues for starters, including your UX improvement.

[axelpale]

To provide a use case, here is an screenshot of a concept application of mine that became possible, performance-wise, thanks to the new sprite sheets. Only a single sheet image and a CSS file needed to be downloaded. This use case also provides a case where a SVG sprite sheet or a customised truetype font would be preferred over the PNG sheet that quickly becomes mushy when the user zooms in.

[Ryuno-Ki]

Chiming in here, as I asked on Twitter whether you would accept PRs.

My use case is using @axelpale's generator, but creating the color directory myself (instead of downloading it with wget). So far, I only saw SVGs, which the generator can't handle.

I'd create a PR to edit the README.md on how to generate those files (in either repo?).

Also, a list of available groups/subgroups would be highly helpful in combination with the generator. Do you need help here?

[carlinmack]

I think it would be best to add your information to axelpale's repo and we'll add a link to axelpale's repo to the Downloads & Distribution Channels section of the README. I think that makes the most sense :)

The groups and subgroups are primarily supplied through Unicode, but we could provide an openmoji interface to them through the npm package, please contribute to discussion in #191 if you have thoughts on this!

[carlinmack]

replying to @axelpale:

I can't promise but maybe there would be scope for us to maintain subgroups if these are well defined and distinct from the unicode ones. We should also think about if we would want to include emojis from extra-openmoji. There are some emoji here which would be useful, but any project that used them would have to recognise that they can't switch to another emoji set as they are non-standard.

The fractal password is a very cool use of the emoji!

[b-g]

Discussion seems to be done. Closing. Please re-open if there is anything to add.

[axelpale]

@b-g Yes, I guess so. I would love to see the generator or the sprites mentioned somewhere with an alpha stage tag. Although they are still in alpha and I haven't yet shared the ownership with you, some publicity would give these repos momentum and invaluable feedback for further development.

[b-g]

@axelpale Of course + Sorry! Was thinking we had already added a link ... done: https://github.com/hfg-gmuend/openmoji/commit/bb875248b03a83ac29baa82f049ff19e78495a6e

[axelpale]

Great, thank you.