Closed Notaduck closed 4 years ago
Same issue here. I tried to add ligatures to Dank Mono
.
fontforge -lang=py ligaturize.py --prefix=Liga "input-fonts/DankMono-Regular.ttf" "output-fonts/LigaDankMono-Regular.ttf" 2>&1 \
| fgrep -v 'This contextual rule applies no lookups.'
Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
Based on sources from 00:15 UTC 31-Jul-2017-ML-D.
Based on source from git with hash: b9149c13e8f9464fc21473f1f676b36a2130775d
The following table(s) in the font have been ignored by FontForge
Ignoring 'DSIG' digital signature table
Reading ligatures from fira/FiraCode-Regular.otf
Exception while adding ligature: {'chars': ['ampersand', 'ampersand'], 'firacode_ligature_name': 'ampersand_ampersand.liga'}
Traceback (most recent call last):
File "ligaturize.py", line 275, in <module>
creator.add_ligature(lig_spec['chars'], lig_spec['firacode_ligature_name'])
File "ligaturize.py", line 162, in add_ligature
self.font[ord(char)].glyphname = char
TypeError: ord() expected a character, but string of length 9 found
facing the same issue
There's two issues here.
@notaduck "TypeError: expected bytes, str found" is characteristic of trying to run it via a Fontforge install that uses Python 3. How did you "try it with both python 2 and python 3"? In my experience with fontforge it's either one or the other. I should probably add a check to FF so that it fails fast if run inside py3.
@shamilchoudhury I'll look into this.
@ryands17 Which issue?
@notaduck I've pushed a version that should now fail unambiguously if it's running under Fontforge with Python 3; try that to make sure you're actually running it under Py2 when you think you are. If you're still getting that error in Py2 it's a different and new issue.
@shamilchoudhury Reading the code, the wheels are coming off when it tries to find the glyphs in the target font that it needs to add ligaturization rules for. It tries to look it up by name first, and if the name lookup fails it assumes that it's a plain letter and looks it up by codepoint.
In this case it tries to look up "ampersand"
, can't find it because Dank Mono doesn't have glyph names at all (I assume; I don't have a copy myself, and since it costs $40 I'm not likely to), tries to look it up by codepoint, and dies because ord("ampersand") is not valid the way ord("&") is.
It might be possible to mitigate this by storing the full name -> actual character mapping so that it can just look up everything by codepoint; if implementing this doesn't break its support for existing fonts I'll do it, although I have no way of testing if it works on Dank Mono.
@ToxicFrog Thanks for looking into this. If you could implement the full name --> actual character mapping in a separate branch, I'd test it with Dank Mono
.
@shamilchoudhury but dank mono explicitly has built in ligatures, it's one of the main reasons to buy it...
Should be fixed with #73
I tried to use your tool to add ligatures to these font's
But I do get this output(I tired with python 2.x and 3.x):