text drawing from the renderer

I'd like to refactor text so that backends will no longer need to
implement classes derived from AxisTextBase, but rather provide a
RendererBackend.draw_text method (as Jeremy suggested many moons ago).
This will enable easy switching of backends in midstream, as discussed
in the last couple of days on matplotlib-users. One important
limiting factor in the current implementation is the fact that axes,
labels, etc.... instantiate derived AxisText classes. Thus backend
specific implementations inadvertently creep into (what should be)
backend-independent interface classes, like Axes, Legend, Tick, Axis,
etc...

I think we should implement a Text(Artist) class which is totally
backend independent (analogous to Line2D and Patch) with most of
protected attribute data defined in AxistTextBase. This class would
store all the relevant text properties (fontsize, fontname,
fontweight, etc) in a standardized way, and provides a few backend
independent utility funcs. The renderer would implement get_text_bbox
and draw_text, each of which take a text instance as an argument;
these two funcs, are the workhorses of text implementations.

Jeremy, do you see any major problems with this proposal vis-a-vis wx?

On a related note, we should shoot for standardization of font names
for the next major release. Which fonts does WX provide, and which
should be part of the core?

Thoughts?

JDH

John Hunter said:

I'd like to refactor text so that backends will no longer need to
implement classes derived from AxisTextBase, but rather provide a
RendererBackend.draw_text method (as Jeremy suggested many moons ago).
This will enable easy switching of backends in midstream, as discussed
in the last couple of days on matplotlib-users. One important
limiting factor in the current implementation is the fact that axes,
labels, etc.... instantiate derived AxisText classes. Thus backend
specific implementations inadvertently creep into (what should be)
backend-independent interface classes, like Axes, Legend, Tick, Axis,
etc...

I think we should implement a Text(Artist) class which is totally
backend independent (analogous to Line2D and Patch) with most of
protected attribute data defined in AxistTextBase. This class would
store all the relevant text properties (fontsize, fontname,
fontweight, etc) in a standardized way, and provides a few backend
independent utility funcs. The renderer would implement get_text_bbox
and draw_text, each of which take a text instance as an argument;
these two funcs, are the workhorses of text implementations.

Jeremy, do you see any major problems with this proposal vis-a-vis wx?

The trickiest problem is that WX requires a device context to be able to
determine the size of a given piece of text, since in WX, GetTextExtent()
is a member of wxDC. This was a major pain when implementing text in
backend_wx, and is one of the messier pieces of code. Provided that the
implementation only requires the calculation of text extent when there is
a gc instantiated, we should not have much problem. From the sound of your
proposal, this would be the case.

On a related note, we should shoot for standardization of font names
for the next major release. Which fonts does WX provide, and which
should be part of the core?

WX provides the following aliases (you'll see some of them used in
backend_wx):

wxSWISS - a Sans-serif font
wxROMAN - a Serif font
wxSCRIPT - a cursive font
wxDECORATIVE - not sure - never used it!
wxMODERN - a fixed pitch font
wxDEFAULT - default - seems to be same as wxMODERN on Windows

The mapping to platform fonts depends on the WX platform, but there is a
further complication: non-TrueType fonts cannot be rotated on Windows
platforms, and some of the above are defined as non-TT fonts.

I suppose that we should have a dictionary which should be populated by
the backend. For backend_wx, I'm rather inclined to choose the some of the
standard Windows fonts, rather than the WX defaults. On Linux, I really
need to look into anti-aliased text, but it probably makes sense to use
those nice new fonts supplied with Gnome 2 (as they are GPL). This means
that I may have to introduce a platform dependency into backend_wx to
ensure that a TT font is always chosen. We should also ensure that the
user can specify platform fonts if they really wish (again, backend_wx
allows for this by checking for a font name which is not in its
dictionary).

I should also remind you that (since the backend will no longer be
responsible for scaling), WX does not cope properly with scaling/rotation
of font sizes over 60 pts on all platforms. I currently simply clip the
maximum font size at 60 in backend_wx (which works fine in practice since
this is always readable) - it may be advisable to be able to cope with
this (e.g. let the backend clip point sizes it cannot handle, provided
that it correctly returns the text extent in such a case).

Overall, it's a very good idea. I can't see any major issues, and I think
I've outlined the minor ones.

Regards

Jeremy

ยทยทยท

Thoughts?

JDH

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options