Gitea 1.14.1 broke some symbols, apparently in a font change #444

libBletchley commented 2021年05月10日 23:27:27 +02:00

Gitea 1.14.1 broke some fonts. Notice all the boxes in the sample below. Those boxes were symbols that rendered correctly when in version 1.13.6.

BTW, I would report this upstream if it didn't involve MS Github.

---

Edit by fnetX: minimal example instead of four long black-/ graylists.

🐘 👌 🚨 🔎 🚓 👁

---

Note that Gitea 1.14.X broke some browsers but not others.

browser	Gitea 1.13.6	Gitea 1.14.1
Firefox	works	works
Tor Browser (not ver 10.0.16)	works	broken
Ungoogled Chromium (ver 72.0.3626.122)	works	broken

Gitea 1.14.1 broke some fonts. Notice all the boxes in the sample below. Those boxes were symbols that rendered correctly when in version 1.13.6. BTW, I would report this upstream if it didn't involve MS Github. ------------ Edit by fnetX: minimal example instead of four long black-/ graylists. 🐘 👌 🚨 🔎 🚓 👁 ---------------------- Note that Gitea 1.14.X broke some browsers but not others. | ***browser*** | Gitea 1.13.6 | Gitea 1.14.1 | |---|---|---| | Firefox | works | works | | Tor Browser (not ver 10.0.16) | works | broken | | Ungoogled Chromium (ver 72.0.3626.122) | works | broken |

fnetX commented 2021年05月11日 11:49:11 +02:00

whoa, no need to copy complete backlists, a minimal example is way more readable.

Who elese can reproduce this?

I think we have had some issues with FontAwesome, I don't know if this might be related?

I'm also missing the "Add checkbox" buttons in the comment editor (both, checked and unchecked). Didn't find the time to look into this yet.

whoa, no need to copy complete backlists, a minimal example is way more readable. Who elese can reproduce this? I think we have had some issues with FontAwesome, I don't know if this might be related? I'm also missing the "Add checkbox" buttons in the comment editor (both, checked and unchecked). Didn't find the time to look into this yet.

fnetX commented 2021年05月11日 11:50:37 +02:00

Just for clarification: Did you only notice this on Codeberg, or did you find it on another instance and only reported it here?

Just for clarification: Did you only notice this on Codeberg, or did you find it on another instance and only reported it here?

n commented 2021年05月11日 13:34:56 +02:00

Can't reproduce on all the browsers mentioned.

However I noticed that noticed on Tor Browser that numbers don't render. var(--fonts-emoji) as a font on the root element seems to be the culprit.

Can't reproduce on all the browsers mentioned. However I noticed that noticed on Tor Browser that numbers don't render. `var(--fonts-emoji)` as a font on the root element seems to be the culprit. 

fnetX commented 2021年05月11日 13:36:11 +02:00

The number thing was also reported via Mastodon, but I didn't manage to reproduce. Okay, that needs investigation!

The number thing was also reported via Mastodon, but I didn't manage to reproduce. Okay, that needs investigation!

libBletchley commented 2021年05月12日 15:20:39 +02:00

It's not just codeberg. That banking directory was correctly rendering for everyone in the beginning, then out of the blue the symbols became boxes, which happened after a migration to Gitea 1.14.1. It's an upstream bug but I have Github access problems. Hopefully an upstream developer will see this.

Tor Browser 10.0.16 works but I heard someone else using TB complain that the symbols were boxes. This is expected, since TB is based on Firefox and there seems to be a difference between different FF versions.

This is what it looks like in Ungoogled Chromium 72.0.3626:

It's not just codeberg. That [banking directory](https://git.disroot.org/cyberMonk/liberethos_paradigm/src/branch/master/usa_banks.md) was correctly rendering for everyone in the beginning, then out of the blue the symbols became boxes, which happened after a migration to Gitea 1.14.1. It's an upstream bug but I have Github access problems. Hopefully an upstream developer will see this. Tor Browser 10.0.16 works but I heard someone else using TB complain that the symbols were boxes. This is expected, since TB is based on Firefox and there seems to be a difference between different FF versions. This is what it looks like in Ungoogled Chromium 72.0.3626:

fnetX commented 2021年05月12日 15:36:17 +02:00

Okay, that makes sense now. Are you running the browsers in different environments (e. g. virtual machine, Qubes OS etc) where different fonts might be available?

