Closed punchcutter closed 6 years ago
So this is basically the same issue as notofonts/khmer#23 These should be decomposed in the sources. Maybe Zachary can send a pull request to Noto-source?
This is a totally different issue from https://github.com/googlei18n/noto-fonts/issues/1012 which is why I opened two. Decomposing will "fix" that issue, but that's just a coincidence. For this one users complained that stroking the text revealed the component lines (with TTF only of course) so I'd like to decompose so we don't see that. I could send a pull request, but we might want to run through QE first so better see what @marekjez86 and @waksmonskiMT think.
Actually, I just noticed that for the components shown in the screenshot above they are set to not export in Glyphs so Glyphs decomposes them and removes the source glyphs, but pipeline doesn't. Also related to this are the custom parameters on instances: Keep Overlapping Components
and Decompose Glyphs
. These will also affect how these components are dealt with.
@anthrotype I guess we should open new issues on ufo2ft for these? These Khmer specific issues will go away when we redeliver, but the issues of handling components in TTF will remain.
Yes please open separate issues for them. Thanks for debugging!
unable to reproduce it with the most recently built sources/fontmake
There are components used in Noto Khmer for both Sans and Serif that should get decomposed so they don't end up in TTFs. Otherwise when trying to stroke text in Adobe apps it looks like this: These should have been decomposed, but I guess I missed it when originally delivered.
When these components aren't decomposed we can run into this interpolation issue: https://github.com/googlei18n/noto-fonts/issues/1012