[why]
Some strings have broken format, because the string should contain a
verbatim backslash.
It seems this is a new warning for Python 3.12
[how]
Use raw strings or escape the escape character via '\\'
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The keep-regular rule should add 'Regular' as weight if there is no
weight (e.g. Bold) or style (e.g. Italic).
But when a font does have neither but has a widths specifier it is also
not added.
[how]
Check for some conrete weight and not only any entry in the weight
token, because we - unfortunately - mix weights and widths in that token
set.
We do not need to check the styles because it is technically impossible
for it to comtain Regular and something else.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
"RecMonoSemi" looks a bit broken.
[how]
Unchanged version "RecMonoSemicasual" is two chars too long for NFP.
This is independent on makegroups mode, because the PS name is affected.
Use "RecMonoSmCasual" which is just the right length and still the
original is discernible (I guess).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Modifier on their own are not allowed (except "Demi").
The previous commit where we changed the CodeClimate fix from
' ' to '' allowed any modifier to be a stand alone detected word.
This resulted in this font name:
RecMonoCasual Nerd Font Propo Semi
[how]
Remove the cumbesome CodeClimate kludge completely, it just makes the
code more complex without any real benefit. Codeclimate just complains
because our tables look so "similar" :rolleyes: That's data dude!
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have now fonts where names for multiple languages are set
(differently) but we need to compare only the base language which is
English US.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code needlessly create two language ID17 even if ID16 is only one
entry / one languange. ID17 is always the same for both languages.
This is an example for the wrong way:
======== BlexMonoNerdFont-Text.ttf ========
SFNT Fullname ID 4 BlexMono Nerd Font Text
SFNT Family ID 1 BlexMono Nerd Font Text
SFNT SubFamily ID 2 Regular
SFNT Pref Family ID 16 BlexMono Nerd Font
SFNT Pref Styles ID 17 ('Text', 'Text')
SFNT PS Name ID 6 BlexMonoNF-Text
SFNT Compatible ID 18 -
SFNT CID findfont ID 20 -
SFNT WWS Family ID 21 -
SFNT WWS SubFamily ID 22 -
PS fontname BlexMonoNF-Text
PS fullname BlexMono Nerd Font Text
PS familyname BlexMono Nerd Font Text
fondname None
This is an example for the correct way (two ID17 when we have two ID16):
======== NotoSerifCondensedNerdFont-BlackItalic.ttf ========
SFNT Fullname ID 4 NotoSerif Condensed NF Black Italic
SFNT Family ID 1 NotoSerif Cond NF Black
SFNT SubFamily ID 2 Italic
SFNT Pref Family ID 16 ('NotoSerif Condensed Nerd Font', 'NotoSerif Cond NF')
SFNT Pref Styles ID 17 ('Black Italic', 'Black Italic')
SFNT PS Name ID 6 NotoSerifCondensedNF-BlackItalic
SFNT Compatible ID 18 -
SFNT CID findfont ID 20 -
SFNT WWS Family ID 21 -
SFNT WWS SubFamily ID 22 -
PS fontname NotoSerifCondensedNF-BlackItalic
PS fullname NotoSerif Condensed NF Black Italic
PS familyname NotoSerif Cond NF Black
fondname None
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Usually we want the width before the weight:
ZedMono Nerd Font Extended ExtraBold Italic
but we get:
ZedMono Nerd Font ExtraBold Extended Italic
The reason is that we do not sort widths and weights and handle them as
one list, keeping the original order.
All fonts but Zed have the width before the weight and it never turned
up
[how]
Handle widths and weights on their own and only afterwards concattenate
width (first) to weights (second).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we add a dummy we need to remove that later on.
Originally that has been introduces to avoid a wrong code duplication
warning.
See how the blank leaks into the name:
ERROR: ====-< Family (ID 1) too long (38 > 31): ZedMono Nerd Font Extended ExtraBold
DEBUG: =====> SubFamily (ID 2) ok ( 6 <=31): Italic
DEBUG: =====> Fullname (ID 4) ok (45 <=63): ZedMono Nerd Font Extended ExtraBold Italic
DEBUG: =====> PSN (ID 6) ok (33 <=63): ZedMonoNF-ExtendedExtraBoldItalic
DEBUG: =====> PrefFamily (ID 16) ok (17 <=31): ZedMono Nerd Font
DEBUG: =====> PrefStyles (ID 17) ok (27 <=31): Extended ExtraBold Italic
DEBUG: =====> PrefStyles (ID 17) ok (27 <=31): Extended ExtraBold Italic
DEBUG: =====> Filename 'ZedMonoNerdFont-ExtendedExtraBoldItalic.ttf'
(Note trailing blanks even in ID 1.)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
'for Code' variants.
Rename RecMonoSemicausal to RecMonoSemi to avoid too long font names
after we add 'Nerd Font Mono' )or even (NFM) to it.
Fixes: #845
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code is rather convoluted and one can not follow what is done.
[how]
Add function that abstracts some steps away.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This sets out to circumvent a problem with VisualStudio 2022. That
application seems to have problems with fonts when the ID16 is not a
prefix in ID1.
We have this when --makegroups >= 4, because
ID1 has the short name suffix 'NF'
ID16 has the long suffix 'Nerd Font'
These fonts can be selected in VisualStudio 2022, and the preview works
ok, but once active some replacement default font is used instead.
The problem vanishes if ID16 and ID1 have the same stem, or rather ID1
has someting added on top of ID16; but ID16 is a substring of ID1.
See more discussions in #1442
[how]
Write both forms in ID16 fields, 'NF' and 'Nerd Font' suffixes. This
works as long as the application considers all languages equal.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Albeight documented in the comment not all non English-US entries are
removed but just al TO_DEL ones.
[how]
Put the conditional in the right position.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When shortening the rare gases names to the element symbol
Radon is named 'Rd' while it should be 'Rn'.
Atomic number 86 on the periodic table.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
After the working draft name Monispace the final patched font name will
be Monaspice.
* It keeps the characteristic `Mona` in the beginning
* It changes just one character
* The replacement is still a real word
* The replacements sounds very similar
Also other very good names have been suggested, thank you all for the
input!
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It is better to have a not-abbreviated file name so that one can make
sense out of the name parts, especially when doing a partial patch.
With the previous commit we ended up with all abbreviated names.
The filename length is hopefully not limited, at least not as severe as
the SFNT table entries.
[how]
We need to store the answers somewhere because the naming is only
understood by the FontnameParser object which we throw away soon.
As fallback we still can parse the SFNT table, for example when the old
renaming is used.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Because the newer Preferred/Typographic names ID 16 and ID 17 have not
a very demanding length limit we add the long form of the name
addendum (i.e. Nerd Font, Nerd Font Mono, Nerd Font Propo).
In the more restricted old names ID 1 and ID 2 we use the short forms
(i.e. NF, NFM, NFP).
This seems to be problematic with Visual Studio (Community) 2022 and the
fonts can be selected but are not really used.
The Postscript family name is never shortened which seems to be of no
consequence, but still is different than the other.
[how]
When creating the Preferred/Typographic Family (ID 16) we check the
shortening mode first and abbreviate the parts as needed and alike ID 1.
This will also change the filenames, because they base on the SFNT
table. We can not change that without changing the whole mechanism.
[note]
Also add new tool that lists all names of fonts, including the
Postscript ones.
Fixes: #1242
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
They renamed
M Plus Code Latin -> M Plus Code Latin50
M Plus Code Latin Expanded -> M Plus Code Latin60
The versioning is rather divers, add more information into the font
specific README file.
Fixes: #1333
Reported-by: LeoniePhiline
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Monaspace has an RFN that individually protects 'Monaspace' and all the
face names of noble gases 'Xenon' etc. Both must not be used on patched
fonts.
[how]
Just add the rule(s). The concrete naming is not decided yet.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some PS weights have a dash in the weight, like 'Extra-Light' in
Iosevka. The parser can not parse it because it expects 'ExtraLight'.
[how]
Filter out all '-' and ' ' from the PS weight string before actually
parsing the string.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the weight check fails for some input the reason is not shown
correctly (i.e. not the string that actually failed).
[how]
Display exactly the failed string in the warning.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the font does not have a PSweight string the font-patcher bugs.
[how]
Rewrite the code to be more robust against unexpected weight values.
Also make detected problems non-fatal.
Reported-by: František Hanzlík <frantisek_hanzlik@protonmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Windows seems to construct the font names including the PS weight.
We have some sourcefonts that are broken (i.e. have in fact different
weights but have the same PS weight and/or OS2 weight.
That raises problems with the fonts on Windows.
[how]
Check and compare all weight metadata (except CID) and issue a warning
if they differ too much. That might fail with unusual weight names,
though.
See Issue #1333 and PR #1358.
Reported-by: LeoniePhiline
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]
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]
The intend was to drop 'Sans Mono' in the renaming process, because the
name is just too long.
ERROR: VeraMono-Italic.ttf ====-< Shortening too long PS family name: BitstromWeraSansM Nerd Font Mono -> BitstromWeraSansM Nerd Font Mon
ERROR: VeraMono-Italic.ttf ====-< Family (ID 1) too long (32 > 31): BitstromWeraSansM Nerd Font Mono
[how]
Include the whole name in the replacement pattern.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The license of Bitstream Vera requires patched fonts to contain neither
"Bitstream" nor "Vera" in the name. It explicitly requires that also
for fonts that (only) add some glyphs.
Yes, we are rather late to notice this :-( Sorry.
[how]
Rename Bitstream Vera to BitstromWera, and also drop the Sans Mono part
of the name. The new name looks and sounds similar enough to get the
reference, while being shorter and somewhat logical.
Fixes: #1173
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Because we do not know if a complete family of fonts has an italic face
we must always assume it does. To get clean RIBBI families in ID1/2 we
create a different family for the oblique slant.
But that is not needed if the font does not have an italic slant, but
just an oblique one (like Bitstream Vera and descendants).
[how]
Add new command line option for font-patcher that specifies if the
family of fonts should be patched under the assumption that there might
be an italic face (default), or if we are sure there is none (and we can
leave oblique in the RIBBI group).
This is then applied to the config.cfg files.
Note that this does not take into account any other of the known_slants.
But they are not encountered in any of our prepatched fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Oblique is not detected correctly anymore.
[how]
With commit
ae656bad8 name-parser: Further formalize style handling
'Oblique' has been taken out of the direct 'known_names' which has been
replaced by a more detailed list of known name parts. It ended up in
known_slopes.
But known_sloped is not taken into consideration as 'weight' when parsing
the font name - no it ends up in 'rest'.
This has been obviously overlooked.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