I had an issue after 1.14 because a font installed on my system was corrupted (removing it solved the matter). But this would then affect all browsers which are in the same environment.

The font definition is this:

-apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla", sans-serif

Can you check which fonts are available? Or maybe use developer tools to remove some fonts from the CSS properties and check if that helps? Like, removing them one-by-one starting with the first and see if there might be some font in the order which does not support emoji or something.

I'll gladly forward your report to Gitea @ GitHub.

Okay, that makes sense now. Are you running the browsers in different environments (e. g. virtual machine, Qubes OS etc) where different fonts might be available? I had an issue after 1.14 because a font installed on my system was corrupted (removing it solved the matter). But this would then affect all browsers which are in the same environment. The font definition is this: ~~~ -apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla", sans-serif ~~~ Can you check which fonts are available? Or maybe use developer tools to remove some fonts from the CSS properties and check if that helps? Like, removing them one-by-one starting with the first and see if there might be some font in the order which does not support emoji or something. I'll gladly forward your report to Gitea @ GitHub.

libBletchley commented 2021年05月12日 15:38:52 +02:00

Demo of the same version of Ungoogled Chromium working with Gitea 1.13.6:

https://git.slashdev.space/garrit/slashdev.space/issues/6#issuecomment-28

Demo of the same version of Ungoogled Chromium working with Gitea 1.13.6: https://git.slashdev.space/garrit/slashdev.space/issues/6#issuecomment-28

fnetX commented 2021年05月12日 15:39:24 +02:00

I assume you already checked https://try.gitea.io to see if it is reproducible there? If not, could you please do so?

I assume you already checked https://try.gitea.io to see if it is reproducible there? If not, could you please do so?

fnetX commented 2021年05月12日 15:45:57 +02:00

Upstream: https://github.com/go-gitea/gitea/issues/15844

Upstream: https://github.com/go-gitea/gitea/issues/15844

libBletchley commented 2021年05月12日 15:54:27 +02:00

I'm working natively outside of a VM. Are we talking system fonts or browser-specific fonts? Since one browser renders the symbols and another does not, both running natively on the same system, I wouldn't have thought it's a systemwide issue. But perhaps some versions of FF bring their own fonts and other FF versions rely on system fonts.

What command gives the font list you're asking for? something like xfontsel?

I'm working natively outside of a VM. Are we talking system fonts or browser-specific fonts? Since one browser renders the symbols and another does not, both running natively on the same system, I wouldn't have thought it's a systemwide issue. But perhaps some versions of FF bring their own fonts and other FF versions rely on system fonts. What command gives the font list you're asking for? something like xfontsel?

libBletchley commented 2021年05月12日 15:55:46 +02:00

I assume you already checked https://try.gitea.io to see if it is reproducible there? If not, could you please do so?

https://try.gitea.io/JonasFranzDEV/drone-gitea-release/issues/2

> I assume you already checked https://try.gitea.io to see if it is reproducible there? If not, could you please do so? https://try.gitea.io/JonasFranzDEV/drone-gitea-release/issues/2

silverwind commented 2021年05月12日 15:58:31 +02:00

Please include the exact versions of the Operating System and Browser where the issue appears and whether you have manually installed any additional fonts into the system from below fonts:

-apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla", sans-serif

Please include the exact versions of the Operating System and Browser where the issue appears and whether you have manually installed any additional fonts into the system from below fonts: ```` -apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla", sans-serif ````

fnetX commented 2021年05月12日 16:02:28 +02:00

Okay, thanks.

What command gives the font list you're asking for? something like xfontsel?

Honestly, I don't know. Would've used some app like LibreOffice to check what is offered, or maybe some other font listing GUI (I think I got one preinstalled somewhere).

Are we talking system fonts or browser-specific fonts?

Fonts are really a weird thing. The main reason for me not using Chrome-based browsers is that I find all websites ugly when viewing there, they apparently do something different with font rendering. I'm not a fan of web frontend, I'm probably the wrong person to ask for details here. 🙈 ← see no evil monkey, in case it doesn't render for you xD

Okay, thanks. > What command gives the font list you're asking for? something like xfontsel? Honestly, I don't know. Would've used some app like LibreOffice to check what is offered, or maybe some other font listing GUI (I think I got one preinstalled somewhere). > Are we talking system fonts or browser-specific fonts? Fonts are really a weird thing. The main reason for me not using Chrome-based browsers is that I find all websites ugly when viewing there, they apparently do something different with font rendering. I'm not a fan of web frontend, I'm probably the wrong person to ask for details here. 🙈 ← see no evil monkey, in case it doesn't render for you xD

libBletchley commented 2021年05月12日 16:22:21 +02:00

Please include the exact versions of the Operating System and Browser where the issue appears and whether you have manually installed any additional fonts into the system from below fonts:

It's Debian stretch. It's old, but the person who reported Tor Browser breakage tends to be a chronic upgrader so he would be using something more current. The bug should be reproduceable under these conditions:

OS: Debian stretch
Browser: ungoogled-chromium_72.0.3626.122-3.stretch1_amd64.deb (based on Chromium 72.0.3626.122)
Gitea: 1.14.1

I didn't knowingly make font changes, but I installed LaTeX and DJVU which may have. When some apps like Gimp give a list of fonts, there are some with "djvu" in the name.

> Please include the exact versions of the Operating System and Browser where the issue appears and whether you have manually installed any additional fonts into the system from below fonts: It's Debian stretch. It's old, but the person who reported Tor Browser breakage tends to be a chronic upgrader so he would be using something more current. The bug should be reproduceable under these conditions: OS: Debian stretch Browser: ungoogled-chromium_72.0.3626.122-3.stretch1_amd64.deb (based on Chromium 72.0.3626.122) Gitea: 1.14.1 I didn't knowingly make font changes, but I installed LaTeX and DJVU which may have. When some apps like Gimp give a list of fonts, there are some with "djvu" in the name.

zeripath commented 2021年05月12日 18:02:25 +02:00

I bet you don't have the Noto Color Emoji fonts installed. Prior to 1.14.0 we would provide the Noto Color Emoji fonts as a webfont.

What is the output of:

fc-list | grep 'Noto Color Emoji'

---

You could install the fonts-noto-color-emoji package.

sudo apt install fonts-noto-color-emoji

which will provide you with an emoji font.

I bet you don't have the Noto Color Emoji fonts installed. Prior to 1.14.0 we would provide the Noto Color Emoji fonts as a webfont. What is the output of: ```bash fc-list | grep 'Noto Color Emoji' ``` --- You could install the fonts-noto-color-emoji package. ```bash sudo apt install fonts-noto-color-emoji ``` which will provide you with an emoji font.

ashimokawa commented 2021年05月13日 10:04:54 +02:00

fonts-noto-color-emoji is not in Debian 9 (stretch). Debian 10 is out since almost 2 years ago. Debian 11 is in freeze and out soon.

Chromium 72 is unsupported for more than 2 years.

Honestly for me this issue is invalid.

fonts-noto-color-emoji is not in Debian 9 (stretch). Debian 10 is out since almost 2 years ago. Debian 11 is in freeze and out soon. Chromium 72 is unsupported for more than 2 years. Honestly for me this issue is invalid.

libBletchley commented 2021年05月13日 15:36:39 +02:00

@ashimokawa

fonts-noto-color-emoji is not in Debian 9 (stretch). Debian 10 is out since almost 2 years ago. Debian 11 is in freeze and out soon.

Actually Debian Stretch is still officially supported until June 2022. This is a red herring.

Chromium 72 is unsupported for more than 2 years.

It's 2 years old. Tools are not obsolete the instant a newer version is released.

Chronic upgrading is actually detrimental to security because new releases are rich in unknown bugs. Software that's a year or two behind the curve has had a larger portion of the security bugs discovered and reported so that users and admins can control for them. You can't control for bugs you don't know about, which is why it's sensible to let the chronic upgraders (the suckers) take a hit for everyone else in the bug discovery process.

It's not sensible for Gitea to be allowed to fail interoperabity with software that is still officially supported even when the end of the lifecycle is near. Moreover, when Stretch reaches end of life (which hasn't happend yet), there is still nothing wrong with continuing to interoperate with it.

Where does Gitea draw the line? If the line is drawn where you propose, that makes Gitea quite flimsy. Robust software interoperates with versions that are still officially supported, at a minimum.

Moreover, it's merely incidental that recent versions of 2 mainstream browsers decided to include Noto Color Emoji fonts. Who's to say that recent versions of other browsers took the same direction? It's inherently a bad idea to make Gitea dependant on all clients to take this direction.

The software interoperability principle that's lacking is:

"be rigid in compliance with constraints in your own software, but be generous and loose with expectations of external software".

