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

[MinRK]

On Tue, Oct 19, 2010 at 15:05, Fernando Perez <fperez.net at gmail.com> wrote:

> On Sun, Oct 17, 2010 at 2:28 PM, Mark Voorhies <mark.voorhies at ucsf.edu>
> wrote:
> > I tried a first pass at this (branch "pastefig" in my github repository.
> > Latest commit:
> >
> http://github.com/markvoorhies/ipython/commit/3f3d3d2f6e1f457856ce7e5481aa681fddb72a82
> > )
>
> Thanks!!!
>
> > The multi-image bundle is sent as type "multi", with data set to
> > a dict of "format"->data (so, currently,
> > {"png" : PNG data from matplotlib,
> >  "svg" : SVG data from maptplotlib}
> > )
> > ["multi" is probably not the best name choice -- any suggestions for
> >  something more descriptive/specific?]
>
> It may be time to stop for a minute to think about our payloads.  The
> payload system works well but we've known all along that once we have
> a clearer understanding of what we need, we'd want to refine its
> design.  All along something has been telling me that we should move
> to a full specification of payloads with mimetype information (plus
> possibly ipython-specific extra data).  Python has a mimetype library,
> and if our payloads are properly mimetype-encoded, web frontends would
> have little to no extra work to do, as browsers are already tooled up
> to handle gracefully mimetype-tagged data that comes in.
>
> What do people think of this approach?
>
> > Naively sending PNG data causes reply_socket.send_json(repy_msg)
> > in ipkernel.py to hang (clearing the eighth bit of the data fixes this,
> > does ZMQ require 7bit data?) -- I'm currently working around this by
> > base64 encoding the PNG, but this may not be the best choice wrt
> > bandwidth.
>
> That's very odd.  Brian, Min, do you know of any such restrictions in
> zmq/pyzmq?  I thought that zmq would happily handle pretty much any
> binary data...
>

Sorry, I sent this a few days ago, but failed to reply-all:

It's not zmq, but json that prevents sending raw data.  ZMQ can send any
bytes just fine (I tested with the code being used to deliver the payloads,
and it can send StringIO from a PNG canvas no problem), but json requires
encoded strings.  Arbitrary C-strings are not necessarily valid JSON
strings. This gets confusing, but essentially JSON has the same notion of
strings as Python-3 (str=unicode, bytes=C-str).  A string for them is a
series of *characters*, not any series of 8-bit numbers, which is the
C/Python<3 notion. Since not all series of arbitrary 8-bit numbers can be
interpreted as valid characters, JSON can't encode them for marshaling.
Zeroing out the 8th bit works because all 7-bit numbers *are* valid ASCII
characters (and thus also valid in almost all encodings).

JSON has no binary data format. The only valid data for JSON are: numbers,
encoded strings, lists, dicts, and lists/dicts of those 4 types, so if you
want to send binary data, you have to first turn it into an *encoded*
string, not a C-string.  Base64 is an example of such a thing, and I don't
know of a better way than that, if JSON is enforced. Obviously, if you used
pickle instead, there would be no problem

This is why BSON (the data format used by MongoDB among others) exists. It
adds binary data support to JSON.

-MinRK


>
> > Generating the PNG from the mpl AGG backend does indeed give
> > nice clipping in the Qt console.  The one wrinkle is that the default
> > PNG images were larger than what we previously had in Qt.  Currently
> > working around this by requesting 70dpi PNGs from matplotlib, but
> > I'm not sure what the default should be (since this is a kernel-side
> > decision, it sets an upper limit on resolution for clients that don't
> > do their own re-rendering from the SVG; since the payload is broadcast,
> > this decision also has a bandwidth consequence for all clients).
>
> I think setting 72dpi for this (the default for low-resolution
> printing) is probably OK for now.  Later we can expose this as a
> user-visible parameter and even one that could be tuned at runtime.
>
> > One question is how much of this can/should be configured in the kernel
> > vs. the client(s).  Are there situations where it would make sense to
> > supplement the main broadcast channel with a "high bandwidth" channel
> > for the subset of clients that want to receive, e.g., pdf data (or would
> the
> > complexity cost be too high to justify this)?
>
> I think we simply want all payloads to move to the pub socket, and for
> now keep a simple design.  We need the payloads on the pub sockets so
> multiple clients can process them.  Once that is working, we can
> consider finer-grained filtering.  One step at a time :)
>
> > If the direction in my pastefig branch looks reasonable, let me know and
> > we can continue the discussion in the context of a pull request.
>  Otherwise,
> > it might be useful to have some more discussion on this thread wrt
> > structuring/configuring the payload and wrapping it on the Qt side.
>
> Let's see what comes back here about the mimetype and zmq questions,
> and we'll then refine it for a pull request.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101019/77b744a3/attachment.html>