[why]
Previously we had the tag 'master' set in all images, as the images were
created with every push the default branch (i.e. master). Some people
might use that tag for something.
At least we can not remove the last image with 'master' tag, and it will
become outdated immediately, making it a misnomer.
[how]
Add both tags. Hope this works ;-)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font-patcher version of a concrete container is a useful information
if you want to use a not-latest version.
[how]
Add the font-patcher version, that is extracted by grep. Not the most
stable of all solutions but I guess it is good enough.
Fixes: #1267
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The "all" range just prints again all the ranges that we previously
already printed (?!!).
As we can not select individual sets this does not make much sense.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a set has multiple ranges defined only the last of that ranges is
actually printed.
[how]
With commit
7a4b5f872 Fixes build errors (ShellCheck)
a false positive of spellcheck lead to a 'correction' in the code that
actually broke it. The mapfile does not accumulate the sequences but
fills it in and so just the last sequence 'survives'.
Dropping mapfile also enables this script on MacOS, as that ancient
bash does not have mapfile.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code is hardcoded for 4 (hex-)digit codepoints. If we want to
examine 3 or 5 digit codes it breaks the formatting.
[how]
Switch from \u to \U to allow printing codepoints with more than 4
digits. This works on all machines I tested (Linux/Mac).
Manually pad the codepoint to get a consistent length independent of
actual number of digits. We can not use "%5x" because we want to
underline only the actual digits.
This also makes the output of empty slots nicer because the underline is
skipped if there is no code.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
- 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>
