Created attachment 13038 [details] Demonstration. The Nimbus Sans (Narrow) fonts (OpenType/CFF flavor) don't have their numbers aligned to a blue zone, resulting in misaligned glyph tops at different sizes with Adobe's CFF renderer in FreeType (the default). See attached image.
And: The number-glyph-top-alignment is inconsistent between the regular and the bold version. In the regular, e.g. 1 and 2 are top-aligned at the same y-coordinate while there's a larger gap in the bold face. Overshoot is normal, but it should be consistent between weights.
I believe this is fixed with the latest release from URW: http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commitdiff;h=273e76aa7
Nope, numbers are still misaligned. Test the fonts on http://www.impallari.com/testing/, you can use the "hinting" section.
That extremely odd because looking at the outlines in fontforge, the top and bottom extents of the glyphs in the previous release clearly did not align with the blue zones, but the current ones do or, at least, appear to.
The points must be exactly within a blue zone, so if a blue zone goes from 500 to 510, the points must be at y=500 to y=510 plusminus BlueFuzz (usually 0 or 1). Being even 1 font unit off gets you misalignment.
I just had a look at the fonts in the git repo. There is no blue zone for the numbers to align to?!
Which font in which repo are you looking at? I'm just checked NimbusSansNarrow-Regular, and it has: /BlueValues [-19.0 0.0 523.0 538.0 718.0 737.0 688.0 703.0] The top extents (in font coordinate space) for the basic number glyphs are: 0 - 703 1 - 703 2 - 703 3 - 703 4 - 703 5 - 688 6 - 703 7 - 688 8 - 703 9 - 703
Ah, the narrow font has proper blue zones, but the regular variant doesn't. The vendor needs to check *all* fonts!
(In reply to madigens from comment #8) > Ah, the narrow font has proper blue zones, but the regular variant doesn't. > The vendor needs to check *all* fonts! Confirmed: this needs referring to URW++.
Fixed in the latest update from URW++ (2017/07/27)
Sigh, nope. Nimbus Sans Regular: '1' and '4' do not align with the other numbers at several pixel sizes (9, 13, ...) as demonstrated in the hinting tab on http://www.impallari.com/testing/. The tops should probably be lowered to match the other flat tops. And there are alignment issues in the other faces and in Nimbus Roman, too. I'm primarily looking at the .otf files here, which are fed to Adobe's CFF driver inside FreeType by default, which is pedantic about hinting. The .ttf files are fed to the autohinter on many systems, which is a bit less fuzzy, but still doesn't catch the '6' and '9' in Nimbus Roman.
Nimbus Sans Regular contains a blue zone from 709 to 724, and the tops of the number glyphs all fall within that zone (1, 2, 3, 4, 6, 8 and 9 have tops at 723, 5 at 710, 7 at 709). As far as I can tell, that all seems correct. FWIW, the Type 1 and CFF parsers in Freetype aren't *that* picky since they apply the hints before the outline has been scaled - which is far from ideal for hinting!
The offending glyphs lack HStems at the top. Adobe's CFF engine will not clamp a point to a blue zone without some hint attached to it. This should be a matter of re-running the autohinter on all files.
(In reply to madigens from comment #13) > The offending glyphs lack HStems at the top. Adobe's CFF engine will not > clamp a point to a blue zone without some hint attached to it. Confirmed, that seems to be true. > This should > be a matter of re-running the autohinter on all files. I'm not sure what URW use to generate their fonts - it's possible this indicates a limitation in the tool. We'll pass this back to them, and hopefully, get it sorted.
Created attachment 15290 [details] Nimbus Sans Narrow update Updated Nimbus Sans Narrow from URW.
Created attachment 15310 [details] Nimbus Sans Narrow update URW update for the narrow variant. It would be useful if the OP reviewed these, but we'll look at them eventually.