text() rendering at small text sizes

[arpruss]

At small values of the size parameter, text() rendering looks different from large values. The most obvious are slight shifts in the x-advances of the glyphs, but in testing I've also seen occasions where the stroke width changed. I am guessing this has something to do with freetype doing pixel-alignment or hinting, which really shouldn't be done in the case of vector output. Here is some code demonstrating this issue:

linear_extrude(height=0.5) text("Hello",size=1,$fn=50);
translate([0,0,-0.5]) linear_extrude(height=0.5) scale(0.1) text("Hello",size=10,$fn=50);

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[t-paul]

With which OpenSCAD version does it happen? In case it's the release version, could you please try with the latest dev snapshot - to see if the issue is related to #2123.

[arpruss]

I was using 2015.03-3 (Linux x64).
I just tried the July 1 2018 snapshot on Win64 (version 2018.06.01 (git 4455a12)) and the problem is still there.

[arpruss]

For a really hideous example of how the text shape changes, try text("This is a string",font="Times New Roman",size=0.5,$fn=30);

[t-paul]

Dev Snapshot (Debian/Testing) gives me that:

[arpruss]

That's better, but it is still different shapes than size=10. Note, for instance, the way the "r" is cut-off on the right.

Is there a Windows build of it somewhere?

[t-paul]

The change which I think is causing this specific issue (#2123) was done last year, so 2018.06.01 has the fix included. I'm not sure what can cause that difference.

[arpruss]

2018.06.01 on Windows still has the issue.

[MichaelAtOz]

I'm not sure what can cause that difference.

Perhaps the align to grid issue with small numbers? I can't find the issue no. I believe there is one...

Possible workaround:
scale(0.0100) text("This is a string",font="Times New Roman",size=50,$fn=30);

[MichaelAtOz]

Issue #23 was what i was thinking, but this problem is in preview too, so it's not CGAL...

[arpruss]

I'm thinking it's a freetype issue. I think freetype uses 1/64 pt coordinates and at small sizes this will have to cause problems. The workaround @MichaelAtOz suggests works fine, and something like that trick could get put into the rendering code.

[jordanbrown0]

I think this was fixed by PR #3263.
In 2021.01 (and in a recent build) the test case looks perfect to me.

Note: I suspect that the differences in the serifs may have been caused by the font being designed to render differently at different sizes. Typography perfectionists think that's desirable, though exactly how it would fit into a unitless environment is unclear. We now render at a constant 1000/64 points and scale from there, so the font does not have an opportunity to have an opinion on the subject. Whether a typographer is happy with that result can be left for a different bug report.