matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
> I would like to ask for some advice from those out there who have experience 
> dealing with fonts and text layout.
> 
> At the end of this message is the output of dvitype, which translates a dvi 
> file (in this case a file typesetting "0.8" in ptmr7t fonts) into human 
> readable output. I have considered writing a dvi parser for mpl, intending to 
> extract the information necessary to render text with mpl's existing font and 
> text support. There is some more information at 
> http://en.wikipedia.org/wiki/DVI_(TeX) and 
> http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.
> 
> Is this worth pursuing? If I could make it work, mpl's only external 
> dependency would be TeX/LaTeX, even dvipng would not be required.
Quite probably. dvitype is new to me. Doing a DVI interpreter for mpl and Chaco
has been on my list of things to look at for some time. The things stopping me
(besides the density of the DVI standard) was that all of the readable code I
found for interpreting DVI files has been GPLed.
You will need to access the parameters defined in the TeX Font Metric files, I
think. I recommend using tftopl(1) to convert them to a parseable form.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

I would like to ask for some advice from those out there who have experience 
dealing with fonts and text layout.
At the end of this message is the output of dvitype, which translates a dvi 
file (in this case a file typesetting "0.8" in ptmr7t fonts) into human 
readable output. I have considered writing a dvi parser for mpl, intending to 
extract the information necessary to render text with mpl's existing font and 
text support. There is some more information at 
http://en.wikipedia.org/wiki/DVI_(TeX) and 
http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.
Is this worth pursuing? If I could make it work, mpl's only external 
dependency would be TeX/LaTeX, even dvipng would not be required.
Thanks,
Darren
(I'm sorry to beat this issue into the ground)
$ dvitype 8b85d26da2410f54cd2d70976999b1d8.dvi
This is DVItype, Version 3.6 (Web2C 7.5.5)
Options selected:
 Starting page = *
 Maximum number of pages = 1000000
 Output level = 4 (the works)
 Resolution = 300.00000000 pixels per inch
numerator/denominator=25400000/473628672
magnification=1000; 0.00006334 pixels per DVI unit
' TeX output 2006年01月21日:1639'
Postamble starts at byte 144.
maxv=41484288, maxh=26673152, maxstackdepth=3, totalpages=1
Font 14: ptmr7t---loaded at size 655360 DVI units
42: beginning of page 1
87: down4 41484288 v:=0+41484288=わ41484288, vv:=2628
92: push
level 0:(h=0,v=41484288,w=0,x=0,y=0,z=0,hh=0,vv=2628)
93: down4 -39649280 v:=41484288-ひく39649280=わ1835008, vv:=116
98: down4 37683200 v:=1835008+たす37683200=わ39518208, vv:=2503
103: push
level 1:(h=0,v=39518208,w=0,x=0,y=0,z=0,hh=0,vv=2503)
104: down4 -35389440 v:=39518208-ひく35389440=わ4128768, vv:=262
109: push
level 2:(h=0,v=4128768,w=0,x=0,y=0,z=0,hh=0,vv=262)
110: right3 5046272 h:=0+5046272=5046272, hh:=320
[ ]
114: fntdef1 14: ptmr7t
136: fntnum14 current font is ptmr7t
137: setchar48 h:=5046272+たす327680=わ5373952, hh:=341
138: setchar46 h:=5373952+たす163840=わ5537792, hh:=351
139: setchar56 h:=5537792+たす327680=わ5865472, hh:=372
[0.8]
140: pop
level 2:(h=0,v=4128768,w=0,x=0,y=0,z=0,hh=0,vv=262)
141: pop
level 1:(h=0,v=39518208,w=0,x=0,y=0,z=0,hh=0,vv=2503)
142: pop
level 0:(h=0,v=41484288,w=0,x=0,y=0,z=0,hh=0,vv=2628)
143: eop

= What's going on? =
The Matplotlib cookbook is hosted at scipy.org. The backend software 
that hosts the website is being changed (from Plone to MoinMoin). This 
morning I converted the matplotlib cookbook, which is hosted at 
scipy.org, for use with the new software. It is available at 
http://new.scipy.org/Wiki/Cookbook/Matplotlib . (This URL to the new 
cookbook will change once the transition is complete.)
Unfortunately in the transition period, there will be 2 copies of the 
cookbook available online:
 1) the shiny new cookbook at currently available at 
