07a23bda90
[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>
|
||
|---|---|---|
| .. | ||
| FontnameParser.py | ||
| FontnameTools.py | ||
| query_monospace | ||
| query_names | ||
| query_panose | ||
| query_sftn | ||
| query_version | ||
| README.md | ||
Creating Consistently Grouped Patched Fonts
This is a small sub-project to font-patcher that uses a little bit more knowledge to come up with font names and name parts. In applications multiple fonts are grouped under a 'Family'. Each member of the Family has a different 'SubFamily' or 'Style'.
Consider a font named 'Times' that has two variants: normal and bold. For this font the Family would be 'Times' and the 'Style' would be 'Regular' (i.e normal) in one file and 'Bold' in the other file.
With this information applications are able to group all 'Times' together and additionally choose the 'Bold' font if the user pushes the 'B' button on the font style dialog in that application.
Motivation
Quite a number of patched fonts have inconsistent or simply wrong font grouping. The naming in general is sometimes surprising and not following naming conventions. This is in part due to the font-patcher, but in part the source fonts are already strange. This results in invisible (but installed) fonts in some applications, inconsistent naming (Familyname differs from Fullname) and not correctly working bold/italic selectors in some applications.
And we would like to have the information within the names sorted in a consistent way. usually a font name consists of these parts (in this order):
- Name base (e.g.
Noto) - Variant (e.g.
Sans) - Subvariant (e.g.
Display) - Weight (e.g.
Black) - Style (e.g.
Italic)
This is important because we want to add subvariant information, namely the Nerd Font part.
Example:
- (old)
Iosevka Term Light Italic Nerd Font - (new)
Iosevka Term Nerd Font Light Italic
The Plan
To solve these issues the font name parts have to be analyzed more thoroughly and then categorized. These categories are then used to assemble the names in correct order. The simple (not typographically aware) applications shall always get groups of at most four styles, and these are Regular, Bold, Italic, and Bold-Italic. Other styles turn up as Families, because this is the only way they would work in these more simple applications.
Typographically aware applications, on the other hand, get all styles grouped under one Family name.
First experiments showed that the full information can usually be restored already from the file names that our source fonts have.
This new naming is complete optional (but recommended). Give the option --makegroups to font-patcher
and it will try to come up with reasonable grouping and naming. Leave the option out and it will
work as it always did.
The Tests
In this directory were two tests. If interested you need to go back in the git history. They are not needed anymore.
Helper scripts
There are some helper scripts that help examining the font files. Of course there are other, more professional tools to dump font information, but here we get all we need in a concise way:
query_monofont_name [font_name ...]query_namesfont_name [font_name ...]query_panosefont_namequery_sftn[<sfnt-name>] font_namequery_versionfont_name
They can be invoked like this $ fontforge query_sfnt foo.ttf.