Fix outline of gamma, fix pad_glyph(), add more kernings with smarter operation#97
Fix outline of gamma, fix pad_glyph(), add more kernings with smarter operation#97dummy-index wants to merge 11 commits into
Conversation
dummy-index
commented
May 29, 2026
dummy-index
commented
- The gamma outline was broken, caused by combination of the wavy outline and changeWeight(). (a part of Minor kerning improvements #70)
- If you align positions using the values from boundingBox() without having called addExtrema() and then round them, the extrema end up in positions that are difficult to round, making it hard to converge. It's better to call addExtrema() first. (However, it seems that for a few characters, the positions of the extrema are still changing)
- Due to the above changes, the effect of automatic hinting changed, so I adjusted the BlueValues and the y-direction positions of A and N. Also, while I was at it, I corrected the lifting of j that had occurred in 3dbc5d1.
- Regarding pad_glyph(), I modified the algorithm and added comments. Due to this bug, the letter-spacing of some characters had become excessively tight.
- Added numerous kernings. Improved processing.
…ems with changeWeight()) (ipython#70)
Disable duplicated handling of variants
successfully reducing individual patches as a result
pelson
left a comment
pelson
left a comment
There was a problem hiding this comment.
Do you think it is possible to separate the kerning changes proposed from the non-kerning changes that are here? The latter are ready to merge 👍, but I think the kerning changes need us to be on the same page, and for us to individually asses the merit of each full-set kerning change.
There was a problem hiding this comment.
Looking at the original handwriting sample, I agree that the spacing is better here.
In particular, looking at "unevangelic" the letters are clearly distinct, whereas in the existing sample before this PR, they are on the verge of touching each other.
👍 to the diff.
There was a problem hiding this comment.
The gamma change here looks like it is significant, rather than a pixel difference.
The location doesn't look correct in the new version?
There was a problem hiding this comment.
Outline before changes:
In the charmap before the change, it seems that the position of gamma was shifted as a result of matplotlib's ax.text() trying to fit the outline within the frame. (A similar behavior can also be seen with U+0327. It seems to be an issue at a level different from the font's yMax height.)
|
|
||
| # Expand the broad letter lists to include accented variants from the outset, | ||
| # so every rule that references `caps`, `lower`, or `all_chars` covers them too. | ||
| caps = _expand_with_variants(font, list('ABCDEFGHIJKLMNOPQRSTUVWXYZ') + upper_ligatures) |
There was a problem hiding this comment.
I'm worried we don't have much visual test coverage of the kerning between accented variants, and therefore want to be sure how how this lands for those characters, even though I can see that the expand call is done within the kern function.
Perhaps we need another sample which covers a bunch of the different languages that we have added support for?
There was a problem hiding this comment.
Yes, taking that point into consideration, in my previous fork, individual kerning was applied only to basic_latin.
| # separation required by the glyphs on the left and right.) | ||
| kern(80+a, set(lower) - {'i', 'j'}, ['f', 't', 'x'], onlyCloser=True) | ||
| # x has diagonal strokes that leave visual space on its right side. (glyph changed in 3dbc5d1) | ||
| kern(80+a, ['x'], set(lower) - {'i', 'j'}, onlyCloser=True) |
There was a problem hiding this comment.
I'm not keen to add kerning for all letter combinations, and think we should start with changing the bounding box of the character in the first instance.
Kerning should then be used when we need specific tweaks between pairs of letters because of the letter forms.
There was a problem hiding this comment.
Kerning originally refers to the process of tightening the space between characters, and by combining the width adjusted to the bounding box with onlyCloser=True, kerning settings remain only for the pairs that really need kerning.
You could say that the CPU is being made to work unnecessarily, but I think it's more reliable than a human constantly keeping all combinations in mind while checking.
That said, it caught my attention when it was mentioned, so I checked the kern table, and it turns out that *j is kerned across the board (except for gj, jj, and the like). The LSB could probably be tightened by about 20–30. Formula (capxrange[0] + bbox[0])/2 was roughly created based on the idea that 'fonts with a less curved lower part of j tend to have tighter spacing between i and j,' so it can be adjusted freely. If tightened, onlyCloser=True will take effect and automatically reduce the kerning settings.
| kern(90, ['E'], set(roman) - {'j'}, onlyCloser=True, damper=0.75) | ||
| kern(115, ['T', 'J'], set(roman) - {'j'}, onlyCloser=True, damper=0.75) | ||
| kern(105, ['Y'], set(roman) - {'j'}, onlyCloser=True, damper=0.75) | ||
| kern(95, ['V'], set(roman) - {'j'}, onlyCloser=True, damper=0.75) |
There was a problem hiding this comment.
Ideally I would like to be reviewing the need for new kerning pairs indivitually - for example, adding V against the full set of letters is a change that I would want to consider in isolation ideally.
2 participants
