[GH-ISSUE #92] Emoji in mail subjects are not displayed #62

Closed
opened 2026-03-15 12:20:50 +03:00 by kerem · 12 comments
Owner

Originally created by @LeoniePhiline on GitHub (Apr 17, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/92

Email subject emoji do show up in notifications:

grafik

But they are missing in the message list:

grafik

(Red indicator added to screenshot - not rendered in the browser.)

And in the message detail view:

grafik

(Red indicator added to screenshot - not rendered in the browser.)

However, they are found in the markup / DOM:

grafik

I would expect system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", "Noto Sans", "Liberation Sans", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji" to be sufficient. (--bs-body-font-family)

Emoji do render in the message body:

grafik


The message header (missing emoji) uses Noto Color emoji. Interestingly, the emoji font is mentioned first:

grafik

While the body (good emoji) uses Twemoji Mozilla:

grafik

Removing Noto Color emoji from the font face makes emoji show up:

grafik


Firefox 112, OpenSUSE Tumbleweed, Noto Color emoji is installed!

Originally created by @LeoniePhiline on GitHub (Apr 17, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/92 Email subject emoji do show up in notifications: ![grafik](https://user-images.githubusercontent.com/22329650/232597468-e77e4c7d-03f2-4d91-b018-0ff9a191ffc5.png) But they are missing in the message list: ![grafik](https://user-images.githubusercontent.com/22329650/232597571-b949c0a7-c50f-498e-916c-28962f313a63.png) (Red indicator added to screenshot - not rendered in the browser.) And in the message detail view: ![grafik](https://user-images.githubusercontent.com/22329650/232597810-3fa0d673-6e5e-49e3-9eb9-ed8b3d109811.png) (Red indicator added to screenshot - not rendered in the browser.) However, they are found in the markup / DOM: ![grafik](https://user-images.githubusercontent.com/22329650/232598017-09d3cd5d-bf42-46b8-8f0e-eba344771557.png) I would expect `system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", "Noto Sans", "Liberation Sans", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"` to be sufficient. (`--bs-body-font-family`) Emoji do render in the message body: ![grafik](https://user-images.githubusercontent.com/22329650/232598493-0e788dbb-d178-4a97-8385-6ff8353569ad.png) --- The message header (missing emoji) uses Noto Color emoji. Interestingly, the emoji font is mentioned first: ![grafik](https://user-images.githubusercontent.com/22329650/232599600-cfea4898-d8a6-4604-a97a-26484a4e2546.png) While the body (good emoji) uses Twemoji Mozilla: ![grafik](https://user-images.githubusercontent.com/22329650/232599706-2530dc78-2d7a-49a1-a6f0-66fb3fe073a2.png) Removing Noto Color emoji from the font face makes emoji show up: ![grafik](https://user-images.githubusercontent.com/22329650/232600148-5e1cc92b-96a7-48e3-835d-b362c80f5be0.png) --- Firefox 112, OpenSUSE Tumbleweed, Noto Color emoji is installed!
kerem 2026-03-15 12:20:50 +03:00
  • closed this issue
  • added the
    stale
    label
Author
Owner

@axllent commented on GitHub (Apr 17, 2023):

Could you please provide me with the message itself (feel free to edit the headers etc to make it anonymous, changing emails etc)? Download the message (in Mailpit), edit, zip and attach? Thanks

<!-- gh-comment-id:1512053456 --> @axllent commented on GitHub (Apr 17, 2023): Could you please provide me with the message itself (feel free to edit the headers etc to make it anonymous, changing emails etc)? Download the message (in Mailpit), edit, zip and attach? Thanks
Author
Owner

@LeoniePhiline commented on GitHub (Apr 17, 2023):

That should be no problem. However, I see this being an issue of the SPA, not the mail content.

I was able to "fix it" by removing Noto Color emoji from the --bs-body-font-family custom property defined on the mailpit UI.

Do you have the possibility to try and reproduce this issue with a linux desktop?

<!-- gh-comment-id:1512229803 --> @LeoniePhiline commented on GitHub (Apr 17, 2023): That should be no problem. However, I see this being an issue of the SPA, not the mail content. I was able to "fix it" by removing Noto Color emoji from the `--bs-body-font-family` custom property defined on the mailpit UI. Do you have the possibility to try and reproduce this issue with a linux desktop?
Author
Owner

@axllent commented on GitHub (Apr 18, 2023):

Yes I do use a Linux desktop (Ubuntu), but I would appreciate a sample message I can test with so I can try reproduce the issue and confirm a fix (or detect what the problem could be) :)

<!-- gh-comment-id:1512314645 --> @axllent commented on GitHub (Apr 18, 2023): Yes I do use a Linux desktop (Ubuntu), but I would appreciate a sample message I can test with so I can try reproduce the issue and confirm a fix (or detect what the problem could be) :)
Author
Owner

@LeoniePhiline commented on GitHub (Apr 28, 2023):

Hi! Just hopping in to let you know I didn’t forget- I just haven’t yet found the time. :)

<!-- gh-comment-id:1527478805 --> @LeoniePhiline commented on GitHub (Apr 28, 2023): Hi! Just hopping in to let you know I didn’t forget- I just haven’t yet found the time. :)
Author
Owner

