font-patcher: Do not maximize heavy brackets in Mono #1232
Merged
Conversation
This file contains 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
|
|
Finii
force-pushed
the
bugfix/heavy-bracket-scale
branch
from
cb0fa84
to
b7f7a33
Compare
[why] The config.cfg settings can be wrong if the to-be-patched font does not set its own. The previous settings are never cleared, so that the flags leak into the next font(s). This is only relevant when the run is not parallel (i.e. no -j given) and all fonts are patched sequentially in the same shell. On parallel runs (like the release process) this is not a problem because each patcher runs in its own subshell. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] After changing something in the patch process it is unclear if all the prepatched fonts will look ok later. It would be nice to produce one font from each input font (and not the complete set of each of the faces of that font) to have some hopefully representative example how symbols will blend into the font. [how] Add a script with explicit list of representative fonts. Evaluate the config.cfg and execute one patcher run. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] When the Heavy Brackets are scaled we want them to be scaled according to 'pa1!' (i.a. preserve-aspect, only-one-cell, scale-always). This is not possible because the glyphs have a ScaleRule and that always assumes pure 'pa' and nothing else. [how] When the first glyph of the group is encountered the group scaling is determined. This now takes the stretch rule of THAT glyph (instead of just 'pa') to prepare the scale of the complete group.
Finii
force-pushed
the
bugfix/heavy-bracket-scale
branch
from
b7f7a33
to
499d7a3
Compare
Hmm, changed the rule to |
[why] The added heavy brackets are maximized within the cell size as all normal other symbols. But in fact they should not be maximized but rather be the size of 'normal brackets'. Furthermore they are all scaled individually, making the size differences less. With some proportional fonts the brackets look tiny. [how] Introduce new y-padding parameter (because a negative overlap also acts in x direction, what we do not want (and it distorts)). Pad the brackets with 30% (15% top and 15% bottom). This is used for all fonts (monospaced or not) so that the new glyphs fit nicely with the existing ones. For some definitions of 'nicely', but that is as good as we can get with automatism. It's not worse than font-fallback. Fixes: #1229 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii
force-pushed
the
bugfix/heavy-bracket-scale
branch
from
499d7a3
to
fe7855f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
font-patcher: Do not maximize heavy brackets in Mono
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.
Furthermore they are all scaled individually, making the size
differences less.
With some proportional fonts the brackets look tiny.
[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want (and it distorts)).
Pad the brackets with 30% (15% top and 15% bottom).
This is used for all fonts (monospaced or not) so that the new glyphs
fit nicely with the existing ones. For some definitions of 'nicely', but
that is as good as we can get with automatism. It's not worse than
font-fallback.
Fixes: #1229
Also done
Fixes some bug fixed along the way 😬
Requirements / Checklist
What does this Pull Request (PR) do?
Insert the heavy brackets more carefully (size wise).
How should this be manually tested?
Use the new
generate-sample-set.shand thenfontforgewith font-compare.Any background context you can provide?
What are the relevant tickets (if any)?
Screenshots (if appropriate or helpful)