On Wed, May 11, 2011 at 4:31 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 05/11/2011 09:11 AM, Benjamin Root wrote:
> >
> >
> > On Wed, May 11, 2011 at 1:43 PM, todd rme <toddrme2...@gmail.com
> > <mailto:toddrme2...@gmail.com>> wrote:
> >
> > On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben.r...@ou.edu
> > <mailto:ben.r...@ou.edu>> wrote:
> > >
> > >
> > > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> > <brenb...@brenbarn.net <mailto: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.
>
> The calculation doesn't have to be perfect, it just has to be good
> enough for layout purposes. If one were to ignore kerning, the
> predicted width of a text string would be slightly larger than the
> actual size. I don't think this would cause serious layout problems.
>
> But--is doing the calculation this way actually much faster than letting
> the renderer do it? Enough to be worth building and maintaining all the
> extra machinery?
>
> Eric
>
>
Kerning, that's the term. I couldn't think of it...
As for the issue about is it worth it to have all of this extra machinery,
that was pretty much my point of the email. If someone wants to see if they
can make an elegant solution that works well and is easy to maintain, then I
would have no problem including it into the codebase. However, I am very
doubtful of that and I would rather see effort in improving the efficiency
of various parts of matplotlib so that various brute-force approaches to
layout will have less time penalty. Plus, it wouldn't hurt to have faster
graphics generation for the rest of us, either!
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
