matplotlib-devel Mailing List for matplotlib

On Sep 12, 2007, at 3:27 PM, Paul Kienzle wrote:
>> Extensibilty:
>>
>> We would like to make it fairly easy for users to add additional
>> non-linear transformations. The current framework requires 
>> adding a
>> new function at the C++ layer, and hacking into axes.py to support
>> additional functions. We would like the existing nonlinear
>> transformations (log and polar) to be part of a general
>> infrastructure where users could supply their own nonlinear
>> functions which map (possibly nonseparable) (xhat, yhat) ->
>> separable (x, y). There are two parts to this: one pretty easy and
>> one pretty hard.
>>
>> The easy part is supporting a transformation which has a separation
>> callable that takes, eg an Nx2 array and returns and Nx2 array. 
>> For
>> log, this will simply be log(XY), for polar, it will be
>> r*cos(X[:,0]), r*sin(X[:,1]). Presumably we will want to take
>> advantage of masked arrays to support invalid transformations, eg
>> log of nonpositive data.
>>
>> The harder part is to support axis, tick and label layout
>> generically. Currently we do this by special casing log and polar,
>> either with special tick locators and formatters (log) or special
>> derived Axes (polar).
>
> Another hard part is grids. More generally, a straight line in
> x,y becomes curved in x',y'. Ideally, a sequence of points plotted
> on a straight line should lie directly on the transformed line. This
> would make the caps on the polar_bar demo follow the arcs of the grid.
>
> The extreme case is map projections, where for some projections, a
> straight line will not even be connected.
Just wanted to chime in because I've done some thinking on this 
problem for Chaco. Right now chaco's coordinate transformation 
process ("mapping") is handled by explicit objects that subclass from 
1D and 2D mapper base classes. We're talking about moving to a 
scheme where the DisplayPDF GraphicsContext is extended into a 
MathematicalCanvas that is both aware of the transformation stack and 
is also aware of "screen" properties such as subpixel alignment and 
such. You would then be able to hand off dataspace coordinates to 
methods like move_to(), line_to(), rect(), etc., so you could move_to 
() a dataspace coordinate and then draw a screen-aligned box. The 
MathCanvas would also have additional methods like geodesic_to() for 
rendering manifold-aware grids and axes. (Of course, grids aren't 
necessary geodesics all the time.)
I don't know if discontinuous map projections could be handled 
cleanly in such a framework, without the renderer querying the canvas 
about screenspace limits of the current transformation.
> Another issue is zooming and panning. For amusement, try it with
> polar_demo.
Yes, one of the problems with non-linear transformations is that 
panning is very much a screen space interaction, and you have to map 
it back into data space to do proper data clipping and 
transformation. Unfortunately (and this is a problem even with 
logarithmic plots), the user may sometimes want to view things on the 
screen that are outside the valid domain of the coordinate transform, 
in which case the code handling the interaction (the "tool", in chaco 
parlance) has to be smart enough to maintain screen-space coordinates 
only.
-Peter

The usetex support in pdf is now a little better, so I am enabling it
now. At least it is more entertaining than NotImplementedError...
I have fixed some of the biggest problems (the broken font embedding
causing crashes of Preview.app, and the lack of virtual font support).
It still makes some assumptions about the TeX distribution: you need
kpsewhich and pdftex.map, so on TeX Live or (I presume) teTeX you are
fine, but I have no idea about Windows.
Transformations of Type-1 fonts are not implemented, so if you try to
use $\alpha$ with Times, TeX typesets an alpha from Symbol and slants
it, but you get the non-slanted version. Fixing this (and adding
subsetting support) probably requires a complete Type-1 parser.
There is support for baseline alignment, but it is based on finding the
baseline of the lowest character, so subscripts will throw it off. A
good solution will require some TeX magic.
Reports of bugs (or successes) are welcome.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks