Setting widths of figures - bug?

Glyphs
#1

I have a font file with oldstyle and lining figures in both tabular and proportional widths, which I created in FontLab.

I am now editing it in Glyphs and I notice that the tabular figures which were components of the default oldstyle proportional figs centered on a 500-unit width now seem to bear the widths of their proportional siblings. And when I try to give them a width of 500, it doesn’t seem to be possible.

Is Glyphs guessing from the name that these are supposed to remain the same and enforcing that? That would be useful in the case of a, á, à, ä etc., but obviously is problematic for figures intended to be on different setwidths.

If it matters, I have used my own suffix convention rather than Glyphs’s (e.g. /one, /one.lnum, /one.tnum, /one.lnum_tnum).

Also if it matters, I have oldstyle figures in the default (/one, /two, etc) slots. Side question: does that design decision prohibit me from taking advantage of Glyphs’s internal understanding of figures as determined by naming scheme?

#2

  1. Add a single point with the path tool. Then the metrics are not kept in sync with the base glyph. The dot constitutes an open path and will therefore be ignored on export.

  2. It’s a bad idea to use underscores in glyph name suffixes (like ‘.lnum_tnum’). Underscores are reserved for ligatures.

  3. The advantage of using Glyphs’ suffix naming suggestions (old-style = .osf, lining = .lf, tabular = .tf, tabular old-style = .tosf) is that Glyphs can generate the Opentype features automatically. If you use your own, you’ll also have to roll your own feature code.

#3

  1. Thanks, I’ll try that workaround. Though I wonder if that will mess with the master compatibility.

  2. Hmm, those underscores were from a long-ago recommended practice from the FontLab folks.

  3. I already have the figure code “rolled” from this font’s former life within FontLab, and I’m happy to have that sense of control over it. But it would be nice for the number Categories in the Font window to pick up the different variants, which perhaps adoption of the Glyphs naming scheme would enable… EDIT: or, as I’ve figured out, I can just make my own filters with custom lists.

#4

re 1.: Simple, add that point to every master.
re 2.: A PDF reader might decode one.lnum_tnum to ‘1’ plus an unrecognized character. That might mess things up if a user tries to copy text from a PDF that uses your font.

#5

re 2.: I thought that danger only came up if an underscore was included in the part of the name before the period.

#6

Found another place where Glyphs’s eagerness to maintain widths is too strong: ldot. This glyph will never be the same width as /l/, but the app insists on it.
Adding a point as suggested above works as a workaround, but doesn’t feel right! I think there should be some way of untethering metrics for glyphs like this.

#7

There is on option. If you use a glyph called “__dot” (the two underscores are important), the width of this letter will be added to the glyph. so make the glyph as wide as you need additional spacing.

And I’m working on improving this.