I’m encountering two issues while using the LTTR/INK plugin with smart components in Glyphs. Any help would be greatly appreciated!
Interpolation Error with Smart Components in Glyphs 3.3.1 (3340)
I’m using the LTTR/INK plugin alongside smart components to create a font. For the smart components, I’ve disabled the brush function in LTTR/INK. However, when I adjust the values of the smart components, I get interpolation errors.
Unable to Disable Brush Function for Individual Glyphs in Glyphs 3.4 (3414)
In the latest version of Glyphs 3.4 (3414), I cannot disable the LTTR/INK brush function for specific glyphs individually.
Has anyone experienced similar issues or found a workaround? Thank you in advance!
Re-posting the same post again is not welcome. Please be patient, whoever can help you with your issue will get back to you on your post, it might take a day or two.
Great to see you here! I think this issue might be a bug in Glyphs, which is why I didn’t email you directly.
The test file you need is already uploaded in the thread. You can download it there.
I understand the method you mentioned, but the problem is that you didn’t add adjustable layers to the smart components. When you add multiple adjustable parameters, the interpolation error occurs. Please download my test file for reference.
You know that you can do the same thing much easier without lttrink (not saying that you shouldn’t use it)? You could use the build in path offset. And have a look into corner components.
Thank you, Georg, for your response. Yes, there are certainly more ideal ways to handle the test file I provided. However, this file isn’t my actual project—it’s just a sample created to help illustrate the issue clearly. In reality, this problem has been troubling me for a long time, which is why I’m seeking help here. When using LTTR/INK to design Chinese fonts, some strokes cannot meet my design requirements with LTTR/INK alone, so I’ve been using smart components to work around this.
I can also reproduce the the issue with the unintentional application of LTTR/INK strokes in the cutting-edge build as reported by @7canfei and @xyzajacf, whereas it appears correctly in older builds.
@GeorgSeifert, could you please take a closer look at the issue? If it turns out to be something that needs to be addressed on our side, I would appreciate any insights you can provide, as well as access to a cutting-edge build to help with debugging. Thank you.