This principle is paramount when it comes to web servers. I cannot reasonably tell everyone who visits my project to change their browsers.

Honestly for me this issue is invalid.

The points you've raised are invalid. The fonts were removed prematurely.

@zeripath

What is the output of: fc-list | grep 'Noto Color Emoji'

Nothing, as you've probably guessed. Thanks for getting to the bottom of this. And I appreciate the workaround.

But note that the workaround only solves the problem for me and whoever finds this issue. It's not just me. Another user said to me "your page just shows boxes". It's my readers who are stuffed. It would be unreasonable for Gitea devs to consiously decide that it's a good idea to make this kind of change and break tools that are still officially supported. So it would be interesting to know who removed the fonts and why.

The only fix here is for me to move my projects to Gitea forges that predate 1.14.0. This is the only way that I can serve all my readers. And that's not sustainable because when a forge upgrades I have to move the project again. I will eventually run out of forges and self-hosting an old Gitea version will be the only option.

I'm reopening because a good reason for "WONTFIX" wasn't given. I would appreciate it if someone would echo the new points above upstream before closing bug 444. Thanks!

@ashimokawa > fonts-noto-color-emoji is not in Debian 9 (stretch). Debian 10 is out since almost 2 years ago. Debian 11 is in freeze and out soon. Actually Debian Stretch is still officially supported until June 2022. This is a red herring. > Chromium 72 is unsupported for more than 2 years. It's 2 years old. Tools are *not* obsolete the instant a newer version is released. Chronic upgrading is actually detrimental to security because new releases are rich in unknown bugs. Software that's a year or two behind the curve has had a larger portion of the security bugs discovered and reported so that users and admins can control for them. You can't control for bugs you don't know about, which is why it's sensible to let the chronic upgraders (the suckers) take a hit for everyone else in the bug discovery process. It's not sensible for Gitea to be allowed to fail interoperabity with software that is still officially supported even when the end of the lifecycle is near. Moreover, when Stretch reaches end of life (which hasn't happend yet), there is still nothing wrong with continuing to interoperate with it. Where does Gitea draw the line? If the line is drawn where you propose, that makes Gitea quite flimsy. Robust software interoperates with versions that are still officially supported, at a minimum. Moreover, it's merely incidental that recent versions of 2 mainstream browsers decided to include Noto Color Emoji fonts. Who's to say that recent versions of other browsers took the same direction? It's inherently a bad idea to make Gitea dependant on all clients to take this direction. The software interoperability principle that's lacking is: ***"be rigid in compliance with constraints in your own software, but be generous and loose with expectations of external software".*** This principle is paramount when it comes to web servers. I cannot reasonably tell everyone who visits my project to change their browsers. > Honestly for me this issue is invalid. The points you've raised are invalid. The fonts were removed prematurely. @zeripath > What is the output of: `fc-list | grep 'Noto Color Emoji'` Nothing, as you've probably guessed. Thanks for getting to the bottom of this. And I appreciate the workaround. But note that the workaround only solves the problem for me and whoever finds this issue. It's not just me. Another user said to me "your page just shows boxes". It's my readers who are stuffed. It would be unreasonable for Gitea devs to consiously decide that it's a good idea to make this kind of change and break tools that are still officially supported. So it would be interesting to know who removed the fonts and why. The only fix here is for me to move my projects to Gitea forges that predate 1.14.0. This is the only way that I can serve all my readers. And that's not sustainable because when a forge upgrades I have to move the project again. I will eventually run out of forges and self-hosting an old Gitea version will be the only option. I'm reopening because a good reason for "WONTFIX" wasn't given. I would appreciate it if someone would echo the new points above upstream before closing bug 444. Thanks!

zeripath commented 2021年05月13日 15:50:11 +02:00

One option for Codeberg is to just edit the custom/header.tmpl to include a <style> that adds (I think this is correct - adjust as necessary): (for 1.14.x)

<style>
 @font-face {
 font-family: 'Noto Color Emoji';
 src: url('/NotoColorEmoji.eot'); /* IE9 Compat Modes */
 src: url('/NotoColorEmoji.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
 url('/NotoColorEmoji.woff2') format('woff2'), /* Super Modern Browsers */
 url('/NotoColorEmoji.woff') format('woff'), /* Pretty Modern Browsers */
 url('/NotoColorEmoji.ttf') format('truetype'), /* Chrome, Safari, Android, iOS */
 url('/NotoColorEmoji.svg#svgFontName') format('svg'); /* Legacy iOS */
 }
 /* And as discovered on #445 do this for "Noto Sans" too */
</style>

and then add the font files to the public/ directory. (for 1.15.x the urls should be /assets/NotoColorEmoji.* - again I think this is correct.)

Adding "Noto Sans" too will fix the issue with numbers.

One option for Codeberg is to just edit the `custom/header.tmpl` to include a `<style>` that adds (I think this is correct - adjust as necessary): (for 1.14.x) ```html <style> @font-face { font-family: 'Noto Color Emoji'; src: url('/NotoColorEmoji.eot'); /* IE9 Compat Modes */ src: url('/NotoColorEmoji.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('/NotoColorEmoji.woff2') format('woff2'), /* Super Modern Browsers */ url('/NotoColorEmoji.woff') format('woff'), /* Pretty Modern Browsers */ url('/NotoColorEmoji.ttf') format('truetype'), /* Chrome, Safari, Android, iOS */ url('/NotoColorEmoji.svg#svgFontName') format('svg'); /* Legacy iOS */ } /* And as discovered on #445 do this for "Noto Sans" too */ </style> ``` and then add the font files to the `public/` directory. (for 1.15.x the urls should be `/assets/NotoColorEmoji.*` - again I think this is correct.) Adding "Noto Sans" too will fix the issue with numbers.

fnetX commented 2021年05月13日 15:52:47 +02:00

The issue was closed because of an internal testing commit that was supposed to improve the situation, but didn't (auto close via commit message).

I think the main point ashimokawa tried to raise was that if you decide to use legacy software that does not yet properly handle Emoji, this is your choice. I agree, that nowadays most Computers should have Emoji fonts on their system.

If not, then it's more a question of the user who should consider changing the system or adding some.

The delivery of this kind of fonts was a workaround over years, but it comes with reduced speed and increased load times. We want web software to be fast and loading a lot of webfonts is nothing that helps in this situation.

So I agree that this issue could be considered invalid and is more of a client-side issue.

Please note: We did fix another font issue with Tor Browsers, because this indeed is a big issue. If you're lucky, this also improves situation for you. If not ... you might want to go ahead and come up with a good fix, but honestly, looking at these 1.6k issues in the Gitea tracker, there are more important tasks (also for accessibility) than providing missing Emoji to a subset of legacy software lovers - they are also not really necessary. I think I could also live without and do in some desktop software that does not care about them, too.

The issue was closed because of an internal testing commit that was supposed to improve the situation, but didn't (auto close via commit message). I think the main point ashimokawa tried to raise was that if you decide to use legacy software that does not yet properly handle Emoji, this is your choice. I agree, that nowadays most Computers should have Emoji fonts on their system. If not, then it's more a question of the user who should consider changing the system or adding some. The delivery of this kind of fonts was a workaround over years, but it comes with reduced speed and increased load times. We want web software to be fast and loading a lot of webfonts is nothing that helps in this situation. So I agree that this issue could be considered invalid and is more of a client-side issue. Please note: We *did* fix another font issue with Tor Browsers, because this indeed is a big issue. If you're lucky, this also improves situation for you. If not ... you might want to go ahead and come up with a good fix, but honestly, looking at these 1.6k issues in the Gitea tracker, there are more important tasks (also for accessibility) than providing missing Emoji to a subset of legacy software lovers - they are also not really necessary. I think I could also live without and do in some desktop software that does not care about them, too.

fnetX commented 2021年05月13日 16:00:04 +02:00

One option for Codeberg

As I understood, this issue was primarily opened because the OP encountered this on another instance. So this should either be addressed upstream or closed.

If you are looking for an old version of Gitea, the oldest one I know about is at https://de.edumat.io/ - beware of some security issues.

> One option for Codeberg As I understood, this issue was primarily opened because the OP encountered this on another instance. So this should either be addressed upstream or closed. If you are looking for an old version of Gitea, the oldest one I know about is at https://de.edumat.io/ - beware of some security issues.

silverwind commented 2021年05月13日 16:15:18 +02:00

The removal of the Noto Color emoji fallback in 1.14 also has to do with Firefox being unable to parse the .ttf file, so that fallback only really worked on Linux in Chromium-based browsers.

So since 1.14 Gitea does expect the browser or operating system to have one of the emoji fonts installed.

The removal of the Noto Color emoji fallback in 1.14 also has to do with Firefox being unable to parse the .ttf file, so that fallback only really worked on Linux in Chromium-based browsers. So since 1.14 Gitea does expect the browser or operating system to have one of the emoji fonts installed.

fnetX commented 2021年05月13日 18:24:45 +02:00

@libBletchley Please simply reach out to the Gitea host of your choice and discuss the options mentioned here with them. That is, including the necessary webfonts as described above.

I think, here at Codeberg we keep it as a wontfix unless more users reach out in this matter (as far as we understand, you are were not using Codeberg recently?).

There is a high amount of work and there are more pressing issues that are open for too long, we are glad for any helping hand, but demanding fixes for legacy compatibility that only affects a small subset is no option for us while we all have to keep an eye to our limited time.

Lastly, we cannot recommend using outdated software (that is, client-side as well as choosing git hosting that uses outdated Gitea versions with severe (!) security issues) for the pleasure of correctly rendering emoji. Use ASCII emoji for compatibility instead if your system does not yet support the unicode ones :-)

@libBletchley Please simply reach out to the Gitea host of your choice and discuss the options mentioned here with them. That is, including the necessary webfonts as described above. I think, here at Codeberg we keep it as a wontfix unless more users reach out in this matter (as far as we understand, you are were not using Codeberg recently?). There is a high amount of work and there are more pressing issues that are open for too long, we are glad for any helping hand, but demanding fixes for legacy compatibility that only affects a small subset is no option for us while we all have to keep an eye to our limited time. Lastly, we cannot recommend using outdated software (that is, client-side as well as choosing git hosting that uses outdated Gitea versions with severe (!) security issues) for the pleasure of correctly rendering emoji. Use ASCII emoji for compatibility instead if your system does not yet support the unicode ones :-)

