Basically, there are two select modes in Illustrator. The
> first, "Selection tool", selects a whole group of paths.
> The second, the "Direct selection tool" selects the path
> segment or otherwise smallest path portion possible.
Hi Andrew -- thanks for the detailed information vis-a-vis
Illustrator. Things are clearer to me now, but it looks like I need
to get my hands on Illustrator and play with a few plots to get a
better feel for it.
I am curious what kinds of editing you are doing with your plots.
The reason I ask is that I wanted to make sure you know that you can
control a lot from within matplotlib using the return values of the
functions. These return the text, line, and patch objects, and you
can use any method in their API to control them, including position,
size, linewidth, colors, symbols, etc. Ditto for the axes -- their
position, line styles, and colors can all be controlled with the
symbols, lines = errorbar(t, s, e, fmt='o')
set(lines, 'linewidth', 3)
set(symbols, 'markerfacecolor', 'g')
set(symbols, 'markeredgecolor', 'r')
set(symbols, 'markersize', 10)
If you want to have all the error bars in the axes, you can change the
ylimits of the axes with
set(gca(), 'ylim', [-1,10])
Likewise, you can control the location and properties of the
tickmarks, ticklabels, etc...
Not that this obviates the need to make a sane PS renderer, but I just
wanted to make sure you were aware of the possibility. I generally
try to do everything in code and minimize the amount of manual editing
because invariably I have to regenerate the figure with new data or
new stats and then I have to redo everything manually again.
So if you tell me the kinds of things you're trying to do, perhaps I
can point you to existing features that provide this, or include some
of them in the matplotlib API. This would also give me a better idea
of how to think about redesigning the PS engine to make it more
palatable to PS editors.
> Yes, I just wonder about the explicit-ness of a decision
> about whether it's matplotlib or PS that does clipping. I
> don't know enough to feel strongly, but if file-size is a
> factor, it should presumably be done by matplotlib. On
> the other hand, I think optimizations (even for file size)
> should happen later and for now maybe rendering everything
> to PS and letting it handle clipping is best. On the
> third(!) hand, huge files are clearly undesirable and
> perhaps the best plan is what seems to already be done --
> any primitives totally outside the clipping area aren't
> drawn, but otherwise, they are drawn with PS itself doing
> the clipping. This point is just food for thought.
This is generally the approach I take. lines handle clipping
themselves. This lets me plot really long signals (5 minutes of EEG)
with only 10 second windows on the screen at the time -- a matplotlib
clip. In addition, I rely on the graphics context clip (GTK / PS) to
handle the little things like circle markers extending outside the
axes lines, the top of a curve that extends past the top of the axes,
etc.... You can read the gory details in the _set_clip function in
the lines module, when you need a distraction from your thesis.
Without too much work, I can probably make a "no clip" an option of
the figure or axes if this would be useful.
> No real problem, I'm just (mildly) against idea of
> invisible primitives in PS files. (This probably stems
> from me dealing with PS output from matlab5 many years ago
> when I remember sorting through layer after layer after
> layer of "strangely behaved rectangles" just to manipulate
> my data. It's quite funny to me that matplotlib produces
> the most matlab-like PS files I've seen in a while!
Oh, now that was a low blow -- matlab5! And just what kind of
manipulation of your data are you doing -- you're not trying to cheat
on those error bars are you <wink>?