How did you install Matplotlib and which version of freetype are you using?
Does it work if you make the font size smaller? Do you have anything about fonts in your rcparams?
My knee-jerk guess is that something is wrong with the font-metrics and we are copy too-small of a buffer. No good guess why this is happening on windows and not linux.
FWIW, I get a similar error when I use IPA glyphs in axis labels (ʃ, ʒ, ð etc), but it only happens in interactive plotting (Qt5Agg) and when generating PNGs, but not when saving to PDF, EPS, or SVG.
(mpl 2.0.2, python 3.6.1, linux)
I can repro too (default rcparams, 2.1.2 or master, archlinux). #9763 fixes the issue, so it's not clearly (not "clearly not" :-)) a font metrics thing...
diff --git i/lib/matplotlib/backends/backend_agg.py w/lib/matplotlib/backends/backend_agg.py
index c5545ae80..30689f403 100644
--- i/lib/matplotlib/backends/backend_agg.py+++ w/lib/matplotlib/backends/backend_agg.py@@ -178,12 +178,9 @@ class RendererAgg(RendererBase):
if font is None:
return None
- if len(s) == 1 and ord(s) > 127:- font.load_char(ord(s), flags=flags)- else:- # We pass '0' for angle here, since it will be rotated (in raster- # space) in the following call to draw_text_image).- font.set_text(s, 0, flags=flags)+ # We pass '0' for angle here, since it will be rotated (in raster+ # space) in the following call to draw_text_image).+ font.set_text(s, 0, flags=flags)
font.draw_glyphs_to_bitmap(antialiased=rcParams['text.antialiased'])
d = font.get_descent() / 64.0
# The descent needs to be adjusted for the angle.
fixes the issue. Indeed, the problem is that load_char does not resize the font's internal buffer, which gets sizes by the smaller "heart" character (which is measured while we prepare for aligning the labels -- we measure all labels before rendering all of them).
The special handling of single-non-ASCII characters was added a long time ago in 29371f9; tbh it's not clear to me why it's necessary (for example it isn't used for longer non-ascii strings...).
Now it would be nice to have a way to test this without a baseline image...
Activity
tacaswell commented on May 14, 2017
http://matplotlib.org/users/dflt_style_changes.html#fonts renders correctly (which was rendered on the computer I am using right now) as does http://matplotlib.org/devdocs/users/dflt_style_changes.html#fonts which renders on travis (both linux).
How did you install Matplotlib and which version of freetype are you using?
Does it work if you make the font size smaller? Do you have anything about fonts in your rcparams?
My knee-jerk guess is that something is wrong with the font-metrics and we are copy too-small of a buffer. No good guess why this is happening on windows and not linux.
a113n commented on May 15, 2017
Thanks for looking into the issue!
I think if you change one of the symbols in http://matplotlib.org/users/dflt_style_changes.html#fonts to smaller symbols such as '❤️' or any alphanumeric characters, the larger ones would be clipped as well.
This behavior can be observed on both Ubuntu 16.04 and Windows 10. My rcparams are not modified.
drammock commented on Jan 24, 2018
FWIW, I get a similar error when I use IPA glyphs in axis labels (ʃ, ʒ, ð etc), but it only happens in interactive plotting (Qt5Agg) and when generating PNGs, but not when saving to PDF, EPS, or SVG.
(mpl 2.0.2, python 3.6.1, linux)
anntzer commented on Jan 25, 2018
I can repro too (default rcparams, 2.1.2 or master, archlinux).
#9763 fixes the issue, so it's not clearly (not "clearly not" :-)) a font metrics thing...
vincentzlt commented on May 7, 2019
still got similar problem with chinese characters in 3.0.3
vincentzlt commented on Jul 6, 2019
still got similar problem with chinese characters in 3.1.1
anntzer commented on Jul 6, 2019
#8609 (comment) was the important hint: looks like
fixes the issue. Indeed, the problem is that load_char does not resize the font's internal buffer, which gets sizes by the smaller "heart" character (which is measured while we prepare for aligning the labels -- we measure all labels before rendering all of them).
The special handling of single-non-ASCII characters was added a long time ago in 29371f9; tbh it's not clear to me why it's necessary (for example it isn't used for longer non-ascii strings...).
Now it would be nice to have a way to test this without a baseline image...