So I’ve just uploaded my free font family to Open Font Library and noticed two rendering problems on that website. I’m wondering whether that’s a problem of their webdesign, or whether there’s a problem in the hinting or vertical definition of my fonts.
The first problem is that the family preview in my user home page looks crappily rendered. The stroke weights are very inconsistent, especially among the caps, and the arches of the /m are uneven in width and strangely top-heavy.
The Open Type Library staff told me that preview was not a webfont, but rather a bitmap image rendered with a piece of code from FontForge. Given that, I find it quite likely that the code is to blame. However, since I’m using the autohinter and lack any kind of experience with hinting, I can’t exclude a problem with my font either. How can I check this?
Secondly, some of the fonts are clipped at the bottom in the OpenType preview window. This is a webfont now, so at least the rendering works well otherwise (phew!).
To tell you the truth, I don’t think it is so bad. Some irregularities are to be expected with thin stems in grayscale-only rendering, and considering that, it still comes out nicely. The Helvetica next to it renders much worse IMO.
To tell you the truth, I don’t think it is so bad. Some irregularities
are to be expected with thin stems in grayscale-only rendering, and
considering that, it still comes out nicely. The Helvetica next to it
renders much worse IMO.
I find the sudden blobs of weight in the caps and in /3 rather jarring. I don’t think the resolution can be blamed; after all, the webfont samples on the project’s page are about the same size and render much better (cf. the Cormorant Infant Regular sample above). I’m not so worried about this effect, though; I’m pretty sure the FontForge rendering code is to blame. I remember how extremely much smoother everything looked when I switched to Glyphs!
Georg: The winDescent trick seems to have worked. Wheee! Although the line spacing seems a bit wide now. Did you mean to suggest 860 as the winAscent? That would be the difference between –240 and the ascender height.
So if I want my font to have tighter leading and look larger at a given point size, I have to reduce the units per UPM? It’s currently 1000, but the span between my descenders and ascenders is only 855 (I changed the proportions around a bit in the early stages, so it got stuck at a weird number). Can I lower that to something like 900, or will a non-standard value cause problems?
I much prefer the size and leading of Alegreya at the same point size:
OK, I did try setting the UPM to 900 and rescaling to 1000, and the master glyphs turned out quite well (at first sight). I might go with that.
It’ll screw up the designs of people who’ve already downloaded and used my fonts, though. Do you think it might be better to leave the scaling as it is…? If not, I suppose I should change it now rather than later.
I’m not sure I understand that. A default Glyphs font has Descender –200, Ascender 800, which add up to 1000 = UPM.
As for the algorithm: You already have a functional rounding algorithm implemented in alt-nudge. How about applying that to the shorter of the two handles after a transform? (That’s how I fix broken curve points: Alt-nudge the shorter handle up–down or left–right once.)
I’m having trouble wrapping my mind around all these different keywords. I have made a rescaled version of the font that does look similar to Alegreya in terms of filling the page (see second Kerensky text above). Its in-Glyphs parameters are now –250, +750, UPM 1000, with winDescent = –285 and winAscent = 1020. However, its Vietnamese accents spill above the ascender height: