Glyph Construction/Builder doesn't automatically set unicode
martin last edited by gferreira
When I use the extension Glyph Construction/Builder something like the following will generate a glyph but without a unicode value:
aring = a + ring
I find this to be unexpected, for adding
aringvia Font > Add Glyphs will trigger the correct unicode, based on the GNUFL definitions which are built into RF. Wouldn't it make sense to implement that behavior into the extension Glyph Construction/Builder too and automatically set unicode values based on glyph name unless a different unicode value is supplied?
My thinking: if RF/GNUFL already knows the unicode for
aring, why would I have to supply it again (risking errors) in my Glyph Construction/Builder file.
[I’m not quite sure where to go with this suggestion. Is this Forum or GitHub the right place?]
StephenNixon last edited by
This would be a nice feature!
It takes me quite awhile to get the right unicodes each time I make a Glyph Construction file, so anything to speed up the process would be excellent.
FYI: this has been an issue for a while see https://github.com/typemytype/GlyphConstruction/issues/12
lets do something about that :)
how about adding a auto unicodes checkbox under the Build button?
edit: scratch that – better to put it in the Build Glyphs sheet:
martin last edited by
@gferreira cool. So Glyph Construction Builder would automatically add unicodes (Yasssssss) while Add Glyphs would have a checkbox where that behaviour would be switched off/on. That would be super!
martin last edited by
Hi @frederik thank you, very much appreciated!
I tried updating to the recent version and am now getting this error
@youbringfire maybe you are using RF 3.1?
ufoLibas part of
fontToolswas introduced with RF 3.2 (see the release notes)
@gferreira I'm actually using Version 3.2b (built 1809041630)
@youbringfire right – that’s a beta version from before the
ufoLibmove. please upgrade to the final 3.2 release, and the error will go away.
I’ll update the extension soon, so it’s backwards compatible with < 3.2
@gferreira ah I understand. Thanks for the heads up, will give that a shot!