Feature request: anchor relative to baseline

[PaintYourDragon]

Anchoring text along a baseline (rather than or in addition to bounding rect) would be very Very very helpful. Maybe this could be indicated without breaking existing code by expressing a Label’s anchor_point as a single value or single-element tuple rather than a 2-element tuple (so it still can do left/center/right alignment, while y coord is then just the baseline, period).

As it currently stands, text bounds can vary with descenders, punctuation, etc. This makes it impossible to guarantee a consistent baseline when there are multiple Label elements that are trying to align as a well-formatted and legible unit. Also, for text that changes value, the current use of bounding rect alignment can cause Label elements to move up or down as the value changes, rather than maintaining their original baseline.

Attached image shows example of desired baseline behavior, which was approximated with some hacks. For the first two items on each line, baseline alignment is forced by using bottom alignment and applying upper() to the location strings (though none of these locations have descenders…but if any of them did, say a “j” or “g,” and were not upper() filtered, those descenders would alter the text bounds, placing the Label bottom-aligned by bounds, but with a baseline that jumps up a few pixels and Looks Bad). The third element on each line here is also bottom aligned…but with +2 added to each anchored position’s Y value…it works here because we know that a comma in this font and this size descends 2 pixels below the baseline, but that’s just a quick workaround and not going to be true for all fonts and sizes. Baseline anchoring would take care of all of that.

[kmatch98]

Fully agreed that the baseline is a major consternation but was based on the (historical?) version of label. It uses the height of an ‘M’ to define the baseline using this code (line 199):

y_offset = int((self._font.get_glyph(ord("M")).height) / 2)

The baseline position is actually defined in the BDF font specification but is currently ignored in the current code.

On a related note, the ascender/descender height should be included in the BDF file but is not currently utilized. Instead, a few characters are checked to test the ascender/descender height. These dimensions is used for the background sizing along with tight_padding.

Any changes to the baseline should be propagated to label and bitmap_label for consistency.

One complexity with baseline positioning is that two ways are currently available to set the position, either (x,y) or by anchor_position.

If we can think of a way to consolidate this perhaps this would be more well-defined (but maybe more confusing?).

One proposal:

1. Get rid of anchored_position and always use x,y to set the position (baseline or the anchor point).
2. If anchor_point value is (None, None) then use the standard baseline values. If one of the anchor_point values is None then just use baseline for that axis. If both are set, the use x,y like anchored_position is currently used.

Also, the Open Book project @joeycastillo may have some guidance since that project formats a lot of text.

[kmatch98]

New features for font ascent and descent were added in this recent PR: #110

[jposada202020]

@PaintYourDragon have you test the new feature that we include in the library that allows different fonts to align to the baseline as you describe in this issue. Let us know if you have more ideas regarding this. Thanks.

[PaintYourDragon]

I’ve not, yet. Been on other projects. Looking forward to using it on future stuff.

[FoamyGuy]

#115 and #134 have added this feature for x,y placement, and anchored_point.

It's much easier now to align different sized fonts as shown in the images above using thew new features. Closing this issue for now.