question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[feaLib] Handle dash in glyph names

See original GitHub issue

I know this has been discussed before, but it’s still a pain, that glyphs2ufo chained to ufo2ft can fail. In my example:

fontTools.feaLib.error.FeatureLibError: features.fea:12:5179: Bad range: "LL" and "middleWelsh" should have the same length

I like to suggest two changes to feaLib, both of which will ideally be pushed to AFDKO / Fea spec as well:

  • A dash, when following a backslash, can be part of a glyph name to mean a single ‘dash’ and as such work around the current limitation that dashes cannot be part of glyph names. In fact, I’d go as far as suggesting that a backslash would escape any punctuation to be part of the glyph name,
  • When the above-mentioned error occurs, ie. when a dash range fails to parse, then try parsing the dashed sequence as a glyph name (only if there were no spaces involved). In fact, in most cases, either a range or a glyph name is valid, not both. It’s ok to fail if there is ambiguity.

Implementing one or both of these makes the glyphs2ufo+ufo2ft experience much better. Right now, fontmake replaces dashes with underscores before calling the above tools. That’s too much to ask each client to do.

@schriftgestalt @jamesgk

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:25 (15 by maintainers)

github_iconTop GitHub Comments

2reactions
brawercommented, Mar 29, 2016

Personally, I think fonttools/feaLib should implement the published specification, not deviate from it. The proposed fallback logic sounds quite interesting, but I think it would need to become part of the spec before fonttools implements it. (Otherwise, we’ll have a chaos pretty quickly).

1reaction
readrobertscommented, Jun 6, 2016

No. I thought I had updated the MakeOTF user guide, but the new characters are currently documented nowhere. The current set is “- + * : ~ ^ !”. Note that the only spec for final glyph names in a font is still the Postscript and Type 1 specs, which do not permit these characters. I don’ t think there should be an official spec for development glyph names, which can be anything that a set of development tools support. I do agree that a set of shared conventions would be useful. I will add documentation for the FDK names to the MakeOTF user guide.

Read more comments on GitHub >

github_iconTop Results From Across the Web

.fea syntax now allows dashes in glyph names · Issue #148 ... - GitHub
brawer is this implemented in feaLib already? We should confirm that, then remove the "Illegal glyph name..." warning from glyphsLib, and remove the...
Read more >
feaLib: Read/write OpenType feature files - fontTools
fontTools' feaLib allows for the creation and parsing of Adobe Font ... If the iterable is left empty, no glyph name in glyph...
Read more >
Getting your glyph names right
The nice names we discussed above are only handled inside of Glyphs. ... Open your Glyph Info palette and type a dash in...
Read more >
FontLab 7 Release Notes Part 4
Glyph names, OT features, text, layers, color, files, UI, Python, varia ... you need to surround the glyph name in quotes to distinguish...
Read more >
Special dash things: softhyphen, horizontalbar - TypeDrawers
Do browsers' implementation of hyphenation display this glyph, ... Can you give me the name of an application that will handle correctly ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found