libBletchley commented 2021年05月14日 15:20:09 +02:00

Lastly, we cannot recommend using outdated software

Debian Stretch is still officially supported until June 2022. Even the previous version (Debian 8: jessie) has official support for another month. It actually harms the security of users to impose software versions that have not yet matured.

It's also wrong to say font inclusion is a matter of software age. FF & Chromium have added fonts-noto-color-emoji which makes browser age purely incidental. Not all browser engineers would have made the same decision. What about less mainstream browsers that are designed to be lightweight? It's a bad idea to marignalize users of standards-conforming-but-not-mainstream browsers.

Do we really want a world of just two browser choices?

for the pleasure of correctly rendering emoji. Use ASCII emoji for compatibility instead if your system does not yet support the unicode ones :-)

It's not just what I'm using; it's what Codeberg is using (see attached). Perhaps Codeberg should swap out the 4 broken ones that are hard-coded in the issue tracker, because it's not just a matter of "pleasure". It's a matter of understanding ideas that people are trying to convey.

And this decision was made to eek out a bit of performance? Poor decision making all around. Surely the performance gain is only felt on the minority of users who are being marginalized, no? If your browser already has the fonts-noto-color-emoji, why would it still download it from the web server? It's most likely a false efficiency.

I suggest reopening to at least change the hard-coded issue tracker emoji to use ASCII emoji.

