-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Implement run-time extra line spacing #4742
base: master
Are you sure you want to change the base?
Conversation
imgui.h
Outdated
@@ -2742,6 +2743,8 @@ struct ImFont | |||
ImVector<float> IndexAdvanceX; // 12-16 // out // // Sparse. Glyphs->AdvanceX in a directly indexable way (cache-friendly for CalcTextSize functions which only this this info, and are often bottleneck in large UI). | |||
float FallbackAdvanceX; // 4 // out // = FallbackGlyph->AdvanceX | |||
float FontSize; // 4 // in // // Height of characters/line, set during loading (don't change after loading) | |||
float ExtraLineHeight; // 4 // in // // Extra line height | |||
float ExtraLineAdvance; // 4 // in // // Extra spacing between lines |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the comment above should include these new fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added real comments here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line right above describes how many bytes are hot for this struct.
Line 2744 in 630e42c
// Members: Hot ~20/24 bytes (for CalcTextSize) |
I don't know how CalcTextSize()
works exactly, but if it would want to break lines, it would prompt inclusion of these new fields into the hot memory calculations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved new fields down. They're not needed in hot path nor reason to invalidate assumption made by this comment.
Thanks for pointing that out.
In my use case I would want to use negative values. It may not be advisable to limit the sliders present in the "Hello world!" window to be >= 0. |
Negative values does work, these parameters are not limited to positive values. |
Yes, I didn't saw anything in the code which would limit them. This is more about the immediate availability through the UI. It may be of use to some people, considering that most fonts now produce an ugly margin. I don't understand this, as typesetting is hard (let's go shopping) and manually fixing this through these parameters may be the easy way to go. For example, this is Noto Sans: And this is Droid Sans of the same size: If a random comment on reddit is to be believed, these fonts should be rendered without any differences. |
cfbff56
to
630e42c
Compare
They may share outlines, but overall metrics may be changed to better fit purpose they were created for. EM scaling appears to be different between them. That's my theory without looking at font files. |
I would definitely appreciate this. Adding the extra equally on top and bottom would be problematic for me. I'm already using cursor position to fix typography in my Dear ImGui apps, and extra-equally wouldn't fix the issues for me. Could you split the extra line height into two please? In typography it's common to need line spacing at the bottom only, and ocassionally at the top. If a font has a very low x height for example, it may be desirable to only add space at the bottom because the top of the font may already be very empty. Another use case is attempting to align a text label with a particular graphic element. Adding spacing at top or bottom would be the most precise way to do that, if it's equal, I'd have to also adjust cursor position any way to compensate. I think your proposal, with the split, would make my life much easier, as I think it would be less cumbersome that over-riding Dear ImGui's layout. |
I think I would add baseline offset rather than two separate spacings. It will allow to achieve the same effect while being more intuitive, I think. |
@meshula There is a baseline offset available now |
From conversation outside of github.
LineAdvance is used in multiline context allowing to control how much new lines will advance.
Usually user want to tweak single font instance. Moving ExtraLineHeight and BaselineOffset to style would mean user will have to keep these values along with ImFont and remember to change style together with font. This appears to be less user friendly interface, so I put them in ImFont directly.
|
67fabfb
to
715c954
Compare
Changes:
|
8b83e0a
to
d735066
Compare
There is some interaction with how clipper works with these changes. Setting ImGuiListClipper clipper;
clipper.Begin( (int)lines.size() );
while( clipper.Step() )
{
for( auto i=clipper.DisplayStart; i<clipper.DisplayEnd; i++ )
{
ImGui::Text( "text" );
}
} Produces blank space at the bottom of the visible clipped area. |
1.86 + docking + this change. This requires resolving conflicts, maybe I did something wrong there?
This is the font setup I do: scale = 1.5f;
fixedWidth = io.Fonts->AddFontFromMemoryCompressedTTF( tracy::FiraCodeRetina_compressed_data, tracy::FiraCodeRetina_compressed_size, round( 15.0f * scale ), &configBasic );
fixedWidth->ExtraLineHeight = -5.0f * scale; With FiraCode 5.2 (https://github.com/tonsky/FiraCode/releases/tag/5.2). The number of lines has to be significant (2500 in my case). |
Ok, i will try to reproduce with that. In the mean time, you might be interested with a few commits from feature/hidpi-support. Mainly:
There is FiraCode v6.2 available, is there any particular reason to stick to v5.2? |
818b0ac
to
da9d61b
Compare
I have hi-dpi support on Windows and Linux by changing font size. What is this feature branch improving here?
6.0 was not monospace with Freetype, don't know how 6.x works in that regard. I guess 6.2 fixes this? |
Main perk is you can keep font size constant. UI designed with 1.0f will scale to DPI while staying sharp and mostly where it suppose to be.
Release 6.2 appears to fix exactly that: https://github.com/tonsky/FiraCode/releases/tag/6.2 :
I reproduced bug, I'm working on a fix. |
That's how it currently works. The only platform where it's broken is MacOS (because ImGui behaves differently there). The image below is a composite of two similar views with different font sizes (50% and 200%). The font size can be dynamically adjusted in run time. |
On my branch I made osx example work. Granted this was done with
Looks like everything in your app is scalable. Cool, this works too.
|
Now that you have said this, I think I had this exact problem on master some time ago. I resorted to just rounding the font size to an integer value. Anyways, the solution works. I am just rounding the value passed to |
b3b85d8
to
0755767
Compare
c817acb
to
8d39063
Compare
I have realized that for my use case I need just to set ItemSpacing to 0, e.g.: ImGui::PushStyleVar( ImGuiStyleVar_ItemSpacing, ImVec2( 0, 0 ) ); |
…eHeight() and GetFontLineAdvance())
611c500
to
7b2b67c
Compare
Rebased on v1.89 WIP (18808) |
This PR address #4578, #2945 feature requests.
Summary
I made a pass over ImGui and prepared necessary patch to support extra spacing in text.
I introduced two new parameters in
ImFont
:ExtraLineHeight
- by how many pixels line height should be increased, extra space will be equally distributed between top and bottom of the fontExtraLineAdvance
- by how many pixels spacing should be increased between consecutive lines of multiline texts, does not affect line height, just move cursor moreTasks
ExtraLineHeight
ImplementRemoved in favor ofExtraLineAdvance
ExtraLineHeight
BaselineOffset
FontLineHeight
for vertical axis instead ofFontSize
_FontSize
back toFontSize
GetFontXXX
functionsPreview
ExtraLineHeight=0
ExtraLineAdvance=0
ExtraLineHeight=8
ExtraLineAdvance=0
ExtraLineHeight=0
ExtraLineAdvance=8
ExtraLineHeight=8
ExtraLineAdvance=8
How atlas generation changed?
Atlas itself isn't affected. Change is entirely run-time only. Also
Font scale
,window scale
andglobal scale
still works as expected.How does it behave in action?