Emoji rendering in copy/save to HTML

[alexrussell]

Now that Atom has decided to use the asar format, any export-to-HTML function includes links to /Applications/Atom.app/Contents/Resources/app.asar/node_modules/roaster/node_modules/emoji-images/pngs/[emoji].png which don't work due to the app.asar file not being a directory as the filesystem sees it. (Also, as a side note, should these actually be file:// URLs? Converting them to file:// URLs doesn't affect anything in the rendered HTML - the images still don't appear - but it feels more correct.)

Potential solutions:

• Convert any internal images used into base64 versions
• Use external URLs (and a compatible service that will allow 'hotlinking') for emoji
• Use actual emoji unicode? (Though this cannot currently be printed from the Chrome browser, which is my use-case.)

[tonka3000]

Have the same problem. I think a base64 solution would be the best because the hole markdown export is inline.

[hrafnkelle]

Seeing this issue as well

[Joinyy]

Any news on this one?

[alexrussell]

A quick test I just did suggests that the issue is still there for any emoji that uses the colon syntax (e.g. :sparkles:). However, if you use true emoji (e.g. 👽) it just exports the UTF-8 codepoints in the HTML and it works fine.

So for now a quick fix is to not use the github emoji syntax but just use emoji directly. It'd still be good if this package (although it's probably a markdown parsing package that this package relies upon) converted the colon syntax into UTF-8 codepoints rather than using images.

[Joinyy]

Okay that's nice.

So i will search a cheatsheet gt UTF8 emojis 😄

[alexrussell]

If you happen to be on a Mac, ctrl+cmd+space (or Edit → Emoji & Symbols) will help you out no end. Windows I'm not sure about.

[50Wliu]

Well, this is completely broken even when simply rendering now that we block all unknown protocols by default.

I like the last option the best because all the emoji -> image libraries I found (including the one we are using currently) are either unmaintained or require an online URL. However, like you mentioned, the emoji conversion happens in a dependency, which also happens to be unmaintained.

[nathansobo]

If I understand this issue correctly, it sounds like the best solution would be to convert shorthand like :poop: to actual unicode code points rather than images. Chrome now knows how to render these correctly.

If someone wants to open a pull request and link it from this issue, we'd prioritize giving it a look.

[alexrussell]

@nathansobo you say that Chrome now knows how to render Emoji correctly. While I can't even remember anything that brought this issue on, if I read my issue description correctly the issue wasn't screen rendering, but printing (possibly, in my case, to PDF, but that's beside the point).

So are you saying that Chrome (well, Electron) can now print these correctly? If so, then yes, that is the best bet for these things AFAICT.

[nathansobo]

I think it's that we render HTML that makes references to images inside the ASAR, when instead we should just render HTML that contains Unicode escape sequences for the correct emoji characters.

[alexrussell]

Yup, rereading my original issue report, the Chrome thing I mentioned is not (as I thought in my last comment here) about Electron supporting PDF output of the markdown preview, but simply my own use-case of loading the generated HTML in Chrome and then printing to PDF. While that's a legitimate worry (if Emoji doesn't print in Chrome) as I imagine it's not only my use-case, it's also not really for Atom devs to care too much about.

So yes, real Emoji codepoints!