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

Use underline position and thickness value in font file #31086

Merged
merged 1 commit into from
May 7, 2020

Conversation

volzhs
Copy link
Contributor

@volzhs volzhs commented Aug 4, 2019

not just using constant 2 for position and 1 for thickness.

old on left, new on right.
underline_1

old on top, new on bottom.
underline_2

@volzhs volzhs added this to the 3.2 milestone Aug 4, 2019
@volzhs volzhs requested a review from akien-mga August 4, 2019 23:27
@Calinou
Copy link
Member

Calinou commented Aug 4, 2019

Today I learned fonts bundle their own underline position and thickness information 🙂

@YeldhamDev
Copy link
Member

@Calinou
test

@akien-mga
Copy link
Member

Seems good to me, though it breaks compat.
It should be fine for 3.2 if it's well documented in the changelog.

Is it configurable though? In the case of the builtin help, I think the thin underlines looked better than the thicker underlines from the font data.

@volzhs
Copy link
Contributor Author

volzhs commented Aug 5, 2019

might be configurable in the font data but not sure if it's good to have it.
I prefer the thicker one for help doc though.

@girng
Copy link

girng commented Aug 6, 2019

i like the top better, the lines are too thick

@Calinou
Copy link
Member

Calinou commented Aug 6, 2019

We could base the underline thickness on the font size, so that underlines automatically become thicker as the rendered font size grows. Last time I checked, this is what Chromium does when underlining text.

@@ -497,7 +497,7 @@ int RichTextLabel::_process_line(ItemFrame *p_frame, const Vector2 &p_ofs, int &
Color uc = color;
uc.a *= 0.5;
int uy = y + lh / 2 - line_descent + 2;
float strikethrough_width = 1.0;
float strikethrough_width = font->get_underline_thickness();
#ifdef TOOLS_ENABLED
strikethrough_width *= EDSCALE;
Copy link
Member

@akien-mga akien-mga Aug 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the EDSCALE factor still needed now that we retrieve this information from the font? Or would it scale automatically together with the font? CC @Calinou

Copy link
Member

@akien-mga akien-mga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a question about whether EDSCALE scaling is still necessary for HiDPI, but otherwise it should be good to merge.

The docs display can be improved later on by replacing the link underline by a more subtle highlight (e.g. different color, and underline on hover).

@Calinou
Copy link
Member

Calinou commented Aug 6, 2019

HiDPI support seems fine to me, but it seems there are some issues with relying on the underline width defined in the font data. If I use the copy of Noto Sans Regular from the official website, I get a 2-pixel underline at 200% editor scale:

image

If I use the copy of Noto Sans UI Regular bundled in the Godot Git repository, I get a thicker underline (4 pixels at 200% editor scale):

image

All in all, this could cause underline widths to vary in unexpected ways without a way for users to control it easily (unless they alter the font data, which is non-trivial). Therefore, I'm wary about relying on the font data for the underline width. The underline can also get really close from the text, which makes it more difficult to read.

We should probably look at calculating the underline width automatically based on the font size (or by using custom constants). As for the underline position, we could add custom constants to RichTextLabel and LinkButton.

@volzhs
Copy link
Contributor Author

volzhs commented Aug 6, 2019

We should probably look at calculating the underline width automatically based on the font size (or by using custom constants). As for the underline position, we could add custom constants to RichTextLabel and LinkButton.

if so, underline position & thinkness should be a some kind of floating ratio value to show properly based on font size. otherwise, we need to change position and thinkness every time when changing font size.

@Calinou
Copy link
Member

Calinou commented Aug 6, 2019

@volzhs Unfortunately, custom constants can currently only contain integers 🙁

This may change with Godot 4.0 — last time he told me, reduz was OK with the idea of changing custom constants to be floats.

@volzhs
Copy link
Contributor Author

volzhs commented Aug 6, 2019

then I would let @akien-mga decide to merge this for 3.2, or wait for 4.0 to cover all feature. 😄

@akien-mga
Copy link
Member

I think it's better to wait for 4.0 and make sure that we handle all aspects of this fully.

@akien-mga akien-mga modified the milestones: 3.2, 4.0 Sep 3, 2019
@ondesic
Copy link

ondesic commented Apr 17, 2020

Hope this one gets implemented soon. I just experienced the underlining issue. I can barely tell there is any underlining.

@akien-mga
Copy link
Member

Needs a rebase.

IIUC, what we need to make this work fully is to support float constants in the theme? Maybe we should have a GIP about it and proceed with that?

@Calinou
Copy link
Member

Calinou commented Apr 29, 2020

IIUC, what we need to make this work fully is to support float constants in the theme?

I think it just involves replacing a lot of integers with float types in the codebase (unless we want to keep integer constants for some reason, but I can't see any for UI purposes).

@volzhs
Copy link
Contributor Author

volzhs commented Apr 29, 2020

@akien-mga rebased

@akien-mga
Copy link
Member

Let's merge and see what users think of it in the master branch.

@akien-mga akien-mga merged commit d7b85fb into godotengine:master May 7, 2020
@akien-mga
Copy link
Member

Thanks!

@volzhs volzhs deleted the underline branch May 7, 2020 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants