[IPython-dev] [QUAR] Re: Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...

[Fernando Perez]

On Thu, Oct 14, 2010 at 11:50 AM, Mark Voorhies <mark.voorhies at ucsf.edu> wrote:
>> I like the idea of getting the .PNG rather than the .SVG, but can we
>> still embed it in the html output?
>
> The HTML export shouldn't care -- it's still seeing a QImage object with
> a save method (hurray for encapsulation).
>
> Some of the SVG functions may need a bit more overhead (since they're
> no longer "first class") but I've already added some of this for the XHTML
> export (via the _name_to_svg dict that Fernando suggested) so it shouldn't
> be too bad.

The trick will be sending to the client both the svg and the png at
pastefig() time.  Later on the figures may have been destroyed, so
unless we send that on the spot, the client would have no way of
reconstructing this.

Technically it's pretty easy to do: the payload can carry multiple
entries, the client can use the png for on-screen rendering (being
generated by mpl's Agg backend, it's guaranteed to be our "gold
standard" so anything on-screen should use that), and it can then use
the 'hidden' SVG (or pdf - see below) when printing to html/pdf.

The cost is time/bandwidth/memory.  So this should probably be
configurable, and even togglable during runtime.  Sending all three
formats instead of just a png is obvioiusly more expensive, and users
may be OK with plain pngs in some cases (slow link when doing remote
collaboration, for example).

> P.S. What would be really nice, long term, would be for the Qt figure widget
> to hold SVG, PNG, and PDF from Matplotlib (or just a copy-on-write reference
> to the figure if we want to be lazy) and return the appropriate representation
> depending on context.  I think that this would be a way to get vector figures
> in PDF output (e.g., if the widget can tell its being called by a QPrinter rather
> than some other type of QPainter), but this might require fairly deep Qt
> hacking...

We can't do copy-on-write, because the actual mpl figure and the
client are in *separate processes*.  Hence my note above about having
to send those other guys (svg/pdf) right on pastefig().  You either
send them right then and there, or for all intents and purposes they
are lost.

> P.P.S. Tangentially, how easy is it to receive SVG payloads from sources other
> than matplotlib (e.g., if I wanted to mix in SVG's from rpy or from a web resource
> like Gbrowse)?

Trivial.  It will take a tiny amount of code to be written, but
ultimately it's just a matter of calling

add_plot_payload('svg', svg_data).

That's the method whose interface we'll probably want to enhance to
allow for svg/png/pdf multi-format payloads.

Regards,


f