> Lastly, we cannot recommend using outdated software Debian Stretch is still officially supported until June 2022. Even the previous version (Debian 8: jessie) has official support for another month. It actually harms the security of users to impose software versions that have not yet matured. It's also wrong to say font inclusion is a matter of software age. FF & Chromium have added fonts-noto-color-emoji which makes browser age purely incidental. Not all browser engineers would have made the same decision. What about less mainstream browsers that are designed to be lightweight? It's a bad idea to marignalize users of standards-conforming-but-not-mainstream browsers. Do we really want a world of just two browser choices? > for the pleasure of correctly rendering emoji. Use ASCII emoji for compatibility instead if your system does not yet support the unicode ones :-) It's not just what I'm using; it's what Codeberg is using (see attached). Perhaps Codeberg should swap out the 4 broken ones that are hard-coded in the issue tracker, because it's not just a matter of "pleasure". It's a matter of understanding ideas that people are trying to convey. And this decision was made to eek out a bit of performance? Poor decision making all around. Surely the performance gain is only felt on the minority of users who are being marginalized, no? If your browser already has the fonts-noto-color-emoji, why would it still download it from the web server? It's most likely a false efficiency. I suggest **reopening** to at least change the hard-coded issue tracker emoji to use ASCII emoji.

6543 commented 2021年05月15日 15:48:04 +02:00

Ok looks like related chat is now ongoing in #445

