text: Use font metrics to determine line heights#31291
text: Use font metrics to determine line heights#31291QuLogic merged 3 commits intomatplotlib:text-overhaulfrom
Conversation
Discussed on the call today and decided not to add line gap for a single-line text. This should be closer to what we used to do, and will minimize the number of changes that occur due to this. |
0264fde to
05c7199
Compare
|
I've now pushed fixes to the |
|
There is one (set of) regression for which I have not pushed the image updates (and so why tests are failing). All the vector multi-font tests now have a reduced line height: This is because the test uses Computer Modern as its primary font, with fallback to DejaVu Sans for the other characters (which is on purpose to test fallbacks). While the ascent/descent metrics for Computer Modern are larger than the "lp" measurement, that font does not have a nonzero line gap. Additionally, since we don't do the fully-correct thing of looking at all font metrics for a used line, while we do see the ascent/descent of DejaVu Sans, we don't know that DejaVu Sans has a larger line gap. Since we aren't applying any other line spacing, all the lines now look a bit cramped. This last thing cannot be fixed until we move to processing all text in the backend where we can inspect all glyphs at a time. I see three options for handling these:
Separately, I did mention that I would run the constrained/tight layout tests without placeholders so that we could compare the results. I did that, and posted the results to a gist here: https://gist.github.com/QuLogic/254ee85ecaa778dd44635924d706acea |
|
Consensus on call is to ignore for now and let it be cramped for now. If we fix this later a few tests would be acceptable. |
This is minimally different from the `x` measurement, but technically more correct. We still do the measurement for fonts we don't ship, but that may change with Unicode Math fonts in the future.
This follows from CSS' default for line height. At the moment, the behaviour has not been changed, and still just falls back to 1.2 for 'normal'.
We follow the process from [the CSS Inline Layout module](https://www.w3.org/TR/css-inline-3/), specifically: 1. The default ascent and descent come from the `OS/2` font table, or failing that, the `hhea` table, with final fallback to the measurement we used to do. 2. If `linespacing` (cf line height in CSS) is normal, then we do as before and size each line based on the maximum ascent/descent of its contents. Additionally, apply the line gap from the font metrics as half-leading around each line. 3. If `linespacing` is a float, then scale it by font size of the first available font, and keep it fixed for each line. However, if we are drawing a single line, then we do not add the line gap around the line, to keep them a similar height as before.
|
OK, pushed the images to the |
|
So it looks like some of these tests are failing on platform/arch-specific ways. What I'll do for now is merge this one since it's holding up everything, and put in a smaller PR upping the tolerances on the ones that are broken. |
PR summary
As outlined in #31220, we follow the process from the CSS Inline Layout module, specifically:
OS/2font table, or failing that, thehheatable, with final fallback to the measurement we used to do.linespacing(cf line height in CSS) is normal, then we do as before and size each line based on the maximum ascent/descent of its contents. Additionally, apply the line gap from the font metrics as half-leading around each line.linespacingis a float, then scale it by font size of the first available font, and keep it fixed for each line.Additionally, the first commit changes mathtext to use the x-height from the default fonts. We can read that from font metrics, but I thought I'd leave the general case to something like #31048.
Note, this is based on the
text-overhaul-figuresbranch, so more test images than necessary are changed here. Please look at the last commit for the test images. Most test image changes are minor, maybe half a pixel or so with the text. The main ones you probably want to look at are those with multiple lines, such as 'basictext_wrap.png`.One thing to decide is whether to apply the line gap for a single line. Previously, I don't believe we ended up doing that, because the line spacing was added before the second and subsequent lines. This PR currently always adds it, which means the text bounding box is taller in all cases. This causes such changes as the fancy bbox patches in
boxarrow_test_image.pngto all be larger, or e.g., every multi-artist legend to be larger. To minimize such changes, we can decide to drop the line gap for single-line text entries, if we want?AI Disclosure
None
PR checklist