kmatch98
commented
3 years ago 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:
- Get rid of
anchored_positionand always use x,y to set the position (baseline or the anchor point). - If
anchor_pointvalue is(None, None)then use the standard baseline values. If one of theanchor_pointvalues isNonethen just use baseline for that axis. If both are set, the use x,y likeanchored_positionis currently used.
Also, the Open Book project @joeycastillo may have some guidance since that project formats a lot of text.
jposada202020
PaintYourDragon
FoamyGuy
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.