Created attachment 33207 [details] Screenshot of 1 and 4 misrendering At 12 pt, the 1 and 4 digits (yes, U+0031 and U+0034) are not rendering with the same height as the other digits. It's a shame, because I've been using the DejaVu family at 11pt across the board; but with a new system I had a slightly better resolution, so was looking to bump my fonts up a notch, but this is really disorienting. In numbers like dates (notably 2010 and 1984) it's really jarring. Screenshot of this being demonstrated by `gnome-specimen` attached. It does not manifest at 11pt nor at 14pt. It does at 12pt and 13pt. This is on a GNOME system (so yes, `gnome-appearance-properties` Font -> Details is at 96 dpi like it's supposed to be) as provided by Canonical's Ubuntu. The hinting is again the default, "slight". If I disable hinting (for that font alone via fontconfig, or for the entire desktop) then the problem indeed goes away. But of course down at these sizes not using hinting at all is a bit suboptimal. Using "medium" hinting also makes the problem go away, but then the font looks stick figures. I don't think that's what we're supposed to be going for. I did some debugging using `pango-view` and FC_DEBUG and saw the same results. It's claims to be 16 pixels high, if that matters. Presumably the tip of the top of the '1' and the '4' are getting hinted or anti-aliased (sorry to not know the right term here) up a pixel. I'd love to help; I got as far as firing up fontforge, and turning the grid on for 12 pt / 96 dpi. I think I can see it drawing an extra pixel in height for 1 vs 2, but I'm not even remotely close to knowing enough about fonts to know what to do from there. Anyway, I'm back at 11pt, and squinting. Any help would be appreciated. AfC
This is a bug in the Freetype autohinter (which discards the hinting in the font). Unfortunately we don't have any control over how Freetype renders these glyphs exactly. If you use the Freetype bytecode interpreter (which uses the font hinting) this will go away. Moving to Freetype product.
(In reply to comment #1) > If you use the Freetype bytecode interpreter (which uses the > font hinting) this will go away. Um, as in the bytecode interpreter that is switched on [or at least not commented out] by distros like Ubuntu? If so, that's what I'm running at the moment. My understanding from some long chats in #gnome-hackers about this is that the autohinter is not being used on Ubuntu at "hintslight" and that the bytecode interpreter is shipped by them. Sorry I don't have a Fedora box to compare against. Attempting forcing the autohinter off with .fonts.conf as follows: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <test name="family"> <string>DejaVu Serif</string> </test> <edit mode="assign" name="hinting"> <bool>true</bool> </edit> <edit mode="assign" name="hintstyle"> <const>hintslight</const> </edit> <edit mode="assign" name="autohint"> <bool>false</bool> </edit> </match> </fontconfig> do not have any effect (but turning hinting off entirely this way does work, so I believe I have the syntax right). So presumably I can report that the problem is present in the face of the bytecode interpeter? Or are you talking about something else, or is there something more drastic I have to do to turn the freetype bytecode interpreter on? Thanks for looking in on this, AfC
Ubuntu has the bytecode interpreter (BCI) disabled AFAIK, just like Fedora. Debian enables it. It may vary over time. I think the patent why it was disabled is no longer valid, so I guess distro's will switch it on again. Also, if the BCI is disabled by the distro, it's not compiled in, so you can't enable it with a fonts.conf file. So then you have to find a version of the freetype package that had it compiled in. Also, but I'm not sure on this: it may be that "hintslight" as the hintstyle still won't turn on the bytecode interpreter if it's available. With the BCI it's not possible to hint less or more. There's just one way of hinting (*), and it may be that you have to tell it to use "hintfull" or "hintmedium" to get it. (*) to be complete, but it doesn't really matter here: it is possible, but then we're talking about different hinting horizontally and vertically.
(In reply to comment #3) > Ubuntu has the bytecode interpreter (BCI) disabled AFAIK, just like Fedora. > Debian enables it. It may vary over time. I think the patent why it was > disabled is no longer valid, so I guess distro's will switch it on again. The Ubuntu packages, at least as of Lucid, have the BCI enabled, and I'm fairly sure it's been enabled for a number of releases.
Well, there's an easy test to see whether the BCI is enabled or not. Copy these glyphs in an editor: "" (U+F000 and U+F001 if just copying doesn't work - you can also check them in for example gucharmap in the private use area block) and select DejaVu Sans to render them. If you see something "88"-like, you're using the autohinter to render the font (it may still be that the BCI was compiled in, but you're just not using it). If it shows a lower number that changes if you change the font size, the BCI is enabled and working (although if it's enabled, there's nothing that says Serif will render with BCI as well, if you have an awkward fonts.conf)
Hey neat. So, yes I get 88,88 ... until I change the hinting to "full", at which point I get a number [what I assume to be the pixel height]. Except that at full hinting the font looks awful (all very thin stick figures) which is certainly not your fault, but it's interesting that in this case it appears that at the default for LCDs, "slight", the bytecode interpreter is not running. So I guess I have to defer to your assesment that the freetype autohinter is to blame. How can we help from here? Since the GNOME default is "slight" (and apparently, autohinter) it'd be nice to find a way to resolve this so that 16 pixel high 1s and 4s behave. AfC
(In reply to comment #6) > Hey neat. > > So, yes I get 88,88 ... until I change the hinting to "full", at which point I > get a number [what I assume to be the pixel height]. Indeed, it's pixel height (and width, if you turn on subpixel hinting with BCI, width will be three times the height) > Except that at full hinting the font looks awful (all very thin stick figures) It's a matter of taste really, and probably even more a matter of what you're used to. It can take weeks before you're used to a new setting. If you've only used slight hinting so far, BCI hinted fonts look way too sharp. If you've seen bitmapped fonts for years, the same BCI hinted fonts look too fuzzy. And once you get used to a new setting, the old setting will look bad even if it used to be the only setting you liked at the time. > How can we help from here? Since the GNOME default is "slight" (and apparently, > autohinter) it'd be nice to find a way to resolve this so that 16 pixel high 1s > and 4s behave. The way to fix this is is to improve the algorithms of the freetype autohinter. Not exactly easy as it has no information from the font whether two heights should be the same or not, and the algorithms have to work for all fonts. This bug is now assigned to the freetype product so they should be aware of it now. Greetings Ben
I think the autohinter is getting confused by the inconsistent height of the number glyphs in Serif. Note how it doesn't happen in Sans: all flat tops of numbers line up at 1493 font units on the y-axis, round tops at 1520 font units. Compare with Serif, where everything except 5 and 7 lines up at 1520. So this arguably a bug in Serif. Commercial-quality fonts don't have this inconsistency.
Created attachment 129559 [details] Shifted flat tops of 1 and 4 down to 1493 font units. Renders correctly now with the autohinter.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.