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

I’ve encountered another problem when exporting spin-off instances. It was pointed out to me that the tabular smallcaps figures looked weird in the SC exports. I was confused, since I hadn’t drawn any tabular smallcaps figures in the first place. It turns out that I had used some regular figures as components in my tabular figures, and when I replaced the regular figures with smallcaps figures as part of my custom parameters upon export, those components also got replaced.

That’s very strange and unexpected behavior. Could you please implement an instance-wide execution of «Decompose Components» at the beginning of any export sequence? Or is there at least a way to force that using custom parameters?

This same problem has come up with my newest project. I had /u as a component in /tse-cy, but in the instances where I replace /u with /u.ss01, the component in /tse-cy erroneously also gets replaced. I would like to run a «decompose all» on the instance before applying the replacements. Is there a custom parameter for that? (It would probably be a good idea to do that by default upon export…)

The Rename code is run before you can decompose things. In this case I would suggest to make an extra ‘u.comp’ that has the outlines of the ‘u’ and is used as component in ‘u’ and ‘tse-cy’. Then you can rename the ‘u’ and the ‘tse’ stays intact.

OK, thanks for the workaround.

Is there a downside to doing a decomposition by default before applying custom parameters, though? The same problems appear when applying other custom parameters (e.g., Cursify does weird things to composed glyphs sometimes). You could probably save a lot of people a lot of workaround work with that one weird trick. :wink:

But other people like the catch all occurrences of the components. Like if you what to change a round to a square tittle on the ‘i’. Or change the shape of a letter and all of its components.

I’d expect them to make a .ssXX version of those letters with, say, a square dotaccent.ssXX for a tittle… sure, it’s more work than letting a custom parameter generate those alts for you, but then again, at least you get to preview and tweak those alts whereas the custom parameter method is a shot in the dark.

Ideally, there’d be a custom parameter you can toggle to decompose before applying other custom parameters…

I’ve started working on my Cormorant family again after a longer period of leaving it in peace, and now I can no longer export it. The following error message appears when Glyphs should start exporting the «Unicase» cuts of my family. No doubt it has something to do with the export script, which overwrites some glyphs with others. It has worked nicely so far, though… did you change something about the way such replacement rules are executed?

Cheers, Christian

This is the Glyphs file in question:

I’ve also looked at the macro window, but there are no messages there.

I’d really appreciate some help on this; the issue is completely blocking my progress with Cormorant at the moment.

What version did you have? It works fine with the latest beta of 2.3.

Hi Georg,

awesome, that did the trick. :grin: I was using 851 before… I guess I should always update before reporting an issue. Sorry for the bother!

(EDIT: I thought there was still a problem with unlinking before applying glyph replacements, but I now believe that was just a symptom of a wrong script of mine. Seems to work just fine now! :grin:)

…and now I’m getting another weird error. My features won’t compile anymore, claiming that CALT refers to the non-existing glyphs /q.medium and /q.long. As the screenshot shows, it doesn’t. Actually, /q.medium and /q.long do appear in the replacement CALT feature that I’m writing into some of the exported instances. However, those instances also contain glyph replacement code that will create /q.medium and /q.long glyphs.

Can I somehow convince Glyphs to let this perceived error slide…? Short of creating some dummy /q.medium and /q.long glyphs just to shut it up…?

How do you do that? Are you using the Parameter Export Glyphs?

The error message sometimes points to the glyph next to the one that is actually missing.

I don’t know about that parameter. I’m using renameGlyphs and replaceFeature.

Well, adding a (pointless) /q.medium and /q.long actually got rid of the error message…

So you meant that you created the glyphs in feature code?

Not sure what you mean. I created the glyphs, period. I didn’t change the feature codes.

I was wrong about that after all; the unlinking still doesn’t work. Here’s how my Cormorant Unicase turns out in Cyrillic. Unicase replaces the /t.sc by /t.sc.ss05. Since /te-cy.sc contains a link to /t.sc, it also gets turned into /t.sc.ss05, which is not appropriate. This really shouldn’t happen.


(Alright, this actually looks somewhat sexy, but probably confusing to Cyrillic readers… in general, though, replacing a character by another should not have undocumented and unpredictable ramifications for other glyphs.)