Ok looks like related chat is now ongoing in #445

libBletchley commented 2021年07月02日 05:04:09 +02:00

Also broken on the latest Ungoogled Chromium, version 90.0.4430.212. Sample attached.

Version 15 also fails to render icons when visiting:

https://try.gitea.io/JonasFranzDEV/drone-gitea-release/issues/2

Also broken on the latest Ungoogled Chromium, version 90.0.4430.212. Sample attached. Version 15 also fails to render icons when visiting: https://try.gitea.io/JonasFranzDEV/drone-gitea-release/issues/2

Ghost commented 2021年07月02日 08:26:18 +02:00

Works for me on here on codeberg and on try.gitea.io

Do you have the "Noto Color Emoji" font installed as mentioned in #444 (comment)?

Works for me on here on codeberg and on try.gitea.io Do you have the "Noto Color Emoji" font installed as mentioned in https://codeberg.org/Codeberg/Community/issues/444#issuecomment-197923?

libBletchley commented 2021年07月02日 23:16:26 +02:00

@rwa I do not. Installing that might fix the problem for me, but it certainly will not fix it for all my readers. And it would be unreasonable for me to tell others to install special packages just to use my repository because stock browsers don't work. If I were an exclusive kind of elitist person, I might have chosen Github or Gitlab.com. The reason I chose gitea in the 1st place was to be available to all.

It would be irresponsible for me to install extra excluded frills that my users/vistors may not have. I would rather run a stock browser so that I see what others see, so that I can see and avoid defects like this one introduced in gitea v.14.

So it seems in order to be inclusive for everybody, I must maintain my repos on Gitea 13.x. And when pre-14.0 gitea forges suffer from obsolescence, i'll have to switch to Gitlab CE or something. I won't like imposing javascript, but OTOH it won't be as extraordinary as expecting users to install separate font packages.

I might like to install fonts-noto-color-emoji to view pages not under my control, but then I would also need to create profiles in ungoogled chromium and in firefox that excludes fonts-noto-color-emoji so I can still see how unmanipulated browsers render sites that are under my control.

I wonder how the computer science discipline has eroded to developers who don't care about interoperability & how others are impacted by their OCD-driven optimizations at the cost of excluding some people. It's reckless and unethical.

@rwa I do not. Installing that might fix the problem for me, but it certainly will not fix it for all my readers. And it would be unreasonable for me to tell others to install special packages just to use my repository because stock browsers don't work. If I were an exclusive kind of elitist person, I might have chosen Github or Gitlab.com. The reason I chose gitea in the 1st place was to be available to all. It would be irresponsible for me to install extra excluded frills that my users/vistors may not have. I would rather run a stock browser so that I see what others see, so that I can see and avoid defects like this one introduced in gitea v.14. So it seems in order to be inclusive for everybody, I must maintain my repos on Gitea 13.x. And when pre-14.0 gitea forges suffer from obsolescence, i'll have to switch to Gitlab CE or something. I won't like imposing javascript, but OTOH it won't be as extraordinary as expecting users to install separate font packages. I might like to install fonts-noto-color-emoji to view pages not under my control, but then I would also need to create profiles in ungoogled chromium and in firefox that excludes fonts-noto-color-emoji so I can still see how unmanipulated browsers render sites that are under my control. I wonder how the computer science discipline has eroded to developers who don't care about interoperability & how others are impacted by their OCD-driven optimizations at the cost of excluding some people. It's reckless and unethical.

zeripath commented 2021年07月03日 01:09:00 +02:00

@libBletchley please see #444 (comment) for how to change your header css to provide the webfont.

@libBletchley please see https://codeberg.org/Codeberg/Community/issues/444#issuecomment-198198 for how to change your header css to provide the webfont.

libBletchley commented 2021年07月03日 05:16:31 +02:00

@zeripath That will only work if I'm in control of the instance. Although perhaps I can persuay other admins to patch that in.

You may have helped answer my other question about how I can install the font for my own browser, and yet have a profile that's deliberately missing the font to see what others see: I could perhaps make changes to userContent.css that would remove the font from a particular profile.

I appreciate the suggestion.

@zeripath That will only work if I'm in control of the instance. Although perhaps I can persuay other admins to patch that in. You may have helped answer my other question about how I can install the font for my own browser, and yet have a profile that's deliberately missing the font to see what others see: I could perhaps make changes to userContent.css that would remove the font from a particular profile. I appreciate the suggestion.

zeripath commented 2021年07月03日 11:38:38 +02:00

Looking at your screenshot I think those emoji that you are seeing are coming from the DejaVu Sans font and I think you have your Sans font set as DejaVu?

One thing to be aware of is that the DejaVu Sans font annoyingly contains some emoji characters (e.g. 😁 ) which means if DejaVu Sans is set as Sans it will override the Noto Color Emoji font.

The project appears dead and no-one has responded to the multiple requests asking for these characters to be removed from the base set for compatibility. This really is a shame as I really like the form and shape of the DejaVu font but it's just not going to work in future - this is not just Gitea, if you have time and inclination you could try contacting the debian developer - assuming the package isn't orphaned - to get them to remove these glyphs from base Sans font and instead split them out to a lower priority Emoji font.

Looking at your screenshot I think those emoji that you are seeing are coming from the DejaVu Sans font and I think you have your Sans font set as DejaVu? One thing to be aware of is that the DejaVu Sans font annoyingly contains some emoji characters (e.g. 😁 ) which means if DejaVu Sans is set as Sans it will override the Noto Color Emoji font. The project appears dead and no-one has responded to the multiple requests asking for these characters to be removed from the base set for compatibility. This really is a shame as I really like the form and shape of the DejaVu font but it's just not going to work in future - this is not just Gitea, if you have time and inclination you could try contacting the debian developer - assuming the package isn't orphaned - to get them to remove these glyphs from base Sans font and instead split them out to a lower priority Emoji font.

libBletchley commented 2022年03月28日 09:58:49 +02:00

Still broken. This blog suggests using a Local Font Access API:

https://web.dev/local-fonts/

Still broken. This blog suggests using a _Local Font Access API_: https://web.dev/local-fonts/

fnetX commented 2022年03月29日 10:11:03 +02:00

Which apparently must be enabled by the user in their browser settings, "and it would be unreasonable for me to tell others to" play with their browser settings.

Sorry, if someone wants to see emoji, they should bring their operating system in a state that it supports emoji. We can't provide a workaround for everyone.

Which apparently must be enabled by the user in their browser settings, ["and it would be unreasonable for me to tell others to"](https://codeberg.org/Codeberg/Community/issues/444#issuecomment-238776) play with their browser settings. Sorry, if someone wants to see emoji, they should bring their operating system in a state that it supports emoji. We can't provide a workaround for everyone.

libBletchley commented 2022年03月29日 23:11:14 +02:00

I didn't realize the Local Font Access API required a user-side intervention. If that’s the case then indeed that’s a bad idea for the same reason that the status quo is a bad idea.

Sorry, if someone wants to see emoji, they should bring their operating system in a state that it supports emoji.

Forcing users to do an OS migration to make a gitea website functional would be the most reckless approach to take. It neglects to grasp the impact & complexity of an OS migration on users who use more apps than just a browser.

It’s not that users "want to see emoji", it's that they don't want to see empty boxes in place of communication that carries meaning.

Filtering out the characters that are not universal would also fix the problem, as the author would be forced to communicate with an expression that reaches everyone.

We can't provide a workaround for everyone.

This was proven to be false, as Gitea 1.13.7 and earlier worked for everyone.

Also the emoji that is hard-coded into the UI when clicking the emoji reaction icon can (and should) be replaced with symbols that are commonly available:

https://codeberg.org/attachments/e3a8375b-edfb-4eef-8e99-08492162a9ca

I didn't realize the Local Font Access API required a user-side intervention. If that’s the case then indeed that’s a bad idea for the same reason that the status quo is a bad idea. > Sorry, if someone wants to see emoji, they should bring their operating system in a state that it supports emoji. Forcing users to do an OS migration to make a gitea website functional would be the most reckless approach to take. It neglects to grasp the impact & complexity of an OS migration on users who use more apps than just a browser. It’s not that users "want to see emoji", it's that they don't want to see empty boxes in place of communication that carries meaning. Filtering out the characters that are not universal would also fix the problem, as the author would be forced to communicate with an expression that reaches everyone. > We can't provide a workaround for everyone. This was proven to be false, as Gitea 1.13.7 and earlier worked for everyone. Also the emoji that is hard-coded into the UI when clicking the emoji reaction icon can (and should) be replaced with symbols that are commonly available: https://codeberg.org/attachments/e3a8375b-edfb-4eef-8e99-08492162a9ca