bug: path effects in text() change text properties

[megies]

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:

import matplotlib
matplotlib.use("TKAGG")
import matplotlib.pyplot as plt
import matplotlib.patheffects as PathEffects

plt.text(0, 0, "BAD", size=100,
         #path_effects=[PathEffects.withStroke(linewidth=3,
         #                                     foreground="red")])
         # EDIT: even `Normal()` exposes the bug
         path_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.

Here's the buggy output png image:

[tacaswell]

@pelson Can you take a look at this one too?

[megies]

Here's my build output.. just in case. https://gist.github.com/megies/9468079

[pelson]

@pelson Can you take a look at this one too?

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]

Btw, it doesn't take withStroke(...), even path_effects=[PathEffects.Normal()] produces the bug.

[pelson]

path_effects=[PathEffects.Normal()] produces the bug.

Thanks, that is worth knowing.

[pelson]

P.S. Workaround: plt.savefig("/tmp/patheffects_bug.png", dpi=plt.gcf().dpi)

[pelson]

P.S. Workaround: plt.savefig("/tmp/patheffects_bug.png", dpi=plt.gcf().dpi)

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/):

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?

[mdboom]

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.

[leejjoon]

It think It will be fixed by implementing the points_to_pixel method for the PathEffectRenderer class.

@@ -152,6 +152,9 @@ class PathEffectRenderer(RendererBase):
             renderer.draw_path_collection(gc, master_transform, paths,
                                           *args, **kwargs)

+    def points_to_pixels(self, points):
+        return self._renderer.points_to_pixels(points)
+
     def _draw_text_as_path(self, gc, x, y, s, prop, angle, ismath):
         # Implements the naive text drawing as is found in RendererBase.
         path, transform = self._get_text_path_transform(x, y, s, prop,

[tacaswell]

@megies I put @leejjoon 's fix in a PR, can you see if it fixes your problem?

[megies]

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]

#3081 resolves (not quite merged, but I will do it in the next couple of days unless somebody else beats me to it 😉 )