attn@pwuertz

Thank you for working on this@takimata !

This will definitely need a test (to make sure we do not accidentally break it in the future).

ooops, I mistakenly marked this draft, but apparently I cannot un-mark it (??). If you rebase it will clean up the tests.

Yeah, hitting the wrong button in the web interface at the wrong time has all kinds of "interesting" effects...

Ping.

I rewrote history to clean up my mess, hope nobody has used my branch yet.

@QuLogic Rebased on master

• It looks like you can use\usepgfmodule/\usepgflibrary locally, so I would just load the required pgf modules when emitting the paths with sketch params, so that this works relatively transparently for the end user.
• I'm not sure this actually works? (Or the scales are very different?) e.g.xkcd(); plot([1, 2])[0].set_sketch_params(10, 128, 16); savefig("/tmp/test.png", backend="png") gives
  
  i.e. the wobbliness is barely (if at all?) present?

• Like this?

• Try a smaller length, e.g., 64 instead of 128.
  Unfortunately matplotlib and PGF require different parameters for the same/comparable image, e.g.scale=2, length=16, randomness=16 gives XKCD-like results with PGF (see pics below).

  Assuming that I correctly convert pixels to inch, I think this is caused by the different approach by PGF/matplotlib (see discussion above).
  Fixing this would require matplotlib/PGF to use the same algorithm to generate the wobbliness.

withplt.xkcd(scale=2, length=16, randomness=16); plt.plot([1, 2])[0].set_sketch_params(10, 64, randomness=16)

Matplotlib:

PGF:

I don't think the algorithms have to match exactly, but I think it would be preferable for the pgf backend to scale the numbers in whatever way needed to make the visual impression similar for similar values of sketch_params.

I agree from a user perspective. But in the end it would be an ugly abstraction which breaks in some cases and which always breaks the documentation in a way that the units given there ("length in pixels") are simply not correct.

When using the PGF backend at all, my only use case for the matplotlib rendering was a (rough) preview, because the PDF produced by LaTeX doesn't exactly match matplotlib's PDF anyway.
So I think people would tend to accept a different behaviour...

For merging this PR, such a workaround could be ok, but in the long term I would prefer having this as a separate feature. I.e., PGF-like sketched lines as a strategy for set_sketch_params.

We talked about this on the call today and the consensus is that it is OK if the wiggles are different (as you would expect because they are implemented differently under the hood), but at least the amplitude should be scale to look ball-park the same.

@tacaswell Thanks for discussing and deciding this. I've added some scaling which should work for most cases.

importmatplotlibasmplimportmatplotlib.pyplotaspltmpl.rcParams.update({'pgf.texsystem':"pdflatex",'figure.figsize': [4,3],})plt.xkcd(scale=1,length=100,randomness=8)plt.plot([1,2])[0].set_sketch_params(scale=10,length=32,randomness=16)plt.tight_layout()plt.savefig("builtin.png")plt.savefig("via_pgf.png",backend="pgf")

now yields

@QuLogic rebased to clean up the tests

Thanks@takimata ! Congratulations on your first Matplotlib PR 🎉 Hopefully we will hear from you again!

Thanks for merging!