@axllent commented on GitHub (May 3, 2023):

I found an email with an emoji (utf8 encoded) in a subject and it works fine on my system (Ubuntu 22.04). The emoji is rendered using Noto Color emoji, and if I remove that font from the CSS list Firefox falls back automatically to Twemoji Mozilla (which also works well).

I suspect that the issue here may be due to how your email subject is encoded. If your subject includes the emoji as-is then that may be the issue. My understanding is that the subject field is plain ASCII, and a if the subject requires something like a UTF8 symbol, then it should be encoded properly. Eg: my subject header actually says Subject: We're on a Sustainability journey =?UTF-8?B?8J+SmeKZu++4jw==?=.

<!-- gh-comment-id:1532545824 --> @axllent commented on GitHub (May 3, 2023): I found an email with an emoji (utf8 encoded) in a subject and it works fine on my system (Ubuntu 22.04). The emoji is rendered using Noto Color emoji, and if I remove that font from the CSS list Firefox falls back automatically to Twemoji Mozilla (which also works well). I suspect that the issue here may be due to how your email subject is encoded. If your subject includes the emoji as-is then that may be the issue. My understanding is that the subject field is plain ASCII, and a if the subject requires something like a UTF8 symbol, then it should be encoded properly. Eg: my subject header actually says `Subject: We're on a Sustainability journey =?UTF-8?B?8J+SmeKZu++4jw==?=`.
Author
Owner

@LeoniePhiline commented on GitHub (May 17, 2023):

Example mail:

de0b3dfa-e64c-4bbf-8fa7-09b222b4de85.zip

(Zipped .eml file, as GitHub only accepts a limited number of specific file extensions.)

Subject line encoding

Subject: =?utf-8?Q?=F0=9F=94=92?= Secret Cobytes credentials: Test (from test env)

Display in MailPit - emoji in subject line are invisible:

List view

image

Detail view

image

CSS font configuration

image

Display in MailHog - emoji in subject line are visible:

List view

image

Detail view

image

CSS font configuration

image

Debugging

Noto Color Emoji as remote webfont: Firefox renders Twemoji Mozilla instead

https://guoyunhe.me/demo/noto-color-emoji/

image

If I change the CSS on that page from "My Noto Color Emoji" (the webfont) to "Noto Color Emoji" (as local font from my linux desktop), then the emoji disappear.

Noto Color Emoji is installed

image

<!-- gh-comment-id:1551483112 --> @LeoniePhiline commented on GitHub (May 17, 2023): # Example mail: [de0b3dfa-e64c-4bbf-8fa7-09b222b4de85.zip](https://github.com/axllent/mailpit/files/11499037/de0b3dfa-e64c-4bbf-8fa7-09b222b4de85.zip) (Zipped `.eml` file, as GitHub only accepts a limited number of specific file extensions.) ## Subject line encoding `Subject: =?utf-8?Q?=F0=9F=94=92?= Secret Cobytes credentials: Test (from test env)` ## Display in MailPit - emoji in subject line are _invisible_: ### List view ![image](https://github.com/axllent/mailpit/assets/22329650/8b0d56d0-2676-44f9-bb8f-943fe4b46faa) ### Detail view ![image](https://github.com/axllent/mailpit/assets/22329650/87647191-4a7f-4eba-9313-1453c7fd4e7d) #### CSS font configuration ![image](https://github.com/axllent/mailpit/assets/22329650/5b7ab4d2-03ed-4f87-bf6e-c3ee808f2da8) ## Display in MailHog - emoji in subject line are _visible_: ### List view ![image](https://github.com/axllent/mailpit/assets/22329650/449c6a4b-d7ab-4f82-86be-2ebb4c73395c) ### Detail view ![image](https://github.com/axllent/mailpit/assets/22329650/75dc5d6a-57d0-4175-b036-00460f6a7ea7) #### CSS font configuration ![image](https://github.com/axllent/mailpit/assets/22329650/7c4f580f-aa7b-4561-8826-d183aef9ec40) # Debugging ## Noto Color Emoji as remote webfont: Firefox renders Twemoji Mozilla instead https://guoyunhe.me/demo/noto-color-emoji/ ![image](https://github.com/axllent/mailpit/assets/22329650/84a1173e-de57-4302-b96b-f5205cc0bfb5) If I change the CSS on that page from "My Noto Color Emoji" (the webfont) to "Noto Color Emoji" (as local font from my linux desktop), then the emoji disappear. ## Noto Color Emoji is installed ![image](https://github.com/axllent/mailpit/assets/22329650/76e4eefe-8eb8-459c-a5fc-c346efdc33a2)
Author
Owner

