I don’t see a large visible change (in fact, I don’t see one at all!). I assume this is because the two sets look very similar?
So I haven’t finished this yet, but Im close:
The basic idea is that fluent ui emoji all have a margin around the image to allow for various shapes. The needed margin is variable, but they applied a fix value on every images, compare to other sets which have no margins, fluent ui set looks smaller because of this.
I have been working a pipeline to compute the most optimal bounding box for each emoji, which should result in a larger and smoother emoji. I hope to have this merged tomorrow.
Sweet! Is that the same for all of the sets? I ask because the reactions on your site are quite a bit larger than the ones on mine. Currently letting the users try out Twemoji. This is the same monitor and same browser side by side. Open in a new tab to see biggie sized.
no only openmoji is also affected by this afaik. I will have to look at your site to understand the difference.
I looked and it’s related to your theme which has this css:
html {
font-family: ember-regular, sans-serif;
font-size: 14px;
}
The size of the emojis are relative to the base font-size, so in your case you have reduced the base font-size and as a result your emojis are smaller.
Got it. Thanks for taking a look!
I dont understand how this is rolled out. On my 3.5.0.beta2-dev the “Twitter” set is currently active with Apple, Google, Windows 10, Google Classic and Facebook Messenger as selections. Will I see the new options after a new deployment of the web container?
Second question: how can I add the openmoji set? (fun fact: the university who designed this is located a few kilometers from my home in SW Germany)
Yes you are apparently missing the most recent commits.
Openmoji will already be available in the list for you when you update. However, openmoji is quite challenging due to their choice of having a large margin, the set looks quite small. I’m trying to apply a similar solution to the one I used for fluentui, but due to some differences on how svgs are defined, it’s not working as good for now.
After all these years of enjoying the visuals of the Apple emojis on our Discourse, can I ask what these licensing reasons were that have caused them to suddenly go away, please?
We don’t have explicit authorization to use them.
Is there any way to add apple emoji as a custom emoji set and then select that set as default emoji?
So that existing messages don’t lose their appearance?
Not at the moment sorry, we might make it easier to add your own set in the future if you want to though, but I wouldn’t expect it soon.
I’d happily co-sponsor this on Marketplace if you want to discuss @taravasya ?
Technically doable per
The feedback we’re getting for losing the old Apple set is really bad.
I’ll check this out, thanks
Seems simple enough to implement, are there any details or guides on naming conventions for the emoji images?
Might I find the answer to that in a commit that lists all the images that were deleted from the repo?
Sorry I can’t reply in your linked topic, it’s locked
I managed to get most of the Apple emojis back and working after following that guide but there are a whole bunch of 404s being thrown.
Things like :grinning_face:
and
:weary_cat:
and
:kissing_face:
are throwing a 404/Not found because they don’t exist in the Apple set at discourse/public/images/emoji/apple at stable · discourse/discourse · GitHub
Have turned it off again for now.
We do a lot of things to ensure max compat, if you want to go the custom way, you will have to handle various issues like this.
I think the easiest way to resolve the 404s might be to copy/paste the entire Twemoji set over the top of the /apple/
folder and tell it not to replace if the image if it already exists.
Open to suggestions though if anyone else is trying to resolve this too
yes it’s what we do in the gem, we copy from unicode as unicode is supposed to always have the image as they are the source reference