fix left edge location for first character of the label.

[FoamyGuy]

This fixes an issue that resulted in multiple labels using monospace fonts with different leading characters to not align properly if the shift x values from the bounding box property in the font is different for different characters.

The change hardcodes the left value to start at 0 rather than the shift x value which was actually causing the shift to get "cut out" and no included in the final bitmap, as well as causing alignment to become misaligned with other labels placed at the same x position.

This problem was original reported on the forums here: https://forums.adafruit.com/viewtopic.php?p=954011

There are details and photos in that forum post.

Here are some photos illustrating the difference with this proposed change:

Currently released version:

This PR version:

If adopted this change would result in the visual x location of labels to change slightly depending on the shift x value for the leading character in whatever font is used. Projects that used larger fonts, or fonts with larger shift x values will see a more substantial change.

This change also has the side effect of putting in the left side padding inside the background box of the label. Previously the left edge of the first character was touching the left edge of the label background rectangle, with this version the shift from the font is respected and used as a left padding.

[tekktrik]

I think this is a good change, definitely good to be consistent. This only effects a single bound box, correct? The "previous" behavior could still be replicated using multiple boxes, right (in case it was desired for some reason)?

[FoamyGuy]

The change would effect any label whose font doesn't have a value of 0 for the offset of whatever the first character in the label text is.

In the screenshots shown each line is drawn by a separate label, so they each have their own bounding box. I have not done any testing around \ns in the text to see what happens with multi-line labels that have 1 single larger bounding box covering multiple rows of text, it may also need some tweaks, but is outside the scope of this one I think.

It would be possible to replicate the old behavior with the changed library, but it could be a bit tedious if the aim is to actually replicate it 100% pixel perfect. In order to do so, one would need to check the offset value in the BDF font they're using for the first character in the label and then once that value is known they could use it as an offset with either the x property or the anchored_position to "manually" move the label back to where it would have gotten rendered with the currently released version of the library.

If someone where just interested in getting close without necessarily being pixel perfect for all possible different leading characters they could just shift the x position by a little bit and eye ball it until it's lined up how they want.

[tekktrik]

That all makes sense to me, thanks for explaining!