This repository was archived by the owner on Mar 7, 2025. It is now read-only.
Fix text baseline position for some fonts#669
Open
PreferLinux wants to merge 3 commits intomono:mainfrom
Open
Conversation
Some fonts (particularly Calibri or the metric-equivalent Carlito) were not aligned to the same baseline as on Windows. This is because fonts have three sets of roughly equivalent metrics, and different platforms use different ones. Pango uses one set, and Windows uses a different set. The one Windows uses has the line spacing included in the ascent and descent. The other two allow the gap to be specified separately, but the one Pango seems to use has normally got only a minimal gap. The problem is that Pango is aligning the top of the font according to just the ascent, and on fonts like the above where this is considerably different to the Windows ascent the text is positioned equivalently higher in the bounding box.
Don't adjust baseline on vertical text. It needs to be handled differently to horizontal, and has enough other problems that I don't want to start. Fixes test failure. Fixes the compile error that happened for Windows. Report the baseline offset separately to the box offset, because it needs to be handled differently for measurement etc. Basically when drawing it needs to make it draw lower (affecting position), but when measuring it needs to make the rectangle taller (affecting size but leaving the position unchanged).
Contributor
Author
|
This has some significant issues, both before and after the changes. In particular, both versions have issues with measuring. I'll continue to work on the problem though. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Text drawn with some fonts (for example Calibri and the free metric-equivalent Carlito) is not aligned to the same baseline as on Windows.
This is because fonts have three sets of roughly equivalent metrics, and different platforms use different ones. Windows uses one set, and Pango primarily uses a combination of the other two. The set Windows uses has the line spacing included in the ascent and descent. The other sets allow the gap to be specified separately, but for many fonts (even most) the one Pango uses has got only a minimal gap with the ascent roughly matching Window's one (hence why this problem is not common). For the first line of text the baseline is positioned according to the ascent.
However, these two fonts have a significant difference between the Windows ascent and the other two. As the text baseline is positioned according to the ascent, the text is positioned equivalently higher in the bounding box:
This works around the problem by calculating the correct baseline and adding the difference between it and the baseline used by Pango to the offset for text drawn with
StringFormat->lineAlignmentset toNear. As long as the metrics returned byGdipGetCellAscentand co are correct this should not make drawing wrong.With fix:
Windows 8.1:
