Closed nickmass closed 3 years ago
Most font rasterizers, like Fontdue, raster a glyph in scanline order. It knows when it enters or leaves a contour by the direction of the line it encounters. Specifically, this is the winding order. TTF fonts use the glyf table while OTF fonts generally use the CFF/CFF2 tables. The glyf table specifies that contours are defined clockwise, while CFF/CFF2 is counter-clockwise.
TTF glypf table example:
Fontdue accept malformed fonts to some degree. It will re-compute glyph metrics and winding order per glyph (that commit cb2e9b2), which fixes a number of issues with some moderately wrong fonts. If a font has a clockwise winding order for some glyphs, but a counter clockwise order for other, Fontdue will render them all correct.
The issue here is that this spec is not enforced, and fonts that don't follow the spec produce undefined behavior. Your font, https://nickmass.com/files/evesansneue-regular.otf, is out of spec. It's a malformed font. Your 'i' and 'j' use two different winding orders for each of its contours. I colored the subtractive and additive sections of the glyph in red and green.
I'm open to fixing this, I'd love to support more out of spec fonts, but this issue is definitely on the font.
Thank you for the detailed response, I was able to open the font in an editor and quickly fix the directions of those contours and now fontdue renders everything perfectly.
No worries, I'll work on thinking of a way to handle this new edge case automatically so you won't need to hand fix the font in the future.
I fixed it, I'll push the change eventually
When the following font is rasterized with fontdue it is missing the dots above the lowercase i and j.
https://nickmass.com/files/evesansneue-regular.otf
I modified the raster-print example code to render the same font with rusttype/freetype-rs for comparison:
Changing the rasterizing scale has no effect on the problem, and slightly interestingly the exclamation point renders with its dot just fine.
I checked the font against some previous versions of fontdue and noticed that prior to commit cb2e9b237 the problem is actually reversed and it only renders the dot while the stem of the characters is absent.
I added some debugging to the fontdue Geometry struct to see if the glyphs were being loaded correctly and as far as I could tell that was fine.