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

Safari on maxOS does not render all header bar emojis #38

Closed
Alen3000 opened this issue Mar 14, 2024 · 7 comments
Closed

Safari on maxOS does not render all header bar emojis #38

Alen3000 opened this issue Mar 14, 2024 · 7 comments

Comments

@Alen3000
Copy link

At a quick glance this includes:

  • Prefetch (U+1F5F2)
  • Refresh (U+1F5D8)
  • Menu in thread watcher (U+1F783)

Additionally, the emojis seem have to varying sizes.

image

Appreciate that Font Awesome is bloat, but it may not be an unreasonable use case to inline some simple, sensibly licensed SVG icons or similar, or finding some other, better way of normalising sizes.

@saxamaphone69
Copy link

Perhaps emoji/unicode icons need a specific font stack to ensure consistent rendering. 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji' somewhere? Though when an emoji version doesn't exist, I dunno.

@TuxedoTako
Copy link
Owner

On windows, the emoji are from Segoe UI Symbol, Segoe UI Emoji is for multi colored pictures instead of the symbols in the fonts color.

I don't have an apple device to test on, so I can't check what font stack would have that effect on mac.

@Alen3000
Copy link
Author

Alen3000 commented Mar 15, 2024

At a glance it seems like it's just inheriting the font-family from whatever theme is picked, by default the yotsuba themes use font-family: arial, helvetica, sans-serif.

Setting font-family: 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji' seems to only really make the reply icon appear more consistent by using a coloured emoji:

When trying to use the characters elsewhere in the system they don't seem to render nicely either. Perhaps it may be worth considering alternative characters, if you don't fancy embedding icons?

Could consider setting the font family as per #38 (comment) and replacing:

  • "🗘" with "🔄"
  • "🗲︎" with "⚡️"

I'm not sure if there's a nice way of rendering these replacements in a monochromatic fashion on Windows/Linux, however.

@TuxedoTako
Copy link
Owner

Could consider setting the font family as per #38 (comment) and replacing:

Just to be clear, I'm on windows, and the header icons look like this on windows:

msedge_eWny6KwA5G

The monochrome icons are from Segoe UI Symbol, which is why that has to be before Segoe UI Emoji. I'm hoping to find an Segoe UI Symbol equivalent on mac, but because I don't own one, I can't test mac font stacks myself myself.

Could consider setting the font family as per #38 (comment) and replacing:

On windows, those look like this:

Without Segoe UI Symbol:

image

With Segoe UI Symbol:

msedge_bQUQ2mOEkr

So those are usable, but that doesn't change the fact that a lot of icons are colored emoji on mac. It might also be broken on Linux.

If we can't find a good font for mac, I'm considering using the icons from ccd0#2395. I would prefer if apple has a good icon font I can put in the stack, but picking and choosing icons is better than including all of of font awesome at least.

TuxedoTako added a commit that referenced this issue Apr 1, 2024
…rting the icons needed instead of the while icon font. [#38](#38)
@TuxedoTako
Copy link
Owner

Since no apple user provided a good icon font, I'm switching back to font awesome. But this time only importing the icons that are actually used.

This will be in the next release, soonish. Code is already in the repo.

@TuxedoTako
Copy link
Owner

Moved back to Font Awesome in 2.7.0.

@saxamaphone69
Copy link

Screenshot 2024-05-22 at 6 41 27 pm

FWIW, the menu icon at the end of posts and the thread watcher doesn't render on macOS/iOS either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants