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

Move sans-serif fallback font higher than emoji fonts #15855

Merged
merged 4 commits into from
May 16, 2021

Conversation

zeripath
Copy link
Contributor

@zeripath zeripath commented May 13, 2021

The Tor browser does not use the system-ui font and no other fonts in the stack match
its default fonts. In fact it is possible that it will in future only
match generic fonts. This means that all rendering will first try the
emoji fonts before falling back to the sans-serif font for glyphs.

In this case the emoji fall back font for Tor contains empty glyphs
for numbers - in order to protect privacy - and leads to numbers being
rendered as empty glyphs. This is clearly not ideal and whilst we could
use the Arimo font - as I state above I suspect that Tor will eventually
ban detecting this and we should instead move the sans-serif font higher
in the stack so that it matches before the emoji fonts.

Partial fix of #15844

Signed-off-by: Andrew Thornton art27@cantab.net

The Tor browser does not use the system-ui font and no other fonts in the stack match
its default fonts. In fact it is possible that it will in future only
match generic fonts. This means that all rendering will first try the
emoji fonts before falling back to the sans-serif font for glyphs.

In this case has the emoji fall back fonts for Tor contains empty glyphs
for numbers - in order to protect privacy - and leads to numbers being
rendered as empty glyphs. This is clearly not ideal and whilst we could
use the Arimo font - as I state above I suspect that Tor will eventually
ban detecting this and we should instead move the sans-serif font higher
in the stack so that it matches before the emoji fonts.

Partial fix of go-gitea#15844

Signed-off-by: Andrew Thornton <art27@cantab.net>
@codecov-commenter
Copy link

codecov-commenter commented May 13, 2021

Codecov Report

Merging #15855 (5bcab07) into main (e0c93fe) will increase coverage by 0.00%.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main   #15855   +/-   ##
=======================================
  Coverage   44.01%   44.02%           
=======================================
  Files         681      681           
  Lines       82333    82333           
=======================================
+ Hits        36241    36248    +7     
+ Misses      40189    40185    -4     
+ Partials     5903     5900    -3     
Impacted Files Coverage Δ
models/unit.go 46.57% <0.00%> (-2.74%) ⬇️
models/gpg_key.go 54.07% <0.00%> (+0.56%) ⬆️
modules/log/file.go 75.39% <0.00%> (+1.58%) ⬆️
modules/log/event.go 61.79% <0.00%> (+1.88%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e0c93fe...5bcab07. Read the comment docs.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label May 13, 2021
@silverwind
Copy link
Member

I wonder what happens if we remove emoji fonts completely from the font stack. I imagine browsers would have some sort of fallback mechanism if a glyph is not found in a font.

@zeripath
Copy link
Contributor Author

I really wouldn't make that assumption.

@zeripath zeripath added the topic/ui Change the appearance of the Gitea UI label May 13, 2021
@zeripath zeripath added this to the 1.15.0 milestone May 13, 2021
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels May 15, 2021
@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels May 15, 2021
@6543
Copy link
Member

6543 commented May 15, 2021

should we backport it to v1.14?

@6543 6543 merged commit 58646ca into go-gitea:main May 16, 2021
@zeripath zeripath deleted the fix-15844-move-sans-serif-up branch May 16, 2021 09:23
zeripath added a commit to zeripath/gitea that referenced this pull request May 16, 2021
Backport go-gitea#15855

The Tor browser does not use the system-ui font and no other fonts in the stack match
its default fonts. In fact it is possible that it will in future only
match generic fonts. This means that all rendering will first try the
emoji fonts before falling back to the sans-serif font for glyphs.

In this case has the emoji fall back fonts for Tor contains empty glyphs
for numbers - in order to protect privacy - and leads to numbers being
rendered as empty glyphs. This is clearly not ideal and whilst we could
use the Arimo font - as I state above I suspect that Tor will eventually
ban detecting this and we should instead move the sans-serif font higher
in the stack so that it matches before the emoji fonts.

Partial fix of go-gitea#15844

Signed-off-by: Andrew Thornton <art27@cantab.net>
lafriks pushed a commit that referenced this pull request May 16, 2021
Backport #15855

The Tor browser does not use the system-ui font and no other fonts in the stack match
its default fonts. In fact it is possible that it will in future only
match generic fonts. This means that all rendering will first try the
emoji fonts before falling back to the sans-serif font for glyphs.

In this case has the emoji fall back fonts for Tor contains empty glyphs
for numbers - in order to protect privacy - and leads to numbers being
rendered as empty glyphs. This is clearly not ideal and whilst we could
use the Arimo font - as I state above I suspect that Tor will eventually
ban detecting this and we should instead move the sans-serif font higher
in the stack so that it matches before the emoji fonts.

Partial fix of #15844

Signed-off-by: Andrew Thornton <art27@cantab.net>
@silverwind silverwind mentioned this pull request May 20, 2021
6 tasks
@6543 6543 added the backport/done All backports for this PR have been created label Jun 6, 2021
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this pull request Aug 10, 2021
The Tor browser does not use the system-ui font and no other fonts in the stack match
its default fonts. In fact it is possible that it will in future only
match generic fonts. This means that all rendering will first try the
emoji fonts before falling back to the sans-serif font for glyphs.

In this case has the emoji fall back fonts for Tor contains empty glyphs
for numbers - in order to protect privacy - and leads to numbers being
rendered as empty glyphs. This is clearly not ideal and whilst we could
use the Arimo font - as I state above I suspect that Tor will eventually
ban detecting this and we should instead move the sans-serif font higher
in the stack so that it matches before the emoji fonts.

Partial fix of go-gitea#15844

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport/done All backports for this PR have been created lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. topic/ui Change the appearance of the Gitea UI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants