Comment 6 for bug 1001033

Hi, Sam,

It isn't even clear to me that the software is behaving incorrectly, depending on just what it is meant to accomplish.
Rendering software is geared towards displaying letters legibly on digital devices, not on making those images all of the same width. It's just saying, when its libraries render a given letter at a certain resolution using a certain algorithm, the image appears to be of a certain width (I guess).

Is the software renderer used by your libraries intended to preserve the width of characters? That is, if two letters have the same width, then the rendered versions of the two letters should also have the same width? Does the documentation say that?

You may be mixing up some concepts here. (It is also possible some software layer is misbehaving, but that is a second guess -- again, I don't know exactly what your libraries are meant to do.) The font is monospaced in that the width of all the nonzero-width glyphs are identical. The measure is not in device pixels, it is in device-independent EM; the fact that you refer to pixels indicates a miscomprehension. A measure in terms of pixels happens only after the glyph is rendered for a certain device.

When you say, "It works perfectly", what sort of tests are you doing? Are you running a test on the whole font, or a large part of it, looking for variations in the rendered width value, or are you just trying a few letters? What exactly is your test?

A full survey of rendered widths reported by your libraries, say of all the Latin characters, between various versions and various fonts, might be interesting.

The TTF and OTF versions of FreeMono are identical with regard to glyph bounds. The outlines of the OTF and TTF version are identical to within about 1 part in 1000. However, rendering software does in fact use rather different algorithms for TTF and OTF -- that accounts for the differences you are seeing.

Let's keep looking at it.