-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
font-patcher: Add progress indicators #1733
Conversation
Something is wrong with the width when Compare handling of |
[note] Glyphs taken from FiraCode; remove negative bearings and add a helper glyphs for vertical alignment that is used for the combined boundingbox calculation but not patched in. Fixes: #1345 Signed-off-by: Fini Jastrow <[email protected]>
d89c9a4
to
054dbc0
Compare
There is obviously a problem with center aligned glyphs... But that is already there before this MR :-( Two notabke commits: acd49cc
Glyphs to check
master branchCommit 81d052bCommit ?Another |
054dbc0
to
943980a
Compare
|
6a07537
to
c589ee2
Compare
So lets crate a list of fonts that need to be tested
Preparing fonts prior to this PR... |
c589ee2
to
bea6001
Compare
Cascadia Code NFMinimal differences, some cell height problems fixed. Green outline before this PR Cascadia Code NFMSame Cascadia Code NFPLots of advance width changes: Most of these are ok, because now it correctly detects that all the symbols should be one 'cell' wide, even in the proportional font, and scales them to 1200. Which is correct (was wrong before). Left: old, overlap on right hand side too big, because scaling was correct. Right: After this PR Left: prior to PR. Right: after PR Left: prior to PR, zoomed in top right corner no overlap. Right: after PR Last 3 glyphs in list do have real issues Investigating... |
bea6001
to
de2f4dc
Compare
Signed-off-by: Fini Jastrow <[email protected]>
[why] It can be confusing what is or is not synced when scaling-shifting. [how] Add text from commit: 90bde73 font-patcher: Use ScaleGlyph BB to align glyph Also add a new (documentary) property for the tables that can be checked so that nothing unexpected will happen. Signed-off-by: Fini Jastrow <[email protected]>
[why] All the glyphs have overlap (negative bearings). That in itself is ok, altough it (the glyph width for example) is not consistent for all subsets. The overlaps can interact strangely with the overlap given by the font-patcher script. [how] It seems better to remove the negative bearings. Also some glyph width are corrected (unified). The font is then stored uncompressed now. [note] The script used to modify the font: import fontforge, psMat font = fontforge.open('src/glyphs/extraglyphs_orig.sfd') font.encoding = 'UnicodeFull' def adjust(f, rang, left, width): for c in rang: g = f[c] if c in range(0x2599, 0x259f + 1): plus = 0 g.transform(psMat.scale(1233/1234, 1)) if c == 0x259D or c == 0x2595: g.width = width g.right_side_bearing = 0 else: g.left_side_bearing = int(g.left_side_bearing + left) g.width = width print('{:X} {} {} {} {}'.format(c, g.boundingBox(), g.left_side_bearing, g.width, g.right_side_bearing)) adjust(font, [*range(0x2500, 0x2570 + 1), *range(0x2574, 0x257f + 1)], 20, 1233 + 40) adjust(font, range(0x2571, 0x2573 + 1), 87, 1280+127) adjust(font, range(0x2580, 0x259f + 1), 0, 1233) font.generate('TEST.sfd') font.generate('TEST.ttf') Signed-off-by: Fini Jastrow <[email protected]>
[why] The shifting in the final patched font is broken for the 'blocks' subset. The reason is that it contains a glyph that is one unit too small. [how] Manually shift the points to make it as wide as the others. Signed-off-by: Fini Jastrow <[email protected]>
Signed-off-by: Fini Jastrow <[email protected]>
[why] Glyphs that shall end up in two cells with xy scaling and overlap (for example E0C0, E0C2) end up being a bit too wide. In fact the width is the 2 cell width and 2 overlap width. [how] Apply the overlap (which is 'percent' factor) not on the concrete glyph width, which is 2*cellwidth in these cases, but base it on the one-cell-width instead. Signed-off-by: Fini Jastrow <[email protected]>
de2f4dc
to
33d4af7
Compare
[why] The EE00 and EE03 glyphs are aligned too far to the left. [how] Affected are only right aligned glyphs with (negative) overlap, that have an advance width (i.e. are member of a scale group). Extract a new condition as variable as we need it in several places. Use that condition also for the right alignment applicability check. Related: #1733 Signed-off-by: Fini Jastrow <[email protected]>
fixed via hotfix e6426bb |
Fixes: #1345
Description
Please explain the changes you made here.
Add these 12 glyphs that can be used as progress indicators and originate from Fira Code:
We specifically left these codepoints un-occupied for these glyphs in previous PRs.
It turned out that the scaling and shifting algorithm has some ... peculiareties, and these glyphs need to be properly aligned and have overlap for gapless display (the first 6 glyphs), so that needs to be fixed first 😬
That in turn showed even more bugs ;-)
It is always an endless pit. Lets see if we can straiten out all the problems.
Requirements / Checklist
Issue number where discussion took place: #xxx
What does this Pull Request (PR) do?
How should this be manually tested?
Any background context you can provide?
What are the relevant tickets (if any)?
Screenshots (if appropriate or helpful)