- Each variable was splitted in 3 variables containing the start block, middle block and end block respectively.
- Now the wrapAt variable controls programatically the length of the decorations lines, (for loop).
- Minimal wrapAt allowed value is 3.
See PR #1261 for details on the reasons.
This mostly reverts commit
f84a4a46d font-patcher: Add Codicons scale list
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Codicons: Maximise all circles
[why]
The scaling works okay for `Nerd Font Mono` fonts, but not for `Nerd Font`
fonts. The later have 'unexpected' left side bearing, which looks even
more out of place because the width is unrelated to the advance width
and might place the majority of the glyph into the next cell.
[how]
In fact we do not want scaling and shifting to be uniform for all glyphs
but the intend was to get the scaling from the biggest (full size)
circle and all the smaller ones would be proportionally smaller.
So we add a new Scale grouping that just takes the scale and the
vertical shift of the combined boundingbox, but individually calculates
the horizontal shift.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
IBM Plex uses some abbreviations also in the fullname and we do not try
abbreviations when resolving weights.
[how]
As this is the only font that has such specials we handle it beforehand
and do not try all combinations of abbreviated and long keywords.
And then their abbreviations are also not standard - at least not used
by us or Adobe, etc.
For such a small amount of affected font files it seems in order to
specifically just fix them instead of a general solution.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The 'Text' weight of Plex is handled as 'other', means that this is
added to the font's name and is a distrinct own family.
But in the original font it is used as weight.
[how]
Remove special handling of 'text' in the font name.
Add 'Text' to known_weights list.
"Text" is not a standard naming, but I see no problems when we handle it
as one. This keeps the family relationships in Blex like Plex.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Function get_name_token has a Cognitive Complexity of 12 (exceeds 9 allowed).
Consider refactoring.
[how]
Remove not really needed special case.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some fonts might have a non-standard (i.e. broken) weight naming scheme:
They put a blank or a dash between the modifier and the weight, for
example "Extra Bold" or "Demi-Condensed", when they mean "ExtraBold"
resp "DemiCondensed".
The former happens with CartographCF, the later with IBM3270.
[how]
Automatically allow a dash between modifier and weight, which comes up
as CamelCase boundary. Insert an optional dash (r'-?') into such
boundaries.
For the further lookup we need to remove the dash in the found keyword,
if there is any, to get back to standard naming.
This might break if the font name ends in a modifier. So we can not
really distinguish
Font Name Extra Bold Italic
=> Font Name - ExtraBold Italic
=> Font Name Extra - Bold Italic
The known modifiers are 'Demi', 'Ultra', 'Semi', 'Extra'.
It is possible but unlikely that a font name ends in one of these.
For example "Modern Ultra - Bold".
[note]
The question arises if we should not parse the PSname instead of the
Fullname; and stick to the dash there as boundary.
The problem might be prepatched fonts with broken naming, that would be
parsed completely wrong then. So maybe the current approach is still the
best, with the caveat given above (fontnames ending in a modifier).
[note 2]
Funny enough the variable allow_regex_token was not used at all :->
Some leftover? Anyhow we use it now.
[note 3]
We can still not remove the special handling for IBM3270, because the
font initially looks like a PSname and this is parsed as such, which
breaks the name in the incorrect place:
PSname template = "Name-StylesWeights"
Fullname of 3270 = "IBM 3270 Semi-Condensed"
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code is obviously wrong. No effect has been seen, though.
First we check if a certain string is a key in the dict.
If it is, we retrieve the value with the string lower-cased as key.
This does not make sense.
[how]
All the keys are lower case anyhow, so the code seems unneeded. Maybe it
is a leftover. The styles that go into it _and are in the dict_ all come
from a regex-enabled search and thus are lower-cased.
Whatever, to have the correct code we use the lower-cased string for
both, checking for existance and retrieving the value - this is the only
sane approach.
Also change to dict.get() method instead of a self made if code.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Patching CartographCF-Bold.ttf creates this naming:
Family (ID 1) : CartographF Nerd Font Condensed
SubFamily (ID 2) : Bold
Fullname (ID 4) : CartographF Nerd Font Condensed Bold
PSN (ID 6) : CartographFNF-CondensedBold
PrefFamily (ID 16) : CartographF Nerd Font
PrefStyles (ID 17) : Condensed Bold
CartographF Nerd Font Condensed Bold
\===> 'CartographFNerdFont-CondensedBold.ttf'
[how]
The font-patcher historically used the file name of the to-be-patched
font to come up with the new name. When the FontnameParser has been
developed that mechanics has been copied at least for fallback. The
earliest tests compared old and new naming with all the filenames.
Later, when the FontnameParser has been used to really apply name
changes it has always based the parsing on the Fullname or the PSname,
because they really hold the information (or at least should hold);
while the filename might be completely random.
Still code the dealt with specific problems in FILEnames prevailed. The
Ubuntu font for example has a file name like 'Ubuntu-C.ttf', and we
needed to convert the C to Condensed.
As that requirement vanished we can drop all the code that has been
added specifically only for parsing the Ubuntu font filenames.
Side note: USUALLY font filenames should be roughly equal to the PSname.
Fixes: #1258
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The order in which the advance widths are reported is rather misleading.
It also does not differentiate properly between basic and extended latin
range.
[how]
Reorder advance width details in output.
Change log entries to one-liners.
Also report monospaced and final cell size result.
[note]
No functional change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For fonts that have no Italic but an Oblique - i.e. when Oblique shall
replace the Italic role in RIBBI font grouping (classic group of 4) -
that grouping fails.
This affects DejaVu on Putty.
[how]
For RIBBI grouping only the classic bits are considered. That means that
for fonts that have Oblique instead of Italic (and not additionally) we
need to set the ITALIC bit and the OBLIQUE bit. This has been
overlooked.
Cite from the specs:
> This bit, unlike the ITALIC bit (bit 0), is not related to style-linking
> in applications that assume a four-member font-family model comprised
> of regular, italic, bold and bold italic. It may be set or unset
> independently of the ITALIC bit. In most cases, if OBLIQUE is set, then
> ITALIC will also be set, though this is not required.
[note]
Also increase font-patcher version.
Fixes: #1249
Reported-by: Huifeng Shen <liaoya@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although DaddyTimeMono is monospaced it has one glyph (napostrophe at
0x149) that is in fact two spaces wide. This breaks the created Nerd
Font Mono font.
[how]
Add that glyph to the list of non-standard glyphs that are ignored.
Fixes: #1243
Reported-by: fabestah
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
$ ./generate-css.sh
Generated CSS, json, and Cheat Sheet HTML
../../css/nerd-fonts-generated.css
../../css/nerd-fonts-generated.min.css [needs to also go into gh-pages:_includes/css/]
../../css/nerd-fonts-generated-removed.min.css [needs to only go into gh-pages:_includes/css/]
../../temp/2017-01-04-icon-cheat-sheet.md [needs to only go into gh-pages:_posts/]
../../glyphnames.json
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Casks without zap stanza are flagged; all casks should contain them.
The font casks do not really need zap.
[how]
What is the right way to say 'we considered zap, but do not need it'?
It seems that other people add a comment (the same comment).
For example here:
https://github.com/Homebrew/homebrew-cask/pull/119090
And that seems rather widespread.
git/homebrew-cask/Casks$ git grep '# No zap stanza required' | wc -l
101
Include the same in our casks.
[note]
https://github.com/Homebrew/homebrew-cask/issues/88469
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
b6301e590 CascadiaCode: Rehint and use ttf
we replaced the hints done upstream by ttfautohint with hints done via
Visual TrueType, because they render the text more similar to the
variable fonts (hints).
But the version string still mentions 'ttfautohint' because we did not
touch the font files at all except opening, hinting, closing in VTT.
This can be confusing.
[how]
Change the version string to "Version 2111.001; VTT 6.35" via:
* `ttx -i *.ttf`
* Edit `ttx` files and replace version, see above
* `ttx -b *.ttx`
* Move new fonts over old fonts
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The codicons have 3 obvious (from the name) pairs of regular and small
icons. The size difference is slight but visible.
When we maximize all individual icons the differences are mostly lost.
[how]
Put each pair into one ScaleGroup to keep their individual scaling.
Fixes: #1214
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
[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.
[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]
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]
The CI process produces a different font than running the
generate-original-source script locally.
Several thing have been checked, to no avail, see #1227.
Turned out the affected SVGs all are somehow ... questionable in their
construction.
[how]
Open SVGs in inkscape, select all (points) and generate new, clean
outline with Path->Union.
Save as optimized SVG.
The (CI) created font file now looks good.
But the cause is still unknown, maybe some sub-library that is used has
changed? I have no clue. Meaning it runs ok locally seems to be no
guarantee it will look the same when run by the CI :-(
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
