[why]
In the patch loop we use two methods to do something with the glyphs
- the glyph object directly (i.e. font[codepoint])
- a selection of glyphs in the font
Using the selection is a bit anonymous and depends on lines far away
(where the selection is set); direct glyph access seems to be easier
understood and is used almost everywhere.
Direct glyph access can not be used for copy() and paste(), but for
everything else.
[how]
The direct glyph addressing is already in use almost for everything, but
not for the transform() calls. This is changed.
Now we transform a specific glyph and not 'all selected glyphs' (with
selection = that specific glyph).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The selection is never used.
Later in the code we use a sourceFont selection to paste the glyphs into
it, but that is selected just there, before, and locally not totally.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This is a TODO item. Well, two in fact.
The symbolFont's selection is used for two things
- the main loop to iterate over all glyphs to insert
- to select the one glyph that is actually copied over
Because the main loop uses iterators on the selection.
The iterator is not 'stable' but invalidates if the selection
is changed.
The current code therefor restores the old selection before the loop
jumps to the head again.
This design is not very robust.
[how]
We need the selection to copy the symbol glyph.
But we can rewrite the loop that it does not need the selection at every
iteration, but that the selection is copied into a list, and we loop
over that list - which is independent on a later selection state.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In some fonts, on in the `patched-fonts/` directory the font information
files contain an explanation why the font is called "Terminess" and not
"Termius" - but the font is neither.
Affected: DroidSansMono and Ubuntu (non mono)
I assume this is a 'I copied the info file over from an existing font
and just change the names' (but the source was unfortunately Terminess).
[how]
Manually remove the paragraph from all files that contain it which but
have another name altogether.
[note]
Not shure if they are autogenerated somehow, with for example
`standardize-and-complete-readmes.sh` ... but a `git grep` showed only
the files that are changed with this PR.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some of the patched Mono fonts do not turn up in the font chooser
of Windows CMD and PowerShell (and probably more).
[how]
For some reasons Windows does not identify the fonts as being strictly
monospaced, so they are hidden in that font choosers.
For the monospaced fonts we set now the Panose proportion 'monospaced'.
Windows seems to honor the Panose properties.
It is not clear why we need to set the old Panose props, especially as
Cascadia Code does not (!) set them and is still detected as monospaced.
Anyhow, the way Windows detects if a font is monospaced is a mystery (at
least for me), and this works, so ;-)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This fixes the Docker image build after changes in 9633b4d moved
PowerlineSymbols.otf into a subdirectory. Previously, the
.dockerignore line for src/glyphs/*.* would exclude any
subdirectories in src/glyphs from being included. Without this
change, a complete font build fails.
[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>