@LeoniePhiline commented on GitHub (May 17, 2023):

Further debugging, with some results:

https://bugzilla.mozilla.org/show_bug.cgi?id=1454152 inspired me to play with my ~/.config/fontconfig/fonts.conf.

Disabling the "antialias" edit mode font match rule as shown below made the emoji appear in the subject line:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <dir>~/.fonts</dir>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
  <!--match target="font">
    <edit mode="assign" name="antialias">
      <bool>true</bool>
    </edit>
  </match-->
  <match target="font">
    <edit mode="assign" name="lcdfilter">
      <const>lcddefault</const>
    </edit>
  </match>
  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>false</bool>
    </edit>
  </match>
  <match target="pattern"> 
    <edit name="family" mode="append"> 
      <string>Noto Color Emoji</string> 
    </edit> 
  </match>
</fontconfig>

Mismatching fonts

However, since the emoji-font is "hard-coded" in CSS (--bs-font-sans-serif), the fonts do not match up - the same emoji is rendered with two different fonts:

image

Fixing it

After removing the "hard-coded" emoji font from CSS...

image

... the emoji render as intended:

image

Solution

While I had a local problem with my fontconfig, the solution is still to remove hard-coded emoji fonts from CSS.

  • They are not commonly used (and emoji render anyway, as browsers / systems have default emoji fonts),
  • they are not necessary any more today, and
  • they are not even doing what they are intended to do.

Test page

https://www.fileformat.info/info/emoji/browsertest.htm - browsers render emoji without CSS emoji font specification. They use the emoji font configured on the system (e.g. firefox' about:config -> font.name-list.emoji.

<!-- gh-comment-id:1551593822 --> @LeoniePhiline commented on GitHub (May 17, 2023): # Further debugging, with some results: https://bugzilla.mozilla.org/show_bug.cgi?id=1454152 inspired me to play with my `~/.config/fontconfig/fonts.conf`. Disabling the `"antialias"` edit mode font match rule as shown below made the emoji appear in the subject line: ```xml <?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <dir>~/.fonts</dir> <match target="font"> <edit mode="assign" name="rgba"> <const>rgb</const> </edit> </match> <match target="font"> <edit mode="assign" name="hinting"> <bool>true</bool> </edit> </match> <match target="font"> <edit mode="assign" name="hintstyle"> <const>hintslight</const> </edit> </match> <!--match target="font"> <edit mode="assign" name="antialias"> <bool>true</bool> </edit> </match--> <match target="font"> <edit mode="assign" name="lcdfilter"> <const>lcddefault</const> </edit> </match> <match target="font"> <edit name="autohint" mode="assign"> <bool>false</bool> </edit> </match> <match target="pattern"> <edit name="family" mode="append"> <string>Noto Color Emoji</string> </edit> </match> </fontconfig> ``` ## Mismatching fonts However, since the emoji-font is "hard-coded" in CSS (`--bs-font-sans-serif`), the fonts do not match up - the same emoji is rendered with two different fonts: ![image](https://github.com/axllent/mailpit/assets/22329650/08e805b0-b9bc-4f35-99c8-8afbdd6e2c3c) ## Fixing it After removing the "hard-coded" emoji font from CSS... ![image](https://github.com/axllent/mailpit/assets/22329650/9d8f0b54-12e1-4cd2-92c0-9e91b0e0a8a6) ... the emoji render as intended: ![image](https://github.com/axllent/mailpit/assets/22329650/54f351ae-d894-4143-b0f8-2c100a428e0f) # Solution While I had a local problem with my `fontconfig`, **the solution is still to remove hard-coded emoji fonts from CSS**. - They are not commonly used (and emoji render anyway, as browsers / systems have default emoji fonts), - they are not necessary any more today, and - they are not even doing what they are intended to do. ## Test page https://www.fileformat.info/info/emoji/browsertest.htm - browsers render emoji without CSS emoji font specification. They use the emoji font configured on the system (e.g. firefox' `about:config -> font.name-list.emoji`.
Author
Owner

@axllent commented on GitHub (May 17, 2023):

@LeoniePhiline Thank you for the detailed report, I really appreciate that.

Mailpit is currently using the default bootstrap 5 font set, which applies to everything in the web UI with the exception of the actual rendered message (iframe / no bootstrap) and desktop notifications. This explains why it is working for the message view, but not in the mail overview, or header summary when opening the message. Clearly there is an issue with "Noto Color Emoji" on your system (ie: your test message works fine on my Ubuntu), however as you have demonstrated, it's actually not needed... at least not on our systems. Apparently you're not the only person with issues with that particular font, so it just seems odd to me that Bootstrap would include this by default (meaning you will have this issue on many bootstrap 5 sites).

