[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>
[why]
The Seti and Custom icons are smaller than in ancient Nerd Font versions
and can seem a bit flimsy. In fact we add about 25% of padding (12% left
and 12% right) to each icon, which seems a bit generous.
This does not show in Nerd Font Mono fonts, because the icons will be
rescaled there, but in the other fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Ubuntu Condensed font is special because it is designed to be not
part of the `Ubuntu` font family but a self standing `Ubuntu Condensed`
family with just one member.
We want the `Ubuntu Condensed` to be part of `Ubuntu`, as it is usual
for fonts with different widths.
The problem then arises that the width class in the font metadata is set
to 'Normal', while it has to be 'Condensed'. That fact does not become
apparent when the font is in its own one member family, but even there
it is wrong.
[how]
To keep all the other information in the font untouched we just directly
patch that one byte where the width-class is stored - and repair the
checksums afterwards. Nothing more.
The code to do this is the Font Tweaker code in font-patcher, just
copied here for one time use.
Fixes: #1228
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With Ubuntu-Regular the fi and fl ligatures are replaced by some font
awesome icons.
The problem is that the font uses the non-standard F001 and F002
codepoints as intermediate referencve to create the actual ligatures
that are at codepoints FB01 to FB04.
[how]
All the normal ligature codepoints (FB00-FB06) are added to the glyph
reference checker and codepoints that are referenced by these are not
patched.
This means that F001 and F002 stay on the original ligatures and the
Font Awesome icons are missing, but this can not be fixed automatically
and would need to 'rewrite' the references inside the font.
Fixes: #1221
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Just run ./generate.
Compare commit
7764e05 Create new octicons.ttf (update to v18.3.0) (2/2)
Fixes: 1213
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some people, for example the `lsd` project, need an icon with a symlink
directory. That has been dropped by Octicons. Our repacking put some
unrelated bookmark icon on that codepoint; but even an empty glyph would
be not ideal.
[how]
Design a file-symlink-directory from file-symlink-file and
file-directory. In this way it fits nicely into the current design of
Octicons.
Sneak that into the unpacked Octicons archive.
Adapt mapping manually to keep as much as possible constant.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While the commit
7cda32651 font-patcher: Allow to specify custom symbolfont with absolute path
would have allowed to specify the custom glyph font with an absolute
path, it is in fact still not possible.
[how]
The file-exists checks also need to observe the absolute path.
[note]
Normally (with a relative path) the custom font is search for in the
ordinary glyphs directory - but that would mean people need to copy it
there.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When a user want to patch some glyph in, and at that position is already
a glyph, there is no way to overwrite it.
The reason is that --custom glyphs are always patched in --careful, and
there is no --not-careful option to override that.
[how]
Add glyphs via --custom always, except --careful has also been given.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If you add a custom icon it probably has to fit with the rest of the
font. So why should we patch it in completely unscaled?
[how]
Just scale the custom icon like all other icons at least.
If someone wants to add just a symbol or two and keep the glyphs exactly
(more or less) unscaled there are simpler ways than this patcher
script. I believe persons that are able to pre-scale the custom font are
also able to just patch it in. So this option is more for the generic
patching of extra glyphs but they need to be scaled somehow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Box Drawing glyphs need to be carefully scaled. This can not be done
if the glyphs are pulled in via font-fallback I guess.
As people may have the fontconfig set up in a way to prefer the Symbols
Only font these glyphs could overrule other box drawing glyphs that
might fit better.
I'm not really sure about this one, but the glyphs look rather bad
anyhow, because they end up in the 1:1 ascpect ratio cell of the Symbols
Only font.
[how]
Just turn the set off if we patch the Symbols Only font.
Need to swap around two subroutine calls for that; first detect if we
are patching the Symbols Only font (through the font metrics) and then
set the patch sets up.
Fixes: #1210
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Changed link again to refer to the default branch ('master' at the
moment) HEAD and use -O instead of needlessly repeating the file name.
Authored-by: Md. Abdullah Al Maruf <62918360+mk1121@users.noreply.github.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
