You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: path effects in text() change text properties #2889
After encountering strange behavior across matplotlib versions 1.3/1.4 in our image tests in @obspy and a couple of hours of debugging and git bisecting roughly a dozen steps through matplotlib git repo I have pinpointed a problem with path effects..
When using path effects in plt.text() and using plt.savefig("...png") the text properties get changed in a strange way. What I experienced is that font size gets decreased by roughly 25% when I used a path effect on text.
The commit that introduces the bug is 3d31865. The parent commit d5f9876 shows the expected behavior.
The following shows a minimal test case to reproduce:
importmatplotlibmatplotlib.use("TKAGG")
importmatplotlib.pyplotaspltimportmatplotlib.patheffectsasPathEffectsplt.text(0, 0, "BAD", size=100,
#path_effects=[PathEffects.withStroke(linewidth=3,# foreground="red")])# EDIT: even `Normal()` exposes the bugpath_effects=[PathEffects.Normal()])
plt.text(0, 0, " OK", size=100)
plt.savefig("/tmp/patheffects_bug.png")
plt.show()
Note that the plot that shows after savefig has the text with correct size.
Yep, just looking now. I'm very surprised about this one - the fact that it shows correctly is weird and I can't see any obvious bugs in my code. Right now I'm suspicious that there is an underlying bug in the renderer somewhere and that my change has exposed us to that - if that is the case, this could be particularly difficult to track down. I'll update on any progress.
I think that might be the clue to the underlying problem - savefig, for some reason, has a different dpi to show. I'm wildly speculating that the smaller text is the correct size given the savefig's dpi, and the larger text is a fallout from the fact that its height is computed before the savefig call - essentially I think the bug here is that the OK text is too big.
Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser. One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
With the resulting PNG from your code, OK has a height of 100px, and bad has 72px (plus a little extra for the actual path effect).
@mdboom / @leejjoon - do either of you know what behaviour we actually want?
The font size given to the Text object is specified in points. The PDF, PS and SVG backends all have a "hardcoded" dpi of 72 -- the native "unit" is always 72 units per inch, and the "dpi" passed to savefig is only intended to affect how images are resampled. Maybe that helps -- if I have time this afternoon, I may look a little deeper myself.
Although it's been a while since I reported this and I can't exactly remember where this first popped up. But I put some effort in a solid bug report in the first place and the above code snippet seems fixed by this:
Activity
tacaswell commentedon Mar 10, 2014
@pelson Can you take a look at this one too?
megies commentedon Mar 10, 2014
Here's my build output.. just in case. https://gist.github.com/megies/9468079
pelson commentedon Mar 20, 2014
Yep, just looking now. I'm very surprised about this one - the fact that it shows correctly is weird and I can't see any obvious bugs in my code. Right now I'm suspicious that there is an underlying bug in the renderer somewhere and that my change has exposed us to that - if that is the case, this could be particularly difficult to track down. I'll update on any progress.
megies commentedon Mar 20, 2014
Btw, it doesn't take
withStroke(...), evenpath_effects=[PathEffects.Normal()]produces the bug.pelson commentedon Mar 20, 2014
Thanks, that is worth knowing.
pelson commentedon Mar 20, 2014
P.S. Workaround:
plt.savefig("/tmp/patheffects_bug.png", dpi=plt.gcf().dpi)pelson commentedon Mar 20, 2014
I think that might be the clue to the underlying problem - savefig, for some reason, has a different dpi to show. I'm wildly speculating that the smaller text is the correct size given the savefig's dpi, and the larger text is a fallout from the fact that its height is computed before the savefig call - essentially I think the bug here is that the OK text is too big.
I'm speculating as I'm not sure what units "size" is in. The two possible definitions (taken from http://kyleschaeffer.com/development/css-font-size-em-vs-px-vs-pt-vs/):
With the resulting PNG from your code, OK has a height of 100px, and bad has 72px (plus a little extra for the actual path effect).
@mdboom / @leejjoon - do either of you know what behaviour we actually want?
mdboom commentedon Mar 20, 2014
The font size given to the
Textobject is specified in points. The PDF, PS and SVG backends all have a "hardcoded" dpi of 72 -- the native "unit" is always 72 units per inch, and the "dpi" passed to savefig is only intended to affect how images are resampled. Maybe that helps -- if I have time this afternoon, I may look a little deeper myself.leejjoon commentedon Mar 20, 2014
It think It will be fixed by implementing the points_to_pixel method for the PathEffectRenderer class.
BUG : fix for text path rendering issues
tacaswell commentedon May 9, 2014
@megies I put @leejjoon 's fix in a PR, can you see if it fixes your problem?
megies commentedon May 13, 2014
Looks good to me. 👍
Although it's been a while since I reported this and I can't exactly remember where this first popped up. But I put some effort in a solid bug report in the first place and the above code snippet seems fixed by this:
pelson commentedon May 21, 2014
#3081 resolves (not quite merged, but I will do it in the next couple of days unless somebody else beats me to it 😉 )