Hello,
I am not sure if this should work this way or if I am running into some kind of problem, but there seems to be no difference between various fonts (within one font family) when rendering with scalable mode. For example below is gif with Bahnschrift font family - showing each font available in this family, but they all look the same. (This isn’t the case when rendering in polygon mode.)
Please is this expected behavior? Thanks.
1 Like
Unfortunately that is an expected limitation at the moment with the font engine that we’re using for the scalable fonts. Bahnschrift is variable font that is actually just one set of character glyphs with additional instructions in it for how to render those different variations (condensed, semibold, etc).
I’ll reach out to the development team that makes the font engine to see if any work has been done on this since we last talked to them about it, but in the meantime it might be possible to make a static font file for a specific variant if you’re interested in trying it. The python fonttools library apparently has a system for it: instancer — fontTools Documentation
Thank you very much for help. I didn’t realize those are variable fonts. Yes, I recall I have used fonttools for this kind of conversion some time ago, it should work fine - I am going to generate static fonts as suggested. Thanks!
1 Like
Looking at instanced Bahnschrift font I have noticed some strange rendering on certain glyphs. Feel free to take a closer look at top and bottom of R, E and D in following gif. When top / bottom lines are between pixels, there are areas that kind of stand out.
Once I have dived into Bahnschrift font I have realized this is caused by overlapping shapes - as visualized here.
It seems that these overlapping areas aren’t working good with Slug library - which is completely understandable (two overlapping shapes produce stronger edge with their algorithm). I guess there will be also other variable fonts with these sort of issues (I guess it makes sense for variable fonts to design glyph shapes this way).
I know this isn’t related to TD, but it is something I have noticed and thought I might post it here. @robmc maybe if you are in contact with Slug developers you could forward this to them - just to let them know about this sort of issues (if they haven’t noticed it yet)? My first idea was to somehow unite these shapes before rendering in Slug, but I am not really sure if that could be performant / good enough solution.
Thanks for the details - that’s interesting to see. I’m not really familiar with the variable font inner workings, but that all makes sense if they are just doing some simpler scaling of the line thicknesses. I haven’t heard back from slug yet about their plans for these fonts, but I will keep these in mind if we get a chance to test anything.
I guess you could look into manually tweaking them with something like font forge, but that could get tedious and I’m not sure about the licensing issues there depending on your usage case.
Great, thanks.
I have tried doing little adjustments in font forge to see if it might help, but unfortunately it seems like it would require completely recreating the shapes in order to get rid of these issues. (If I just moved overlapping shapes on E glyph to the right, it was much better, but the problem was still present - one pixel stood out in the area where two shapes met.) And that would be really tedious to do for all glyphs with this problem 
The solution for this is after all quite simple actually. Fonttools already have support for dealing with overlaps - just use --remove-overlaps flag on the instancer (for more info look at fonttools varLib.instancer -h). This merges overlapping shapes and produces font that can be rendered using Slug library without any problem. 
2 Likes
That’s great - thanks for sharing. The slugfont dev was really surprised to hear that Bahnschrift had those overlapping segments because apparently that goes against font design standards.
fyi, slug is hoping to add variable font support in the future, but they don’t have it on their timeline at this point. Their suggestion for the blending was to use a min or max blending mode in the material, but it sounds like you’ve got a better solution now.
1 Like