[why]
Sometimes fontforge returns None for font.path. That should not be the
case according to specs:
font.path
(readonly) Returns a string containing the name of the file from
which the font was originally read (in this session), or if this
is a new font, returns a made up filename in the current directory
named something like “Untitled1.sfd”. See also font.sfd_path.
This seems to be the case for fonts that do not have a fullname set.
I did not search for nor file any issue at Fontforge.
[how]
In fact we already have the original font file name, and we want to
retain its extension anyhow (if nothing is specified), so we use the
filename that we opened to determine the extension.
[note]
Related: #412
Related: #641
[note]
This was the sole usage of font.path.
Has been introduced with commit d8b760aee which looks uncritical.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we overwrite a glyph that originally had some special handling, be
it a substitution or position table entry (GPOS/GSUB), that special
handling is usually not appropriate anymore and has to be removed.
If we need special lookup table entries for the new glyph we would have
to add them later anyhow, because we can not rely on their existance.
In Issue #509 it was a ligature entry, that replaced 'f' followed by 'i'
with the 'fi' ligature. The ligature glyph is overwritten by us with a
telephone symbol and the substitution table entry makes no sense
anymore.
[how]
If we overwrite a preexisting codepoint we remove it from all lookup
tables.
Thanks to all other reporters with details.
Fixes: #509#254
Reported-by: mangelozzi <mangelozzi@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the font file is not existing the message we get is either
unreadable or missleading (at least for normal users).
[how]
Explicitely state why we can not open a font file, at least in the cases
where we can.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Nerd Font Version is not added to the SFNT Version.
This is also a TODO item in `font-patcher`.
The SFNT-Revision is not updated at all.
[how]
Set the SFNT Version and Revision.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
f7d6fcb5 font-patcher: Allow processing of fonts with fsType set
we added support for fonts with the fsType set. This came up in
issue #686 with font 'Bicubik'.
The solution in that commit uses (modern) textual flags in the
`fontforge` open() method. But they have been only introduced in 2020,
so people using older `fontforge` could not patch anything anymore.
This has been reported in issue #691.
As a quick fix the fsType support has been removed with commit
ab6fa3c5 Reverts part of #687 * the patcher refuses to patch all/most fonts with this flag in the open options
[how]
Revert f7d6fcb5 but use the old fashioned numerical open flags
interface instead.
[note]
The textual open() flags have been introduced into `fontforge`s python
interface with their commit
4a76712f0c
Font Open flag improvements
* Document more Open flags
* Add string tuple interface to python FontOpen API
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When fontforge is not able to open the font we fail with a meaninless
exception. Users might think that the font-patcher script itself is
broken.
[how]
Exit the script with a hint how to get more information if fontforge was
not able to open the font.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Through fsType certain restrictions can be set on a font. When fontforge
is used in interactive mode the user can override the restrictions with
a popup dialogue. The font-patcher script dies instead, without any
meaningful message.
[how]
Allow the script to ignore fsType settings when opening.
The restrictions will still persist into the generated patched font.
[note]
This came up with Bicubik by Anton Kudin, that has fsType = 2
(modification restriction) set.
Fixes: #686
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Useful for allowing installation in system wide
locations as a package from the package manager.
This way the script can be installed in /usr/bin
and glyphs can be in /usr/share/nerd-fonts/glyphs.
Signed-off-by: Aisha Tammy <floss@bsd.ac>
[why]
With a source font where Win Ascent/Descent differs from Typo
Ascend/Descent newly added symbols that are intended to be centered
_within the visual space_ can end up too far up or down.
The happens for example when patching CascadiaCode. Added glyphs like
the Ubuntu logo (unicode 0xF31B) is not centered between the square
brackets or on a line with the less then and other centered glyphs.
[how]
The calculation takes the Win Ascent/Descent to calculate the visual
hight. That information is a mix of hight and line spacing and can be
misleading.
Therefore, if use_typo_metrics is set in a font, we obey that flag
and use the typo metrics values instead.
[note]
Some websites with further information follow.
https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics
> Hhea metrics are used in Mac OS X, whilst Microsoft uses
> Typo when Use_Typo_Metrics is enabled
https://docs.microsoft.com/en-us/typography/opentype/otspec160/os2#fsselectionhttps://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
I keep seeing this warning when running `font-patcher`, and realised this is a relatively simple fix. This property expects and `int`, but a `float` is passed and implicitly cast.
This squelches the deprecation warning, and keeps the code future-proof too.
```
/nerd/font-patcher:823: DeprecationWarning: an integer is required (got type float). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
glyph.left_side_bearing = 0.0
/nerd/font-patcher:825: DeprecationWarning: an integer is required (got type float). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
glyph.right_side_bearing = 0.0
```
[why]
Some glyphs are just used as overlays for 'real' glyphs. These can be
for example U+0300 .. U+036F (the 'COMBINING ...' diactritics) like
U+0300, gravecomb, COMBINING GRAVE ACCENT
U+0301, acutecomb, COMBINING ACUTE ACCENT
U+0308, uni0308, COMBINING DIAERESIS
They are never used on their own, at least they are overlayed over a
blanc (U+0020, space).
For the font rendering engine they need to have the correct negative
bearings, so they are shifted to take no space by themselves.
The font-patcher script does not allow negative bearings in monospaced
fonts. This makes sense if every glyph is in itself a 'letter' that
should not reach beyond it's allotted (monospaced) space.
[how]
In the font-patcher script we do not touch the bearings of such overlay
glyphs. They can be identified by their width of zero.
For Windows to detect this font as 'monospaced' we need to change the
width to the standard width, though.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some reason reading a font into fontforge looses data on glyphs. As
a workaround the `font-patcher` script has the switch `--mono` to
ascertain an equal width of all glyphs. We want to (and sometimes need to)
use that mode of the script to get a new font that is detected as monospaced
by Windows.
Sometimes that workaround fails. For example it breaks ligature glyphs
in some circumstances; they seem to be moved sideways.
[how]
The workaround is done in two steps: First each glyph is checked for
negative bearings. If these are found they are set to fixed zero.
Afterwards the glyph width is set to the font global width.
The ligature glyphs have already the correct width, they just have
negative bearings that they indeed need. There is no reason to change
the (correct) bearings to get a monospaced font. In strict monospaced
fonts that would be impossible, but the ligatures are only used in
applications that could work with negative bearings and so they should
be there. Strict monospaced usage does ignore the bearings anyhow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