I'm happy to remove it from the list of Mailpit CSS fonts as you have requested, and leave it out, provided I don't get bug reports from others that their emojis are not working for them (because the font is missing). I assume that Noto Color Emoji must be included for a compatibility reason, I just don't know for what. I'll see if I can get a release out later today for you 👍

<!-- gh-comment-id:1552119650 --> @axllent commented on GitHub (May 17, 2023): @LeoniePhiline Thank you for the detailed report, I really appreciate that. Mailpit is currently using the **default** bootstrap 5 font set, which applies to everything in the web UI with the exception of the actual rendered message (iframe / no bootstrap) and desktop notifications. This explains why it is working for the message view, but not in the mail overview, or header summary when opening the message. Clearly there is an issue with "Noto Color Emoji" on your system (ie: your test message works fine on my Ubuntu), however as you have demonstrated, it's actually not needed... at least not on our systems. Apparently you're not the only person with issues with that particular font, so it just seems odd to me that Bootstrap would include this by default (meaning you will have this issue on many bootstrap 5 sites). I'm happy to remove it from the list of Mailpit CSS fonts as you have requested, and leave it out, provided I don't get bug reports from others that their emojis are not working for them (because the font is missing). I assume that Noto Color Emoji must be included for a compatibility reason, I just don't know for what. I'll see if I can get a release out later today for you :+1:
Author
Owner

@LeoniePhiline commented on GitHub (May 17, 2023):

That could be real nice!

I believe all emoji fonts can be removed, including "Apple Color Emoji" and "Segoe UI".

Example https://guoyunhe.me/demo/noto-color-emoji/ on iOS renders with Apple Color Emoji even despite the custom emoji web font (which apparently is entirely ignored):

image

And https://www.fileformat.info/info/emoji/browsertest.htm which does not add emoji fonts to font-family, also renders emoji correctly on iOS:

image

I no longer have access to an Android phone to test with. Do you?

If you like, I can test on Windows 11 tomorrow, having dual boot set up.

In case you get bug reports about the emoji change (or other things I can help with), then please ping me and I'll be glad to help figure them out. :)

<!-- gh-comment-id:1552172778 --> @LeoniePhiline commented on GitHub (May 17, 2023): That could be real nice! I believe all emoji fonts can be removed, including "Apple Color Emoji" and "Segoe UI". Example https://guoyunhe.me/demo/noto-color-emoji/ on iOS renders with Apple Color Emoji even despite the custom emoji web font (which apparently is entirely ignored): ![image](https://github.com/axllent/mailpit/assets/22329650/fcc98142-618f-4e10-8179-bcf6fee31101) And https://www.fileformat.info/info/emoji/browsertest.htm which does not add emoji fonts to `font-family`, also renders emoji correctly on iOS: ![image](https://github.com/axllent/mailpit/assets/22329650/136468b3-f01e-4752-9baa-474b54b2cf88) I no longer have access to an Android phone to test with. Do you? If you like, I can test on Windows 11 tomorrow, having dual boot set up. In case you get bug reports about the emoji change (or other things I can help with), then please ping me and I'll be glad to help figure them out. :)
Author
Owner

@axllent commented on GitHub (May 17, 2023):

I do have Android, and can test with Windows 11, however I'd prefer at this stage not to remove all the emoji fonts for the sake of removing them (after all, they must be included by default for a reason). I have released 1.6.10 now - could you please test this and report whether it fixes it for you? Thank you.

<!-- gh-comment-id:1552194347 --> @axllent commented on GitHub (May 17, 2023): I do have Android, and can test with Windows 11, however I'd prefer at this stage not to remove all the emoji fonts for the sake of removing them (after all, they must be included by default for a reason). I have released 1.6.10 now - could you please test this and report whether it fixes it for you? Thank you.
Author
Owner

@github-actions[bot] commented on GitHub (Jun 8, 2023):

This issue is stale because it has been open for 21 days with no activity.

<!-- gh-comment-id:1581802974 --> @github-actions[bot] commented on GitHub (Jun 8, 2023): This issue is stale because it has been open for 21 days with no activity.
Author
Owner

@LeoniePhiline commented on GitHub (Jun 14, 2023):

Fixed with github.com/axllent/mailpit@d1edbe73b4 ♥️

<!-- gh-comment-id:1591683136 --> @LeoniePhiline commented on GitHub (Jun 14, 2023): Fixed with https://github.com/axllent/mailpit/commit/d1edbe73b42c45e6bd4c52e146641b46d159d97a ♥️
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#62
No description provided.