But there is no reason you shouldn't be able to create a PS
>> figure or a GD figure to save. I've been meaning to add a 'PS'
>> extension checker in the savefig command that would enable you
>> to save to PS from any backend.
>> Is this primarily what you need to switch backends for?
> Yes that's the sweet spot.
> Presumably the Save button on the GTK/WX GUI just calls
> savefig()? In which case you'd be able to save postscript
> from there too, which would be popular too I think.
I've made some changes to the GTK backend that enable save to a ps
figure, either by calling
or using a file with the ps extension from the save figure dialog.
It's not too pretty internally but it works (more or less). Consider
this a preliminary functional implementation with known bugs that will
be hammered out later.
The problem in implementing this is that the AxisText instances (axis
and tick labels, title) are backend dependent. As Jeremy noted when
he did the wx backend, this is different than the way other objects
(lines, patches) are handled. With some refactoring this can be made
The other problem is that the default fonts are different between the
backends, so you'll get a lot of warnings like "Falling back on
default font". This is another problem we need to clear up -- ie, we
need a set of shared fontnames between backends.
Finally, a 'gotcha' that you need to watch out for is that text
references in scripts will be destroyed by calling a postscript
savefig (because of the way text instance conversions are handled).
So if you did
ax = subplot(111)
labels = ax.get_xticklabels()
set(labels, 'color', 'r')
The color change would not take effect because the text references
have been changed. Moral of story: do not change figure text
properties after calling savefig for a ps figure with text instances
obtained before the savefig call.
Other than that it should work. Let me know. I've updated CVS but be
forewarned: CVS mirrors sometime take a while to update.