http://new.scipy.org/Wiki/Cookbook/Matplotlib
 2) the slow-to-edit and to-be-removed cookbook at 
http://www.scipy.org/wikis/topical_software/MatplotlibCookbook
*Please make any changes to the new cookbook!*
= Further information =
I've been spearheading an effort to move the scipy.org website to 
something more user-friendly. The goals were for the new site to be:
 * more inclusive of the scientific-computing-using-python community 
rather than the those-using-scipy-the-package community
 * easier (faster) for people to edit
 * more visually pleasing. (aka better marketing)
The decision we took was to make the new website based on MoinMoin, the 
wiki engine available at http://moinmoin.wikiwikiweb.de .
= What you can do =
Please review the Matplotlib Cookbook in its new location. If you can 
correct any errors yourself, that would be greatly appreciated. If you 
just drop me an email, that's fine, too -- I'll try to fix it. We'd also 
appreciate any help and suggestions for the entire new website.
Cheers!
Andrew

Ted Drain wrote:
> John & Fernando,
> I think the basic problem can be solved in a number of ways. Normally a 
> GUI widget will have an initial size and when it is placed in a window, the 
> window will layout around it (or to it's own size). However, once the 
> window is drawn, changing the size of one or more widget that it contains 
> doesn't mean you're changing the size of the window.
> 
> Here's some ideas for how to fix this:
Thanks for the feedback, Ted. I hope one of your suggestions can be 
implemented (2 sounds very reasonable). If not, at least I think the 'forward' 
option should then just be removed. There's no point in exposing a feature 
known to crash all but ONE backend, I think.
Regards,
f

John & Fernando,
I think the basic problem can be solved in a number of ways. Normally a 
GUI widget will have an initial size and when it is placed in a window, the 
window will layout around it (or to it's own size). However, once the 
window is drawn, changing the size of one or more widget that it contains 
doesn't mean you're changing the size of the window.
Here's some ideas for how to fix this:
1) Tell people they have to use the resize method on the window object. 
Pro: simple. Con: not really the API that you want.
2) Write a resize method (but probably don't call it 'resize' because every 
widget system already uses that name) and have it emit a signal 
(callback). When you construct the window object, connect that signal to a 
resize method (again not called 'resize') on the window object that can 
compute it's correct size based on the new plot size. This way the plot 
doesn't know who's getting the signal and can remain independent of it's 
container.
3) Explore the different backends and see if there is a way to configure 
the window objects so they dynamically resize when a child widget is 
changed. I did a quick check through Qt and couldn't find anything for 
this but it might be there.
It seems like 2) would be pretty simple to implement. In the Qt backend, I 
think you could do this by:
backend_qtagg.py: In FigureCanvasQTAgg.resizeEvent, add an emit call to 
create a new signal.
self.emit( qt.PYSIGNAL( "plotResize" ), ( w, h ) )
backend_qt.py: In FigureManagerQT.__init__, connect that signal to a new 
method resizeFromPlot( w, h ). This method should contain the code from 
the current __init__ method that resizes the window based on a given plot 
size.
self.connect( self.canvas, PYSIGNAL( "plotResize" ), self.resizeFromPlot )
This should make it so that any size change to the plot will trigger a 
resize on the main window. There may be a circularity problem but we'd 
have to try it first an see if calling resize on the main window triggers a 
resize in the plot.
Ted
At 10:25 AM 1/22/2006, John Hunter wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
>
>
> Fernando> TypeError: resize() takes exactly 2 arguments (3 given)
>
>Yes, this is basically broken on all GUIs except GTK*. There was a
>fair amount of discussion back in octover on the devel list about how
>to do this right, since basically it requires a child to call a method
>on the parent and we don't know a-priori what the container will be.
>In pylab we can make it work (but haven't yet across backends) because
>we know the parent will be a FigureManager instance, but it would be
>nice to come up with a generic method that works regardless of whether
>you are using mpl in pylab or not. It's on the slow burner,
>currently.
>
>JDH
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel