Exporting spin-off instances (SC, SS01, etc.)

Scripting
42

Replacing depending components is not unintended and unpredictable. Accented letters depend on it. I need to think about this.

43

I think we’ve discussed this before
 if you have an /a.ss01, you’ll want to create an /aacute.ss01 as well that contains the /a.ss01 as a component. If you just replace the /a by /a.ss01 and propagate that to the existing /aacute upon export, the position of the acute, the metrics, and possibly the kerning classes will no longer be correct. That’s not a workflow Glyphs should encourage. Of course, you’ll also want to be able to access the feature via SS01 in the original font, which wouldn’t be possible that way.

44

Please implement unlinking before glyph replacements; its current omission is a dangerous bug, not a feature. Here’s an example of the bloody mess that it creates:

45

That problem can be solved by the “Decompose Glyphs” parameter that is new in 2.3.1 (905).

1 Like
46

When will that be released?

47

I just uploaded it. It is not 905 but 904 :wink:

48

Hooray! :smile:

49

BTW, what’s the proper value for Decompose Glyphs? True? Shouldn’t that be the default value when the feature is created?

EDIT: The value «True» doesn’t seem to do the trick. :frowning: No error message, though.

50

A list of glyph names.

51

Oh, OK, that works.

What I still find strange, though, is that when I replace /a with /a.sc, the original shape of /a gets stored in /a.sc instead. Also, although I use a Remove Feature custom parameter for smcp when I export my SC fonts, the feature still persists in the exported fonts, which then proceeds to replace the smallcaps glyphs with lowercase glyphs! Very unexpected indeed!

EDIT: OK, so I made a mistake in the custom parameter
 I removed the feature «sc» rather than «smcp». Still, it’s weird that Replace Glyphs apparently swaps rather than replaces glyphs.

52

That was a frequent feature request, and is now implemented in 2.3.1. You can disable the other glyph with the Remove Glyphs parameter.

53

I notice I’m still getting these glyph replacement glitches despite my use of the Decompose Glyphs custom parameter. For instance, I replace /y with /y.ss01 (infant /y) and then feed /y to the Decompose Glyphs parameter, but that doesn’t catch the fact that /u-cy is linked to /y. So in the exported font, /u-cy is going to look like /y.ss01 but retain the advance width, anchors, and kerning behavior of the original /u-cy. Bad idea!

I guess I should have my scripts generate a list of all glyphs and feed that to Decompose Glyphs, just to be sure I don’t miss anything. Is there a downside to unlinking all glyphs prior to export?

54

No downside, CFF fonts must be decomposed eventually anyway. TTFs can have components and save some file size this way, but if you decompose wisely, that should be fine too. You should be able to use LayerGeek as a Prefilter for that purpose.

55

You don’t decompose the ‘y’ but the ‘u-cy’.

56

The problem is figuring out what glyphs need replacing. When I make an alt for /y, I don’t necessarily think about its ramifications for /u-cy; that’s how these mistakes happen.

I’ve taken to feeding the Decompose Glyphs custom parameter the full glyph list, though, so that should be moot from now on.

57

There is the ‘Show all Glyphs That use this as component’ in context menu of the edit view. Then you have your list.

58

Edit:
For automatically generated OT-Features, Remove Glyphs or Keep Glyphs Custom Parameter will deal with the feature code.

What about manually written code? Would it be possible to exclude lines of code if the glyphs are not there anymore? Quite a complex mechanism I guess 


59

You can redefine features with a parameter. You will have to enter the complete feature code though, it does not work line by line.

1 Like