Re: [matplotlib-devel] text drawing from the renderer

[Jeremy O'D. <je...@o-...>]

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 you=
r
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 th=
e
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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>