On Wed, May 11, 2011 at 1:43 PM, todd rme <toddrme2...@gmail.com> wrote:
> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben.r...@ou.edu> wrote:
> >
> >
> > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <
> brenb...@brenbarn.net>
> > wrote:
> >> One thing I've always wondered: is it fundamentally impossible to
> >> change the fact that, in matplotlib, you cannot know how big a drawn
> >> object will be until you actually draw it? When I was doing some
> >> animation stuff a while back this caused me a lot of headache, for the
> >> reasons Tony Yu mentioned: it means you have to draw everything
> >> multiple times. It would really help if it were possible to specify
> >> objects' parameters and get their sizes without drawing them.
> >>
> >> -- Brendan Barnwell
> >> "Do not follow where the path may lead. Go, instead, where there is no
> >> path, and leave a trail." --author unknown
> >>
> >
> > Most things, we do know the sizes of. It is my understanding that it is
> the
> > text objects that is the unknown. If this could be solved, then a layout
> > engine would be much more feasible. The problem is that even LaTeX has
> to
> > re-render things multiple times to get this right for an arbitrary font.
> If
> > we were to restrict ourselves to particular fonts and package those fonts
> > with matplotlib, then we could have an internal table of size information
> > for each glyph and compute it on the fly and lay everything out right.
> But,
> > that would cause us to give up significant benefits for another benefit.
> >
> > I think the pain of the bootstrapping/re-rendering approach could be
> reduced
> > significantly if we could get various aspects of matplotlib figure
> building
> > to be faster. Last time I checked, there is significant amount of
> > processing time spent in calculating the ticks for the axes. Maybe if we
> > focus some efforts in improving the efficiency of certain parts of
> > matplotlib, maybe we could introduce a convenience function like the one
> > earlier in this thread that some users can choose to use with only a
> slight
> > penalty in speed. I personally would not want to make it default, but
> > certainly would consider highly advertising such a function.
> >
> > Just my two cents,
> > Ben Root
>
> Perhaps there could be three options:
>
> 1. Manual mode: current behavior
> 2. Database mode: uses a list of known fonts. When a font not found
> in the database is used, it falls back to manual mode.
> 3. Automatic mode: uses a list of known fonts. When a font not found
> in the database is used, it renders the text alone in an invisible
> figure to calculate the space needed, then uses that information to
> set the margins. Alternatively, create a temporary mini font database
> just for the characters needed. The former approach may be faster,
> but the latter may be easier to program since it could share a lot of
> code with the database.
>
> There could also be a function to scan a particular font and add to
> the database (there would probably be a separate user database in your
> matplotlib configuration directory that this would use, as well as
> probably caching the measurements from text used in automatic mode for
> future versions of the figure).
>
> -Todd
>
>
That might be a possible direction. Obviously, any route taken will have to
be well thought-out and designed. What is great about moving over to git is
that the user community can easily experiment on larger changes to the
code-base, and make it easier for others to test out experimental designs
and collaborate. I encourage those in this thread to make a fork of
matplotlib on github and experiment with some of these ideas and we all can
play around with some of these parts.
As a further bit of information, I believe that there is an old project that
attempted a layout engine for matplotlib (
https://github.com/matplotlib/mplsizer). I have never used it, nor do I have
any idea if it still works, but it may be an interesting codebase to start
from.
As a further comment about a database of text size information. An
interesting complication I just noticed are fonts that allow certain
combinations of characters to overlap a bit. For example, right now I
noticed that using Gils Sans in LibreOffice that the word "Tracking" has the
'r' in with the 'T'. Calculating the amount of space a particular set of
characters might take up may not be very straight-forward.
Just another 2 cents,
Ben Root
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
