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 > > 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 ------------------------------------------------------------------------------ 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
