Font "features" that Medley doesn't seem to support?

[MattHeffron]

There are features in the BDF font format that it seems that Medley cannot support.
Without special case handling when converting the BDF font, the general case could cause errors in other glyphs.

For example:
A BDF font may specify a glyph width (advance distance or escapement) that is less than the width of the bitmap and it may specify that the left position of the glyph when displayed is to the left of the "current position". (I.e., it has a negative starting position!)
The glyph doesn't store any unnecessary whitespace in the bitmap, but rather specifies the left and bottom positions of the bitmap relative to the "current position".
When putting the BDF glyph bitmap into the CHARSETINFO bitmap I allocate the space for a glyph there including the left and bottom positions. When the left offset is negative, the space allocated is too small. And that offset is also used for the BITBLT, so the negative offset can cause the glyph to leak into the preceding glyph area of the CHARSETINFO bitmap.
I first noticed this in the Monaco font, as the glyph with this issue is the first one in the CHARSETINFO bitmap, so the negative offset trims off the left of the glyph. (For this glyph, there doesn't appear to be any indication from the Wikipedia info for U+25C6, XCCS 042,041 (0x2221) that the glyph should hang back to the left.)
I have since found similar cases in other fonts, but I haven't extensively checked all of the glyphs there to see what issues are there, if any.

Even without the negative left position issue, fonts encoded in the STRIKE format (in DISPLAYFONT files) cannot have a glyph (character) width that is different from the glyph bitmap (image) width of that glyph. There are glyphs that have zero advance distance but a non-zero bitmap width, typically accents and other diacritics.
Do we need a modified STRIKE file format that allows for different values for the bitmap and advance widths?

Right now, I think that READ-BDF handles the normal cases correctly.
It may be only a matter of time before something bites us.

[MattHeffron]

When putting the BDF glyph bitmap into the CHARSETINFO bitmap I allocate the space for a glyph there including the left and bottom positions. When the left offset is negative, the space allocated is too small. And that offset is also used for the BITBLT, so the negative offset can cause the glyph to leak into the preceding glyph area of the CHARSETINFO bitmap.
I first noticed this in the Monaco font, as the glyph with this issue is the first one in the CHARSETINFO bitmap, so the negative offset trims off the left of the glyph. (For this glyph, there doesn't appear to be any indication from the Wikipedia info for U+25C6, XCCS 042,041 (0x2221) that the glyph should hang back to the left.)

In PR #2108, I have modified functions in READ-BDF to account for this, basically by ignoring the negative offset.