IPython qtconsole (0.12) can't export to html with external png

[claumann]

This error looks a bit like that in issue #1087 but the details are different. I create a qtconsole session with some embedded figures. Export to HTML with inline PNG works fine. Export to XHTML/SVG 'works' (with missing images). Export to HTML with external PNG creates a folder with the PNG files correctly but fails to write the HTML (leaving a zero size .html file) with the following error:

Error exporting HTML to /Users/claumann/Desktop/test/test.html
'ascii' codec can't decode byte 0xc2 in position 2287: ordinal not in range(128)

I have an html (with embedded PNG) that constitutes a minimal session reproducing this but I don't know how to attach it to this issue. The (non-graphical) content:

In [1]: figure()
scatter(r_[0,1,2], r_[0,1,2], marker='x')
display(gcf())

<embedded image>

In [2]: !uname -a
Darwin blackbear.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

In [3]: np.__version__
Out[3]: '2.0.0.dev-26aa3cf'

In [4]: pylab.__version__
Out[4]: '2.0.0.dev-26aa3cf'

In [5]: matplotlib.__version__
Out[5]: '1.2.x'

[fperez]

I can confirm the problem, and it's truly weird: if I type this:

scatter(r_[0,1,2], r_[0,1,2], marker='x')

everything seems to work fine. But if instead I do this:

figure()
scatter(r_[0,1,2], r_[0,1,2], marker='x')

then saving with external PNG produces the error you indicate above. Now, those two calls should be the same from our perspective, so I really don't get what's going on. We'll have to dig in to figure this out, but obviously we can't release 0.12 with broken qt console export.

Thanks for the timely report!

[minrk]

simple reproduce:

In [1]: u'é'
In [2]: plot(rand(100))
<save>

I've narrowed it down to image_tag returning unicode, but re.sub not handling that properly. Ensuring that image_tag returns utf8-encoded str solves the issue, and I'm right now just trying to figure out the best way to do it.

[fperez]

Actually, I just confirmed that this bug exists since 0.11, so I'm bringing the priority down to high. If the bug has been in the wild for 4 months, I don't want to hold the 0.12 release just for it.

But still, it is real and serious, so we should definitely try to address it ASAP. With a bit of luck we'll have it fixed before the release, but since that's coming this weekend, it may not quite happen right away.

[fperez]

Ah, yes: the re library is known to have unicode issues, there's even a proposed new regexp library for python itself partly due to these problems. Thanks for getting onto this one!

[minrk]

PR #1165 seems to address the issue