[win32] Fix collapsed tab stops at fractional zoom levels - #3493
Open
vogella wants to merge 1 commit into
Open
Conversation
Contributor
TextLayout.setTabs() takes the tab stops in points, but computeRuns() converted them to pixels and compared them against a pen position accumulated from raw glyph advances. At zoom levels that are not a multiple of 100 the point/pixel round trip can place a stop one pixel past a pen position that actually sits exactly on that stop, so the tab advanced by a single pixel instead of moving to the next stop. StyledText hits this because it measures its tab width as the width of N spaces in points and passes that back as the only tab stop, so a tab following N spaces lands precisely on the stop. It became visible in 4.36 when monitor-specific scaling turned the effective auto-scale from "integer" into "quarter", exposing zoom 125, 150 and 175. Resolve the stop in points instead, including for merged consecutive tabs, and convert only the resulting position to pixels. Fixes eclipse-platform/eclipse.platform.ui#3052
vogella
force-pushed
the
styledtext-tab-stops
branch
from
August 8, 2026 07:51
4768d9c to
3cd0ff7
Compare
vogella
changed the title
vogella
marked this pull request as ready for review
August 9, 2026 07:27
Contributor
Author
|
@HeikoKlare this is a scalling related bug fix, do you want to review? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TextLayout.setTabs()takes the tab stops in points, butcomputeRuns()converted them to pixels and compared them against a pen position accumulated from raw glyph advances. At zoom levels that are not a multiple of 100 that point/pixel round trip can place a stop one pixel past a pen position that actually sits exactly on that stop, so the tab advanced by a single pixel instead of moving on to the next stop.StyledText runs straight into this because it measures its tab width as the width of N spaces in points and hands that back as the only tab stop, so a tab following N spaces lands precisely on the stop. That is the "tabs are sometimes not indenting" report in eclipse-platform/eclipse.platform.ui#3052. It surfaced in 4.36 when monitor-specific scaling turned the effective auto-scale from "integer" into "quarter", exposing zoom 125, 150 and 175.
The stop is now resolved in points, the unit the caller defined it in, including the fallback past the last stop and the merged consecutive tabs, and only the resulting position is converted to pixels. The regression test was pushed on its own first: the Windows job flagged 45 combinations of zoom, font height and tab length, at 125, 150, 175 and also 200 percent for odd tab lengths.