4 ms·

That happens all the time, and unfortunately it isn't regarded as a bug. There's no specification or agreement that requires font renderers to match up. Font r

That happens all the time, and unfortunately it isn't regarded as a bug. There's no specification or agreement that requires font renderers to match up. Font rendering used to be all about bitmaps, then as TrueType matured it was all about aggressively hinting (and auto-hinting) to fit the pixel grid, and we haven't fully gotten away from that. Of all the main OSes, I think OS X and iOS do the least hinting, but I don't know if they do no hinting; and many people dislike the blurry text on OS X. (I don't see any complaints about blurriness on iOS, though, where you always have really high screen resolution now.) It would be technically feasible for all font renderers to product identical output (or at least to provide such an option) but nobody seems to care enough to push for it.

jancsika 9y ago
tl;dr - without a spec nothing will ever change Thanks for the reply-- it's what I gathered from doing a little digging into extant font stacks but wasn't sure if I had skipped over an obscure specification somewhere. So here's the deal-- maybe a year ago, I tested Windows, OSX, and old-school GNU (via Ubuntu 14.04) and got font metric results within a half a pixel of each other for the test I outlined above. New-school GNU, however, was about 7 pixels wider. Again, this was for the same version of a mono-spaced font, loaded from the same font file shipped with my test program. I also got reports from users of other GNU/Linux distros about the discrepancy-- these were distros that also used the newer GNU font stack. Since that time I've seen reports about this discrepancy affecting other software. One final data point-- I also noticed that the newer GNU font stack seems to quantize pixel sizes that aren't whole numbers. For example, assume size "11.3px" generates a particular output. Then "11.33px" would generate the same output, and only when you get to, say, "11.37px" do you get a different output. Not sure if those numbers accurately reflect the quanta, but it was something like that. And again, this only happened with the newer GNU font stack and not with any of the other platforms. Now maybe there's some super beautifully readable output that comes from that algo, but OSX's gold standard of readability doesn't seem to do that... I didn't take the time to narrow this down any further than that, nor drill down to figure out what part of the font stack causes the discrepancy, or when it happened. Without a spec to which I can refer I'm 99% sure I'll get a response from a font-stack dev that this is the way fonts work and it's my app that is broken. And confirming that likely response isn't worth the effort it would take to precisely describe this bug on an issue list. As an aside-- my solution to this in my program is to do a sanity check at startup, do some sizing adjustments to make sure fonts fit appropriately into their boxes if necessary, and print out a message for users when the oddball GNU situation is detected. I have to print the message because the diagrams printed in the program are supposed to be pixel-exact, and oddball GNU users will notice extra space at the end of the boxes. (Which is a feature, because if those boxes were tight fitting oddball-GNU-font-stack users would potentially move them closer together and generate overlaps for sane-font-stack users...) Edit: clarifications
int_19h 9y ago
I think all mainstream font renderers do have the ability to produce identical output in terms of metrics, at least. E.g. on Windows (DirectWrite), you have "ideal layout" as an alternative to "pixel snap", and that should do the same thing as OS X - not pixel perfect, but dimension-wise. The problem is that the output sucks on low-res displays, like most PC screens. Mac users are kinda used to it (and Apple uses bigger fonts to compensate somewhat), but for Windows users, it's a major eyesore when someone tries to use ideal rendering. For a long time, WPF did that, and it was constantly reported as a bug - indeed, I filed one of those bugs myself (https://connect.microsoft.com/VisualStudio/feedback/details/380919/wpf-text-renderer-produces-badly-blurred-text-on-small-font-sizes https://connect.microsoft.com/VisualStudio/feedback/details/...). They actually had to fix WPF to allow for pixel-snapping. Ultimately, this problem will only go away for good once everything is high-DPI, including desktops and laptops. Ironically, the reason why WPF only supported ideal layout initially, is because the team thought that this would be the case by the time they released the final version (the design process started somewhere in 2001, IIRC). It's obvious now that it's not going to the case anytime soon - indeed, many cheaper laptops still use 1366x768. Hopefully we'll get there eventually.

jancsika 9y ago

tl;dr - without a spec nothing will ever change Thanks for the reply-- it's what I gathered from doing a little digging into extant font stacks but wasn't sure if I had skipped over an obscure specification somewhere. So here's the deal-- maybe a year ago, I tested Windows, OSX, and old-school GNU (via Ubuntu 14.04) and got font metric results within a half a pixel of each other for the test I outlined above. New-school GNU, however, was about 7 pixels wider. Again, this was for the same version of a mono-spaced font, loaded from the same font file shipped with my test program. I also got reports from users of other GNU/Linux distros about the discrepancy-- these were distros that also used the newer GNU font stack. Since that time I've seen reports about this discrepancy affecting other software. One final data point-- I also noticed that the newer GNU font stack seems to quantize pixel sizes that aren't whole numbers. For example, assume size "11.3px" generates a particular output. Then "11.33px" would generate the same output, and only when you get to, say, "11.37px" do you get a different output. Not sure if those numbers accurately reflect the quanta, but it was something like that. And again, this only happened with the newer GNU font stack and not with any of the other platforms. Now maybe there's some super beautifully readable output that comes from that algo, but OSX's gold standard of readability doesn't seem to do that... I didn't take the time to narrow this down any further than that, nor drill down to figure out what part of the font stack causes the discrepancy, or when it happened. Without a spec to which I can refer I'm 99% sure I'll get a response from a font-stack dev that this is the way fonts work and it's my app that is broken. And confirming that likely response isn't worth the effort it would take to precisely describe this bug on an issue list. As an aside-- my solution to this in my program is to do a sanity check at startup, do some sizing adjustments to make sure fonts fit appropriately into their boxes if necessary, and print out a message for users when the oddball GNU situation is detected. I have to print the message because the diagrams printed in the program are supposed to be pixel-exact, and oddball GNU users will notice extra space at the end of the boxes. (Which is a feature, because if those boxes were tight fitting oddball-GNU-font-stack users would potentially move them closer together and generate overlaps for sane-font-stack users...) Edit: clarifications

int_19h 9y ago

I think all mainstream font renderers do have the ability to produce identical output in terms of metrics, at least. E.g. on Windows (DirectWrite), you have "ideal layout" as an alternative to "pixel snap", and that should do the same thing as OS X - not pixel perfect, but dimension-wise. The problem is that the output sucks on low-res displays, like most PC screens. Mac users are kinda used to it (and Apple uses bigger fonts to compensate somewhat), but for Windows users, it's a major eyesore when someone tries to use ideal rendering. For a long time, WPF did that, and it was constantly reported as a bug - indeed, I filed one of those bugs myself (https://connect.microsoft.com/VisualStudio/feedback/details/380919/wpf-text-renderer-produces-badly-blurred-text-on-small-font-sizes https://connect.microsoft.com/VisualStudio/feedback/details/...). They actually had to fix WPF to allow for pixel-snapping. Ultimately, this problem will only go away for good once everything is high-DPI, including desktops and laptops. Ironically, the reason why WPF only supported ideal layout initially, is because the team thought that this would be the case by the time they released the final version (the design process started somewhere in 2001, IIRC). It's obvious now that it's not going to the case anytime soon - indeed, many cheaper laptops still use 1366x768. Hopefully we'll get there eventually.