I have an /emdash and /endash that has a component of /hyphen that is stretch non uniformly.
My instance with RoundCorner filter show stretched round corners in the preview pane, but on export it seems the behave like you would expect. It would of course be nice if it looked just like on export.
Stretched corners, from the preview pane:
/hyphen /emdash /endash
I’m guessing it’s a matter of order of decompose -> RoundCorner vs. RoundCorner -> decompose.
Latest version: Version 2.3.1 (908)
Can you send me the file?
Sure. I sent it to you now.
I had a look at the file. It happens because the filter is applied to the base glyph and then the component is scaled. This will be the result if you export as TrueType.
Of you export as OpenType, all components are decomposed befor the filters are applied. So there is no scaling in this case.
I have a look at it to make it react the same in all three cases.
Thanks. I figured it had something to do with the order of application.
I hope that the correct order on export and preview would be:
At least that would be the best order for my rounded corner use case with stretched components.
If you’re using the RoundCorners filter, I suspect you might want the “Remove Overlap” to happen before RoundCorners. Otherwise, you might find artifacts you weren’t expecting, depending on how different paths overlapped.
Oh, you’re right, that makes sense actually. I forgot that the round corners are not applied to inward corners anyway.
But it seems, though, that it isn’t applied to components either with or without RemoveOverlap; in Custom Parameters.
Thinking about it I see pros and cons with both decomposing components before and after adding Round Corners or Rounded Font. Not sure which I personally would prefer as the default but it would be nice to have control over the order of it.
There is a custom parameter ‘Decompose Glyphs’. That is applied before the filters. The parameter accepts a list of glyph names. This will solve your problem.
Thanks Georg!
