matplotlib-devel Mailing List for matplotlib (Page 460)

Hi Edin,

On Sunday 20 August 2006 10:21 am, Edin Salkovi=C4=87 wrote:
> The SoC deadline (for code) is tommorow (Aug 21st.), so I decided to comm=
it
> what I have done till now to the repository.
>
> JDH is going on a vacation and will not be able to review it for at
> least a week,
> but I had to commit it before 21st. Aug - that's the SoC rules. Hopefully,
> I'll be adding new stuff the next week (and after), but that doesn't
> count as part of SoC anymore...
>
> Since this is my first commit, can anyone please test it. I tested it
> only on my windows box.
>
> I changed
> __init__.py,
> mathtext.py
> CHANGELOG
>
> I added
> mathtext2.py
> mathtext2_demo.py
>
> Anyone who wants to test the new mathtext2 has to add the following line(=
s)
> to the matplotlibrc (mathtext2 is disabled by default):
>
> mathtext2:   True            # Needed to enable the new mathtext
>
> # Font lines, feel free to change or uncomment (BaKoMa is used by default)
> mathtext.rm     :   FreeSerif.ttf
> mathtext.it     :   FreeSerifItalic.ttf     # Text italic
> mathtext.tt     :   FreeMono.ttf    # Typewriter (monospaced)
> mathtext.mit    :   FreeSerifItalic.ttf     # Math italic
> mathtext.cal    :   FreeSansOblique.ttf # Caligraphic
> mathtext.nonascii:  FreeSerif.ttf # Used for \sum, \infty etc.
>
> The FreeFont fonts (or any other for that matter) have to be downloaded a=
nd
> put into the mpl-data dir. The default settingsuse the current bakoma
> fonts, and they play pretty well with FreeSerif.ttf as the nonascii
> (unicode) font.
>
> so I recommend you just put the line
> mathtext.nonascii:  FreeSerif.ttf
>
> and comment out the rest (experiment a little with fonts).
>
> Tonight I plan to add support for fractions. Beware that the only
> supported backend for now is Agg.
>
> mathtext2_demo.py is attached

I just updated my svn repository, added the lines you indicated to my rc fi=
le,=20
but when I run the example, mpl can't find the freefonts that I already hav=
e=20
installed on my system. The freefonts I have installed are not ttf, but pfb=
=2E=20
Where should we download from? ftp://ftp.cs.umn.edu/pub/gimp/pub/gimp/fonts=
,=20
for example? I dont think those are what I am looking for. Do they really=20
need to go in mpl-dir? It would be more appropriate if they could be=20
installed somewhere like /usr/share/fonts.

SGVyZSBhcmUgdGhlIHJlYXNvbnMgZm9yIHJld3JpdGluZyBtYXRodGV4dDIgdGhhdCBJIGNhbiBj
b21lIHVwIHdpdGg6CgogKiBPbmUgb2YgdGhlIHJlYXNvbnMgSSBzdGFydGVkIHRoZSBjb21wbGV0
ZSByZXdyaXRlIG9mIHRoZSBwYXJzZXIgaXMgdGhhdApJJ20gYSBuZXdiaWUgYXQgcGFyc2luZywg
YW5kIEkgd2FudGVkIHRvIHRyeSBpdCBvdXQgYSBiaXQuIEkgZGlkbid0IHVuZGVyc3RhbmQKd2h5
IHdhcyBpdCBzbyBkaWZmaWN1bHQgdG8gcGFyc2UgVGVYIChvciBhbnl0aGluZyBhIGxpdHRsZSBi
aXQgY29tcGxpY2F0ZWQKZm9yIHRoYXQgbWF0dGVyKS4gV2VsbCwgbm93IEkga25vdyA7KQoKICog
VGhlIG90aGVyIHJlYXNvbiB3YXMgdGhhdCBJIGRpZG4ndCB1bmRlcnN0YW5kIGZ1bGx5IHRoZSBj
dXJyZW50IHBhcnNpbmcKY29kZSwgb3IgbW9yZSBwcmVjaXNlbHksIHRoZSBwYXJ0IHdoZW4gd2hh
dCdzIGludGVycHJldGVkIGdldCdzIHJlbmRlcmVkLgpBbmQgSSdtIG5vdCB0YWxraW5nIGFib3V0
IGdseXBocywgYnV0IGFib3V0IHRoZSBjb21wbGV4IGNvbnN0cnVjdHMgKHNjcmlwdHMsCmZyYWMn
cyBldGMuKQoKICogVGhlIHRoaXJkIHJlYXNvbiB3YXMgdGhhdCBJIGNhbiBub3cgdHJ5IG91dCBp
biBwYXJhcmVsIHRoZSBuZXcgYW5kIHRoZSBvbGQKY29kZS4gQWxzbywgYmVjYXVzZSBJJ20gbm90
IHRvdWNoaW5nIHRoZSBQUyBhbmQgU1ZHIGJhY2tlbmRzIGZvciBub3cgd2UgY2FuCmhhdmUgdGhl
IGZvbGxvd2luZyBjb2RlIGluIHRoZSBjdXJyZW50IG1hdGh0ZXh0OgoKaWYgcmNQYXJhbXNbc29t
ZV9wYXJhbWV0ZXJdOgogICBmcm9tIG1hdHBsb3RsaWIubWF0aHRleHQyIGltcG9ydCBtYXRoX3Bh
cnNlX3NfZnQyZm9udAplbHNlOgogICBtYXRoX3BhcnNlX3NfZnQyZm9udCA9IG1hdGhfcGFyc2Vf
c19mdDJmb250X2NvbW1vbignQk1QJykKbWF0aF9wYXJzZV9zX2Z0MmZvbnRfc3ZnID0gbWF0aF9w
YXJzZV9zX2Z0MmZvbnRfY29tbW9uKCdTVkcnKQptYXRoX3BhcnNlX3NfcHMgPSBtYXRoX3BhcnNl
X3NfZnQyZm9udF9jb21tb24oJ1BTJykKbWF0aF9wYXJzZV9zX3BkZiA9IG1hdGhfcGFyc2Vfc19m
dDJmb250X2NvbW1vbignUERGJykKCkFsc28sIEkgdGhvdWdodCB0aGF0IHRoZSBhdXRob3Igb2Yg
dGhlIGN1cnJlbnQgY29kZSBiYXNlIGRpZCBzb21lIGRlc2lnbgptaXN0YWtlcyBhdCB0aGUgYmVn
aW5pbmcuIEFuZCwgYmVpbmcgYSBkZXZlbG9wZXIgbmV3YmllLCBpdCdzIGEgbG90IGVhc2llcgp0
byBzdGFydCB0aGluZ3MgZnJvbSBzY3JhdGNoLCB0aGFuIG1ha2UgZml4ZXMgdG8gb2xkIHN0dWZm
IHlvdSBkb24ndAp1bmRlcnN0YW5kIHdlbGwuCgpBcyBmb3IgdGhlIG1hdGh0ZXh0X2RlbW8ucHkg
cGFydCwgZXZlbiByZWFsIFRlWCBjYW4ndCBoYW5kbGUgaXQgOikuIFRoZSBwb2ludAppcyB0aGF0
LCBpLmUuIFxjYWwgc2V0cyB0aGUgY3VycmVudCBmb250ZmFjZSB0byAiY2FsIiwgYW5kIHRoZSBj
aGFuZ2UgaXMKcHJvcGFnYXRlZCB0aWxsIHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgc2NvcGUgKG9y
IHVudGlsbCBpdCBoaXRzIFxybSwgZm9yCmV4YW1wbGUpLiBPbGQgbWF0aHRleHQgYXBwbGllcyBp
dCBvbmx5IHRvIHRoZSBmaXJzdCBpdGVtIGFmdGVyIHRoZSBjb21tYW5kLgoKSSBwcm9taXNlIHRo
YXQgSSdsbCBwb3N0IG1vcmUgYWJvdXQgdGhlIGltcGxlbWVudGF0aW9uIGluIGEgZGF5IG9yIHR3
by4KSSdsbCBhbHNvIHBvc3Qgc2NyZWVuc2hvdHMgKFRlWC9tYXRodGV4dC9tYXRodGV4dDIgc2hv
b3RvdXQpLgoKQ2hlZXJzLApFZGluCgpPbiA4LzE4LzA2LCBKb2huIEh1bnRlciA8amRodW50ZXJA
YWNlLmJzZC51Y2hpY2Fnby5lZHU+IHdyb3RlOgo+ID4+Pj4+ICJFZGluIiA9PSBFZGluIFNhbGtv
dmnCpyA8ZWRpbi5zYWxrb3ZpY0BnbWFpbC5jb20+IHdyaXRlczoKPgo+ICAgICBFZGluPiBIaSBh
bGwsIFBsZWFzZSBKb2huLCB0YWtlIHNvbWUgdGltZSBiZWZvcmUgU2NpUHkgY29uZiB0bwo+ICAg
ICBFZGluPiBhbnN3ZXIgYXQgbGVhc3Qgc29tZSBvZiB0aGlzIHF1ZXN0aW9ucywgYmVjYXVzZSB0
aGUgU29DCj4gICAgIEVkaW4+IGRlYWRsaW5lICgyMXN0IEF1Z3VzdCkgaXMgKnZlcnkqIG5lYXIu
Cj4KPiBBbGFzLCBJIGFtIGFscmVhZHkgaGVyZSBhbmQgaGF2ZSBiZWVuIGEgbGl0dGxlIG91dCBv
ZiBlbWFpbCBjb250YWN0Cj4gd2hpbGUgdHJhdmVsaW5nLiAgU29ycnkgZm9yIHRoZSBkZWxheS4K
Pgo+ICAgICBFZGluPiAxKSBJJ20gaGF2aW5nIHNvbWUgcHJvYmxlbXMgcmVnYXJkaW5nIEZUMkZv
bnQuICBUaGUgcHJvYmxlbQo+ICAgICBFZGluPiBpcyB3aGVuIEkgaW5zdGFudGlhdGUgRlQyRm9u
dCBsaWtlOiBmb250ID0gRlQyRm9udChmaWxlbmFtZSkKPiAgICAgRWRpbj4gYW5kIHdoZW4gSSBj
YWxsIGl0J3MgbWV0aG9kIGZvbnQuc2V0X3RleHQoIlNvbWUgdGV4dCIpLCBhbmQKPiAgICAgRWRp
bj4gYWZ0ZXJ3YXJkcywgZm9udC5kcmF3X2dseXBoc190b19iaXRtYXAoKSwgdGhlIGxhdHRlciBz
aW1wbHkKPiAgICAgRWRpbj4gZGVsZXRlcyBldmVyeSBnbHlwaCB0aGF0IHdhcyBkcmF3biBiZWZv
cmUgaXQsIGFuZCBqdXN0Cj4gICAgIEVkaW4+IHBhaW50cyBpbiB0aGUgaW50ZXJuYWwgaW1hZ2Ug
YnVmZmVyIHRoZSB0ZXh0IHRoYXQgd2FzIHBhc3NlZAo+ICAgICBFZGluPiBvbiBsYXN0IGludm9j
YXRpb24gb2Ygc2V0X3RleHQgKG9yIGxvYWRfY2hhcikuCj4KPiBUaGlzIGlzIGEgZmVhdHVyZSwg
bm90IGEgYnVnIDotKSAgWW91IGNhbiBjbGVhciB0aGUgaW1hZ2UgYnVmZmVyIGlmCj4geW91IHdh
bnQgd2l0aCB0aGUgY2xlYXIgbWV0aG9kLCBhcyB3ZSBkbyBpbiB0aGUgbWF0aHRleHkgY29kZQo+
Cj4gICAgICAgICBmb3IgZm9udGZhY2UgaW4gc2VsZi5mb250cy52YWx1ZXMoKToKPiAgICAgICAg
ICAgICBmb250ZmFjZS5jbGVhcigpCj4KPiAgICAgRWRpbj4gVGhpcyBpcyBhIHBhaW4sIGJlY2F1
c2UgZHJhd19nbHlwaHNfdG9fYml0bWFwIGltcGxlbWVudHMgdGhlCj4gICAgIEVkaW4+IGxheW91
dCAod2l0aCBrZXJuaW5nIGV0Yy4pLCBidXQgaWYgb25lIHdhbnRzIHRvIHBhaW50Cj4gICAgIEVk
aW4+IHNldmVyYWwgd29yZHMgaW4gZGlmZmVyZW50IHgseSBwb3NpdGlvbnMgaW4gdGhlIHNhbWUg
aW1hZ2UKPiAgICAgRWRpbj4gYnVmZmVyLCBoZSBoYXMgdG8gZG8gdGhlIGxheW91dCBmb3IgZXZl
cnkgY2hhcmFjdGVyIGluIGV2ZXJ5Cj4gICAgIEVkaW4+IHdvcmQgbWFudWFsbHkgdmlhIGRyYXdf
Z2x5cGhfdG9fYml0bWFwKHgsIHksIGdseXBoKSAobGlrZQo+ICAgICBFZGluPiB5b3UgZGlkIHdp
dGggdGhlIEJhS29NYSBmb250cyBpbiBtYXRodGV4dCkuCj4KPiAgICAgRWRpbj4gV2h5IGhhc24n
dCBkcmF3X2dseXBoc190b19iaXRtYXAgYmVlbiBpbXBsZW1lbnRlZCBzbyB0aGF0IGl0Cj4gICAg
IEVkaW4+IHRha2VzIHgsIHkgYXMgYXJndW1lbnRzIChkcmF3X2dseXBoc190b19iaXRtYXAoeCwg
eSkpIGFuZAo+ICAgICBFZGluPiBsZWF2ZXMgdGhlIGltYWdlIGJ1ZmZlciBpbnRhY3QgKGFzIGRv
ZXMKPiAgICAgRWRpbj4gZHJhd19nbHlwaF90b19iaXRtYXApPwo+Cj4gWW91IGNhbiBhZGQgb3B0
aW9uYWwgeCBhbmQgeSBhcmdzIHRvIGRyYXdfZ2x5cGhzX3RvX2JpdG1hcCBpZiB5b3UgbmVlZAo+
IHRoZW0uICBKdXN0IG1ha2Ugc3VyZSBhbnkgY2hhbmdlcyB5b3UgbWFrZSBwYXNzCj4gZXhhbXBs
ZXMvYmFja2VuZF9kcml2ZXIucHkgYW5kIHVuaXQvbWVtbGVha19oYXdhaWkzLnB5Cj4KPiAgICAg
RWRpbj4gMikgQXMgSSBoYXZlIHNhaWQgYmVmb3JlLCBJIGhhdmUgc3RhcnRlZCB0aGUgY29tcGxl
dGUKPiAgICAgRWRpbj4gcmV3cml0ZSBvZiBtYXRodGV4dCAodGhlIHBhcnNpbmcgc3R1ZmYgZXRj
LikuIEkgaGF2ZQo+ICAgICBFZGluPiBjb21wbGV0ZWx5IHJlbW92ZWQgdGhlIGRlcGVuZGVuY3kg
b24gcHlwYXJzaW5nIChwbGVhc2UgZG9uJ3QKPiAgICAgRWRpbj4geWVsbCBhdCBtZSA6KSwgYW5k
IEkgd2FzIHdvbmRlcmluZyBhYm91dCBob3cgbXVjaCBvZiBUZVgKPgo+IE9LLCBJIHdvbid0IHll
bGwuICBRdWlldGx5IHNjb2xkIG1heWJlIDotKQo+Cj4gSSBhbSBza2VwdGljYWwgb2YgeW91ciAt
LSBvciBhbnlvbmUncyBleGNlcHQgUm9iZXJ0J3MgLS0gYWJpbGl0eSB0bwo+IHBhcnNlIFRlWCBt
YXRoZW1hdGljYWwgZXhwcmVzc2lvbnMgdy9vIGEgdHJ1ZSByZWN1cnNpdmUgZGVzY2VudAo+IHBh
cnNlci4gIEkgdG9vayBhIGxvb2sgYXQgeW91ciBjb2RlIGJ1dCB3L28gYW55IHJ1bm5pbmcgZXhh
bXBsZXMgSQo+IGNvdWxkIG5vdCB0ZXN0IGl0LiAgRnJvbSByZWFkaW5nIGl0LCBJIGRvIG5vdCB0
aGluayBpdCB3aWxsIGJlIGFibGUgdG8KPiBoYW5kbGUgdGhlIGRlZXBseSByZWN1cnNpdmUgc3Ry
dWN0dXJlcyB0aGF0IGFyZSBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5Cj4gdGhlIGV4aXN0aW5nLCB3
b3JraW5nIHBhcnNlci4gIENhbiB5b3UgaGFuZGxlIHJlY3Vyc2l2ZWx5IG5lc3RlZAo+IHN1cGVy
L3N1YiBzY3JpcHRzPyAgQ2FuIGl0IHBhcnNlIHRoaXMKPgo+ICAgdGV4ID0gcickXGNhbHtSfVxw
cm9kX3tpPVxhbHBoYV97aSsxfX1eXGluZnR5IGFfaVxybXtzaW59KDIgXHBpIGYgeF9pKSQnCj4K
Pgo+IElmIHNvLCBJIGFwb2xvZ2l6ZSBmb3IgbXkgc2tlcHRpY2lzbSwgYnV0IG15IHdvcmtpbmcg
YXNzdW1wdGlvbiBpcyB5b3UKPiB3aWxsIG5lZWQgYSBwcm9wZXIgcGFyc2VyIHRvIHBhcnNlIHRl
eCBhbmQgc3RyaW5nIG1ldGhvZHMgYXJlbid0IGdvaW5nCj4gdG8gZ2V0IHlvdSB0aGVyZS4gIFdo
YXQgSSByZWFsbHkgbmVlZCB0byBzZWUgYmVmb3JlIGV2ZW4gY29uc2lkZXJpbmcgYQo+IHN5c3Rl
bSB0aGF0IHJlcGxhY2VzIHRoZSB3b3JraW5nIHN5c3RlbSBpcyBhbiBhcmd1bWVudCBhYm91dCB3
aHkgaXQKPiBuZWVkcyB0byBiZSByZXBsYWNlZCwgYW5kIG1vcmUgaW1wb3J0YW50bHksIGNvZGUg
dGhhdCBjYW4gZG8KPiBldmVyeXRoaW5nIHRoZSBvbGQgY29kZSBjYW4gZG8sIHN1Y2ggYXMgcmVu
ZGVyIHRoZSBtYXRodGV4dF9kZW1vLnB5Cj4gZXhhbXBsZT8KPgo+ICAgICBFZGluPiBzaG91bGQg
bWF0aHRleHQgc3VwcG9ydC4gSSdtIG5vdCB0YWxraW5nIGFib3V0IHN1cHBvcnQgZm9yCj4gICAg
IEVkaW4+IFxmcmFjLCBcYWJvdmUsIFxjaG9vc2UgKHdoaWNoIEkgcGxhbiB0byBhZGQgb25lIGJ5
IG9uZSkKPiAgICAgRWRpbj4gZXRjLiwgYnV0IGFib3V0IG1vcmUgZ2VuZXJhbCB0aGluZ3MgLSBt
YWNyb3MgKFxkZWYgZXRjLikuIEkKPgo+IFxhYm92ZSwgXGZyYWMgYW5kIFxzcXJ0IHllcywgXGRl
ZiBuby4gIE90aGVycyBJJ20gbm90IHN1cmUgYWJvdXQuCj4KPiAgICAgRWRpbj4gd2FzIHRoaW5r
aW5nIG9mIGp1c3Qgc2ltdWxhdGluZyB0aGVtLCBhdCBsZWFzdCB0byBhCj4gICAgIEVkaW4+IHRv
bGVyYWJsZSBleHRlbnQsIHZpYSBub3Rpb24gb2YgYW4gZW52aXJvbWVudC4gIEV4YW1wbGU6IFxy
bQo+ICAgICBFZGluPiBpbiBwbGFpbiBUZVggc2V0cyB0aGUgY3VycmVudCBmb250IHRvIHJvbWFu
ICh1bnRpbCB0aGUgZW5kCj4gICAgIEVkaW4+IG9mIHRoZSBjdXJyZW50IHNjb3BlIC0gJ3RpbGwg
aXQgaGl0cyAifSIpLiAgSW1wbGVtZW50YXRpb246Cj4gICAgIEVkaW4+IEF0IHJlbmRlciB0aW1l
LCB3aGVuIHRoZSBwYXJzZXIgaGl0cyAiXHJtIiwgaXQgZG9lcyB0aGUKPiAgICAgRWRpbj4gZm9s
b3dpbmc6IGVudlsiZmFjZXR5cGUiXSA9ICJybSIsIHdoZXJlIGVudiBpcyB0aGUKPiAgICAgRWRp
bj4gZW52aXJvbm1lbnQgaW4gdGhlIGN1cnJlbnQgc2NvcGUuCj4KPiBDYW4gd2UgdXNlIGNsYXNz
ZXMgaGVyZSByYXRoZXIgdGhhbiBkaWN0aW9uYXJpZXM/ICBTeW50YWN0aWNhbGx5LCBJCj4gcHJl
ZmVyIGVudi5mYWNldHlwZSA9ICJybSIgdG8gdGhlIGRpY3Rpb25hcnkgc3ludGF4Lgo+Cj4gICAg
IEVkaW4+IEFsc28sIEkgYW0gcGxhbmluZyB0byBjcmVhdGUgYSBzZXBhcmF0ZSBjbGFzcyBmb3Ig
ZXZlcnkgbmV3Cj4gICAgIEVkaW4+IGxheW91dCBpdGVtIHRoYXQgZ2V0cyBpbXBsZW1lbnRlZC4g
IEV4YW1wbGU6Cj4gICAgIEVkaW4+IHN1Yi9zdXBlcnNjcmlwdGVkIGl0ZW0gKG51Y2xldXNfc3Vi
XnN1cCkgZ2V0cyB0cmFuc2xhdGVkIHRvCj4gICAgIEVkaW4+IGFuIGluc3RhbmNlIG9mIGNsYXNz
IFNjcmlwdGVkIHRoYXQgaGFzIHRoZSBhdHRyaWJ1dGVzCj4gICAgIEVkaW4+IG51Y2xldXMsIHN1
cGVyc2NyaXB0IGFuZCBzdWJzY3JpcHQuCj4KPiAgICAgRWRpbj4gMykgSSB3YXMgdGhpbmtpbmcg
b2YgZm9jdXNpbmcgb24ganVzdCB0aGUgQWdnIGJhY2tlbmQgZm9yCj4gICAgIEVkaW4+IG5vdyAo
dGhhdCBpcyB0aWxsJyB0aGUgZGVhZGxpbmUpLiBJcyB0aGlzIE9LPyAgNCkgSSB0aGluawo+ICAg
ICBFZGluPiB0aGF0IHdlIHNob3VsZCBtb3ZlIHRoZSBqb2Igb2YgbWF0aF9wYXJzZV9zX2Z0MmZv
bnQsCj4gICAgIEVkaW4+IG1hdGhfcGFyc2Vfc19mdDJmb250X3N2ZywgYW5kIG1hdGhfcGFyc2Vf
c19wcyBldGMuICB0byB0aGUKPiAgICAgRWRpbj4gY29ycmVzcG9uZGluZyBiYWNrZW5kcywgYW5k
IHRoYXQgc29tZSBnZW5lcmFsIGZ1bmN0aW9uIGxpa2U6Cj4gICAgIEVkaW4+IG1hdGhfcGFyc2Vf
cyh4LCB5LCBzLCBwcm9wLCBhbmdsZSkgc2hvdWxkIGJlIGltcGxlbWVudGVkCj4gICAgIEVkaW4+
IGRpcmVjdGx5IGluIG1hdGh0ZXh0LnB5IChwZXJoYXBzIGV2ZW4gd2l0aG91dCB0aGUgImFuZ2xl
Igo+ICAgICBFZGluPiBwYXJhbWV0ZXIpIHNvIHRoYXQgaXQgcmV0dXJucyBhIGxpc3Qgb2YgdGhl
IGZvbGxvd2luZyB0eXBlOgo+ICAgICBFZGluPiBbKHgxLCB5MSwgczEsIHByb3AxLCBhbmdsZTEp
LCAuLi4gLCAoeG4sIHluLCBzbiwgcHJvcG4sCj4gICAgIEVkaW4+IGFuZ2xlbildCj4KPiBJIGNh
bid0IGFkZHJlc3MgdGhlc2UgcXVlc3Rpb25zIHVudGlsIEkgdW5kZXJzdGFuZCB3aHkgeW91IGFy
ZSB0cnlpbmcKPiB0byByZXdyaXRlLCByYXRoZXIgdGhhbiBleHRlbmQgb3IgZml4LCB0aGUgZXhp
c3RpbmcgY29kZS4gIFRoZSBhZ2cgYW5kCj4gdGhlIHBvc3RzY3JpcHQgYmFja2VuZHMgd29yayB3
aXRoIHRoZSBleGlzdGluZyBmcmFtZW93b3JrLiAgQXMgZmFyIGFzCj4gSSBjYW4gc2VlLCB5b3Ug
Y291bGQgZml4IHRoZSBsYXlvdXQgZW5naW5lIGluIHRoZSBleGlzdGluZyBmcmFtZXdvcmsKPiBh
bmQgbm90IGhhdmUgdG8gdGhpbmsgdG9vIG11Y2ggYWJvdXQgYmFja2VuZHMsIHdpdGggdGhlIGV4
Y2VwdGlvbiB0aGF0Cj4geW91IG5lZWQgYSBiYXNpYyBiYWNrZW5kIGxpbmUgZHJhd2luZyBBUEkg
Zm9yIHRoaW5ncyBsaWtlIHRoZQo+IGhvcml6b250YWwgbGluZSBpbiBcZnJhYy4KPgo+ICAgICBF
ZGluPiA1KSBXaGF0IHdvdWxkIGJlIHRoZSBjb25zZXF1ZW5jZXMgb2YgZGlzdHJpYnV0aW5nIGEg
R1BMIGZvbnQKPiAgICAgRWRpbj4gKEZyZWVGb250KSB3aXRoIG1hdHBsb3RsaWIuIEkgbWVhbiwg
aXQncyBub3QgdGhhdCB1c2luZyBhCj4gICAgIEVkaW4+IEdQTCBmb250IGluIHNvbWUgbm9uLUdQ
TCBhcHAgY291bGQgYmUgYSBicmVhY2ggb2YgdGhlCj4gICAgIEVkaW4+IEdQTC4gSXMgdGhlcmUg
YW55IGludGVyZXN0IGluIHRoaXM/Cj4KPiBEb24ndCB1bmRlcmVzdGltYXRlIHRoZSB6ZWFsb3Vz
bmVzcyBvZiBHUEwgYWR2b2NhdGVzLiAgSSBoYXZlIGJlZW4KPiBpbmZvcm1lZCBieSB0aGUgRlNG
IHRoYXQgbWVyZWx5IHByb3ZpZGluZyBhIGJhY2tlbmQgdGhhdCBkb2VzCj4KPiBpbXBvcnQgcXQK
Pgo+IGluIGEgYmFja2VuZCB0aGF0IGlzIG9wdGlvbmFsbHkgaW5jbHVkZWQgYXQgcnVudGltZSBi
eSBhIHVzZXIgd2hvIG1heQo+IGJlIHVzaW5nIGEgR1BMIHZlcnNpb24gb2YgUVQgb3IgbWF5IGJl
IHVzaW5nIGEgY29tbWVyY2lhbGx5IGxpY2Vuc2VkCj4gdmVyc2lvbiBvZiBxdCAod2UgY2FuJ3Qg
a25vdyB3aGljaCkgbWFrZXMgdGhlIGVudGlyZSBjb2RlIGJhc2Ugb2YgbXBsCj4gR1BMJ2QuICBU
aGlzIGNsYWltIHdhcyBwcm92aWRlZCB3L28gYXJndW1lbnQgYW5kIEkgZnJhbmtseSBmaW5kIGl0
Cj4gbHVkaWNyb3VzLiAgUm9iZXJ0IGNhbiBwcm9iYWJseSB0ZWxsIHlvdSB0aGUgSUFOQUwgcmVz
cG9uc2UgdG8KPiBpbmNsdWRpbmcgR1BMJ2QgZm9udHMgYnV0IEknbSBub3QgdG9vIGludGVyZXN0
ZWQgaW4gZGlzdHJpYnV0aW5nIHRoZW0uCj4gV2UgY2FuIGFsd2F5cyBwb2ludCB0aGUgdXNlciB0
byBhIHdlYiBzaXRlIGFuZCB0aGV5IGNhbiBkb3dubG9hZCB0aGVtCj4gZnJvbS4KPgo+ICAgICBF
ZGluPiBUaGUgbmV3IG1hdGh0ZXh0LnB5IGlzIGF0dGFjaGVkLiBQbGVhc2UgZG8gbm90IHRyeSBp
dCBhdAo+ICAgICBFZGluPiBob21lIDspIGJlY2F1c2Ugbm90aGluZyB2aXNpYmxlIHlldCB3b3Jr
cy4KPgo+IE9LLgo+Cj4gSkRICj4K

The SoC deadline (for code) is tommorow (Aug 21st.), so I decided to commit
what I have done till now to the repository.

JDH is going on a vacation and will not be able to review it for at
least a week,
but I had to commit it before 21st. Aug - that's the SoC rules. Hopefully,
I'll be adding new stuff the next week (and after), but that doesn't
count as part of SoC anymore...

Since this is my first commit, can anyone please test it. I tested it
only on my windows box.

I changed
__init__.py,
mathtext.py
CHANGELOG

I added
mathtext2.py
mathtext2_demo.py

Anyone who wants to test the new mathtext2 has to add the following line(s)
to the matplotlibrc (mathtext2 is disabled by default):

mathtext2:   True            # Needed to enable the new mathtext

# Font lines, feel free to change or uncomment (BaKoMa is used by default)
mathtext.rm     :   FreeSerif.ttf
mathtext.it     :   FreeSerifItalic.ttf     # Text italic
mathtext.tt     :   FreeMono.ttf    # Typewriter (monospaced)
mathtext.mit    :   FreeSerifItalic.ttf     # Math italic
mathtext.cal    :   FreeSansOblique.ttf # Caligraphic
mathtext.nonascii:  FreeSerif.ttf # Used for \sum, \infty etc.

The FreeFont fonts (or any other for that matter) have to be downloaded and put
into the mpl-data dir. The default settingsuse the current bakoma
fonts, and they play pretty well with FreeSerif.ttf as the nonascii
(unicode) font.

so I recommend you just put the line
mathtext.nonascii:  FreeSerif.ttf

and comment out the rest (experiment a little with fonts).

Tonight I plan to add support for fractions. Beware that the only
supported backend for now is Agg.

mathtext2_demo.py is attached

As a probably final installment in the thread about optimizing the wx 
back-end, here is a post from the wxPython list, in which someone posted 
SWIG code for making a PyBuffer from his data set, then using it to 
create a wx.Image without copying. A similar approach could be used for 
the wxAgg back-end.

-Chris

-------- Original Message --------
Subject: [wxPython-users]  Re: using wxImage in C++ python extension
Date: Fri, 18 Aug 2006 16:48:08 +0000 (UTC)
From: Andrew Murray <and...@st...>
Reply-To: wxP...@li...
To: wxp...@li...
References: <200...@uc...> 
<44E...@al...> <200...@uc...> 
<44E...@no...> <44E...@al...> 
<44E...@no...>

Hi all :)

I've followed the combined advice of Robin and Christopher in using a python
buffer object to instance a wx.Image in the python wrapper layer.  It 
all seems
to be working - and I don't think there are any 'data copies' going on ;)

To keep my underlying C++ python-free, I introduced the buffer (and 
creation of
the wx.Image) via my .i Swig file.  In case anyone who is reading is 
keen trying
to solve a similar problem, I've included the code that I added to my .i 
file in
order to implement the change below. (I'd appreciate any comments regarding
errors or shortcomings that anyone spots in my implementation.)

Sorry I didn't reply to the thread earlier.  A combination of being tied 
up with
more boring work, moving house and background research into using python 
buffers
with Swig means that I've only just got this far.

One remaining question I have is: Does the call to wx.EmptyImage that I make
cause any memory to be allocated?  I see from Robin's recent post that in my
case this call is now redundant (as I will soon be using 
ImageFromBuffer) - but
I'm curious to know the answer anyway ;)

Thanks for all the help.  The more I use wxPython the more I like it...

Andrew ;)


/* the RawImage C++ class that we are wrapping offers a method that
    returns a pointer to an internal 'unsigned char' buffer of display
    data.  To make the python class generated by SWIG a bit more
    friendly to the rest of our wxPython code we instruct SWIG to make
    two modifications during the wrapping process.  First we add a
    method to the C++ class that will return a version of the internal
    display buffer wrapped up as a 'python buffer object' (performing
    this in the C++ wrapper class keeps the wrapped C++ python-free)...
  */
%extend RawImage {
	PyObject* RawImage::getDisplayBuffer(void) {
		// return a new 'python buffer object' that intialised using
		// the memory address and length of our display buffer...
		void* pvBufferData = (void*)self->pcGetDisplayData();
		int iBufferSize = self->getDisplayBufferSize();
		return PyBuffer_FromMemory(pvBufferData, iBufferSize);
	}
}
/* ... we also add a method to the python wrapper class that will use
    the buffer offered by our new C++ method to create a wx.Image
    (neither of these methods actually copies the image data)...
  */
%extend RawImage {
%pythoncode %{
def getImage(self):
     # create an unintialised wx.Image of the correct size...
     wximage = wx.EmptyImage(self.getWidth(), self.getHeight(), clear=False)
     # then define the data content of the image...
     wximage.SetDataBuffer(self.getDisplayBuffer())
     return wximage
%}
}


---------------------------------------------------------------------
To unsubscribe, e-mail: wxP...@li...
For additional commands, e-mail: wxP...@li...


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:

    Edin> Hi all, Please John, take some time before SciPy conf to
    Edin> answer at least some of this questions, because the SoC
    Edin> deadline (21st August) is *very* near.

Alas, I am already here and have been a little out of email contact
while traveling.  Sorry for the delay.

    Edin> 1) I'm having some problems regarding FT2Font.  The problem
    Edin> is when I instantiate FT2Font like: font =3D FT2Font(filename)
    Edin> and when I call it's method font.set_text("Some text"), and
    Edin> afterwards, font.draw_glyphs_to_bitmap(), the latter simply
    Edin> deletes every glyph that was drawn before it, and just
    Edin> paints in the internal image buffer the text that was passed
    Edin> on last invocation of set_text (or load_char).

This is a feature, not a bug :-)  You can clear the image buffer if
you want with the clear method, as we do in the mathtexy code

        for fontface in self.fonts.values():
            fontface.clear()

    Edin> This is a pain, because draw_glyphs_to_bitmap implements the
    Edin> layout (with kerning etc.), but if one wants to paint
    Edin> several words in different x,y positions in the same image
    Edin> buffer, he has to do the layout for every character in every
    Edin> word manually via draw_glyph_to_bitmap(x, y, glyph) (like
    Edin> you did with the BaKoMa fonts in mathtext).

    Edin> Why hasn't draw_glyphs_to_bitmap been implemented so that it
    Edin> takes x, y as arguments (draw_glyphs_to_bitmap(x, y)) and
    Edin> leaves the image buffer intact (as does
    Edin> draw_glyph_to_bitmap)?

You can add optional x and y args to draw_glyphs_to_bitmap if you need
them.  Just make sure any changes you make pass
examples/backend_driver.py and unit/memleak_hawaii3.py

    Edin> 2) As I have said before, I have started the complete
    Edin> rewrite of mathtext (the parsing stuff etc.). I have
    Edin> completely removed the dependency on pyparsing (please don't
    Edin> yell at me :), and I was wondering about how much of TeX

OK, I won't yell.  Quietly scold maybe :-)

I am skeptical of your -- or anyone's except Robert's -- ability to
parse TeX mathematical expressions w/o a true recursive descent
parser.  I took a look at your code but w/o any running examples I
could not test it.  From reading it, I do not think it will be able to
handle the deeply recursive structures that are currently supported by
the existing, working parser.  Can you handle recursively nested
super/sub scripts?  Can it parse this

  tex =3D r'$\cal{R}\prod_{i=3D\alpha_{i+1}}^\infty a_i\rm{sin}(2 \pi f x=
_i)$'


If so, I apologize for my skepticism, but my working assumption is you
will need a proper parser to parse tex and string methods aren't going
to get you there.  What I really need to see before even considering a
system that replaces the working system is an argument about why it
needs to be replaced, and more importantly, code that can do
everything the old code can do, such as render the mathtext_demo.py
example? =20

    Edin> should mathtext support. I'm not talking about support for
    Edin> \frac, \above, \choose (which I plan to add one by one)
    Edin> etc., but about more general things - macros (\def etc.). I

\above, \frac and \sqrt yes, \def no.  Others I'm not sure about. =20

    Edin> was thinking of just simulating them, at least to a
    Edin> tolerable extent, via notion of an enviroment.  Example: \rm
    Edin> in plain TeX sets the current font to roman (until the end
    Edin> of the current scope - 'till it hits "}").  Implementation:
    Edin> At render time, when the parser hits "\rm", it does the
    Edin> folowing: env["facetype"] =3D "rm", where env is the
    Edin> environment in the current scope.

Can we use classes here rather than dictionaries?  Syntactically, I
prefer env.facetype =3D "rm" to the dictionary syntax.

    Edin> Also, I am planing to create a separate class for every new
    Edin> layout item that gets implemented.  Example:
    Edin> sub/superscripted item (nucleus_sub^sup) gets translated to
    Edin> an instance of class Scripted that has the attributes
    Edin> nucleus, superscript and subscript.

    Edin> 3) I was thinking of focusing on just the Agg backend for
    Edin> now (that is till' the deadline). Is this OK?  4) I think
    Edin> that we should move the job of math_parse_s_ft2font,
    Edin> math_parse_s_ft2font_svg, and math_parse_s_ps etc.  to the
    Edin> corresponding backends, and that some general function like:
    Edin> math_parse_s(x, y, s, prop, angle) should be implemented
    Edin> directly in mathtext.py (perhaps even without the "angle"
    Edin> parameter) so that it returns a list of the following type:
    Edin> [(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn,
    Edin> anglen)]

I can't address these questions until I understand why you are trying
to rewrite, rather than extend or fix, the existing code.  The agg and
the postscript backends work with the existing frameowork.  As far as
I can see, you could fix the layout engine in the existing framework
and not have to think too much about backends, with the exception that
you need a basic backend line drawing API for things like the
horizontal line in \frac.

    Edin> 5) What would be the consequences of distributing a GPL font
    Edin> (FreeFont) with matplotlib. I mean, it's not that using a
    Edin> GPL font in some non-GPL app could be a breach of the
    Edin> GPL. Is there any interest in this?

Don't underestimate the zealousness of GPL advocates.  I have been
informed by the FSF that merely providing a backend that does=20

import qt

in a backend that is optionally included at runtime by a user who may
be using a GPL version of QT or may be using a commercially licensed
version of qt (we can't know which) makes the entire code base of mpl
GPL'd.  This claim was provided w/o argument and I frankly find it
ludicrous.  Robert can probably tell you the IANAL response to
including GPL'd fonts but I'm not too interested in distributing them.
We can always point the user to a web site and they can download them
from.

    Edin> The new mathtext.py is attached. Please do not try it at
    Edin> home ;) because nothing visible yet works.

OK.

JDH

Charlie Moad wrote:
> I'll paste the block of interest to save
> you a little digging.
> 
>            bbox = self.replot
>            w, h = int(bbox.width()), int(bbox.height())
>            l, t = bbox.ll().x().get(), bbox.ur().y().get()
>            reg = self.copy_from_bbox(bbox)

So this is one copy.
>            stringBuffer = reg.to_string()

Is this another? or does to_string not copy?

>            qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
> qt.QImage.IgnoreEndian)

Here we have difference from wx -- AFAICT, a wx.Image doesn't do rgba32, 
it does RGB24, with a separate 8bit alpha channel. if to_string copies 
anyway, then that wouldn't make much difference.

But do we really need alpha here anyway?

>            self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
>            p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)

And this looks like wx.

I wish I had more time to work on this, but I'm in a crunch that I'll be 
in for while....

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                      		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Darren Dale wrote:
> I think all the high rollers are at SciPy 2006.

Oh right. This is the third year in a row that I have ALMOST gone 
myself. Maybe next year.

But what's the deal? Aren't they all hooked up to wifi and checking 
email constantly?

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                      		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On 8/17/06, Christopher Barker <Chr...@no...> wrote:
> Hi all,
>
> I seem to be talking to myself here, but if someone (including myself)
> wants to pick this up in the future, it'll be good to have it in the
> archives.
>
> Christopher Barker wrote:
> >> There is also the
> >> wx.Image.SetDataBuffer method, which will have the wxImage use the
> >> buffer passed in without making a copy, but if the buffer doesn't
> >> live as long as the image does it will likely cause a crash.
> >
> > This would probably be the easiest way to get top performance at the
> > moment. If we can make the Agg data a buffer, and somehow do the
> > reference counting right so it doesn't get deleted while the wxImage is
> > still around (that may not be hard -- the wxImage has to be converted to
> > a wxBitmap to be drawn anyway)
>
> I've been suing this for another use, and Robin just added an improved
> version of new wx.Image factory function I wrote for just this purpose:
>
> def ImageFromBuffer(width, height, dataBuffer, alphaBuffer=None):
>      """
>      Creates a `wx.Image` from the data in dataBuffer.  The dataBuffer
>      parameter must be a Python object that implements the buffer
>      interface, such as a string, array, etc.  The dataBuffer object is
>      expected to contain a series of RGB bytes and be width*height*3
>      bytes long.  A buffer object can optionally be supplied for the
>      image's alpha channel data, and it is expected to be width*height
>      bytes long.
>
>      A reference to the data and alpha buffer objects are kept with the
>      wx.Image, so that they won't get deleted until after the wx.Image
>      is deleted.  However please be aware that it is not guaranteed that
>      an object won't move its memory buffer to a new location when it
>      needs to resize its contents.  If that happens then the wx.Image
>      will end up referring to an invalid memory location and could cause
>      the application to crash.  Therefore care should be taken to not
>      manipulate the objects used for the data and alpha buffers in a
>      way that would cause them to change size.
>      """
>      image = wx.EmptyImage(width, height)
>      image.SetDataBuffer(dataBuffer)
>      if alphaBuffer is not None:
>          image.SetAlphaBuffer(alphaBuffer)
>      image._buffer = dataBuffer
>      image._alpha = alphaBuffer
>      return image
>
> Does the aggDrawer already implement a Python buffer object? If so,
> using this would be easy. If not, then it probably should, unless we go
> straight to the numpy array protocol.

I haven't had time to thoroughly absorb all your post.  From skimming
it looks like we could do a similar approach as the qtagg blitting.
If you look at the else clause in the FigureCanvasQTAgg.paintEvent
method, you'll see we added a to_string method to the BufferRegion
object.  Using this string buffer we create a QImage and blit it.  It
includes the alpha channel.  I'll paste the block of interest to save
you a little digging.

            bbox = self.replot
            w, h = int(bbox.width()), int(bbox.height())
            l, t = bbox.ll().x().get(), bbox.ur().y().get()
            reg = self.copy_from_bbox(bbox)
            stringBuffer = reg.to_string()
            qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
qt.QImage.IgnoreEndian)
            self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
            p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)

- Charlie

On Thursday 17 August 2006 7:19 pm, Christopher Barker wrote:
> I seem to be talking to myself here

I think all the high rollers are at SciPy 2006.

Hi all,

I seem to be talking to myself here, but if someone (including myself) 
wants to pick this up in the future, it'll be good to have it in the 
archives.

Christopher Barker wrote:
>> There is also the
>> wx.Image.SetDataBuffer method, which will have the wxImage use the
>> buffer passed in without making a copy, but if the buffer doesn't
>> live as long as the image does it will likely cause a crash.
> 
> This would probably be the easiest way to get top performance at the 
> moment. If we can make the Agg data a buffer, and somehow do the 
> reference counting right so it doesn't get deleted while the wxImage is 
> still around (that may not be hard -- the wxImage has to be converted to 
> a wxBitmap to be drawn anyway)

I've been suing this for another use, and Robin just added an improved 
version of new wx.Image factory function I wrote for just this purpose:

def ImageFromBuffer(width, height, dataBuffer, alphaBuffer=None):
     """
     Creates a `wx.Image` from the data in dataBuffer.  The dataBuffer
     parameter must be a Python object that implements the buffer
     interface, such as a string, array, etc.  The dataBuffer object is
     expected to contain a series of RGB bytes and be width*height*3
     bytes long.  A buffer object can optionally be supplied for the
     image's alpha channel data, and it is expected to be width*height
     bytes long.

     A reference to the data and alpha buffer objects are kept with the
     wx.Image, so that they won't get deleted until after the wx.Image
     is deleted.  However please be aware that it is not guaranteed that
     an object won't move its memory buffer to a new location when it
     needs to resize its contents.  If that happens then the wx.Image
     will end up referring to an invalid memory location and could cause
     the application to crash.  Therefore care should be taken to not
     manipulate the objects used for the data and alpha buffers in a
     way that would cause them to change size.
     """
     image = wx.EmptyImage(width, height)
     image.SetDataBuffer(dataBuffer)
     if alphaBuffer is not None:
         image.SetAlphaBuffer(alphaBuffer)
     image._buffer = dataBuffer
     image._alpha = alphaBuffer
     return image

Does the aggDrawer already implement a Python buffer object? If so, 
using this would be easy. If not, then it probably should, unless we go 
straight to the numpy array protocol.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi all,

Please John, take some time before SciPy conf to answer at least some of
this questions, because the SoC deadline (21st August) is *very* near.

1) I'm having some problems regarding FT2Font.
The problem is when I instantiate FT2Font like:
font = FT2Font(filename)
and when I call it's method font.set_text("Some text"), and afterwards,
font.draw_glyphs_to_bitmap(), the latter simply deletes every glyph that
was drawn before it, and just paints in the internal image buffer the
text that was passed on last invocation of set_text (or load_char).

This is a pain, because draw_glyphs_to_bitmap implements the layout
(with kerning etc.), but if one wants to paint several words in different
x,y positions in the same image buffer, he has to do the layout for every
character in every word manually via draw_glyph_to_bitmap(x, y, glyph)
(like you did with the BaKoMa fonts in mathtext).

Why hasn't draw_glyphs_to_bitmap been implemented so that it takes x, y as
arguments (draw_glyphs_to_bitmap(x, y)) and leaves the image
buffer intact (as does draw_glyph_to_bitmap)?

2) As I have said before, I have started the complete rewrite of mathtext
(the parsing stuff etc.). I have completely removed the dependency on
pyparsing (please don't yell at me :), and I was wondering about how much
of TeX should mathtext support. I'm not talking about support for \frac,
\above, \choose (which I plan to add one by one) etc., but about more
general things - macros (\def etc.). I was thinking of just simulating
them, at least to a tolerable extent, via notion of an enviroment.
Example:
\rm in plain TeX sets the current font to roman (until the end of the
current scope - 'till it hits "}").
Implementation:
At render time, when the parser hits "\rm", it does the folowing:
env["facetype"] = "rm", where env is the environment in the current scope.

Also, I am planing to create a separate class for every new layout item
that gets implemented.
Example: sub/superscripted item (nucleus_sub^sup) gets translated to an
instance of class Scripted that has the attributes nucleus, superscript
and subscript.

3) I was thinking of focusing on just the Agg backend for now (that is
till' the deadline). Is this OK?
4) I think that we should move the job of
math_parse_s_ft2font, math_parse_s_ft2font_svg, and math_parse_s_ps etc.
to the corresponding backends, and that some general function like:
    math_parse_s(x, y, s, prop, angle)
should be implemented directly in mathtext.py (perhaps even without the
"angle" parameter) so that it returns a list of the following type:
[(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn, anglen)]

Then the backend should call draw_text for every item in the list.
Something like
    def draw_mathtext(self, gc, x, y, s, prop, angle):
        items = math_parse_s(x, y, s, prop, angle)
        for item in items:
            draw_text(*items)

instead of current:
    def draw_mathtext(self, gc, x, y, s, prop, angle):
        """
        Draw the math text using matplotlib.mathtext
        """
        if __debug__: verbose.report('RendererAgg.draw_mathtext',
                                     'debug-annoying')
        size = prop.get_size_in_points()
        width, height, fonts = math_parse_s_ft2font(
            s, self.dpi.get(), size, angle)

        if angle == 90:
            width, height = height, width
        for font in fonts:
            if angle == 90:
                font.horiz_image_to_vert_image() # <-- Rotate
                self._renderer.draw_text( font, int(x)-width, int(y)-height, gc)
            else:
                self._renderer.draw_text( font, int(x), int(y)-height, gc)
        if 0:
            self._renderer.draw_rectangle(gc, None,
                                          int(x),
                                          self.height-int(y),
                                          width, height)

Is this possible? I'm aware of overseeing the dpi and fontsize arguments,
but I don't think that this is much of an issue.

5) What would be the consequences of distributing a GPL font (FreeFont)
with matplotlib. I mean, it's not that using a GPL font in some non-GPL
app could be a breach of the GPL. Is there any interest in this?

The new mathtext.py is attached. Please do not try it at home ;)
because nothing visible yet works.

Cheers,
Edin

On Tuesday 15 August 2006 12:32, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> When I run the following: figure(); plot([1,2]) figure();
>     Darren> plot([1,2])
>
>     Darren> and then I use the zoom widget in one figure, and then try
>     Darren> to use the zoom widget in the other figure without turning
>     Darren> off the first zoom widget, I get an error. Is this
>     Darren> desirable?
>
> Hi Darren -- I just modified the code to use per canvas widget
> locking.  Now every FigureCanvas has a widgetlock attr.
> Unfortunately, I cannot adequately test right now because I am working
> over X11 and the interactive widget stuff like examples/lasso_demo.py
> is too slow.  Could you try that demo, as well as multiple figures
> with pan/zoom and make sure you don't see any strangness?

Looks good to me, no problems to report.

I moved this to the devel list -- that seemed more appropriate.

Stefan van der Walt wrote:
> On Mon, Aug 14, 2006 at 11:12:29AM -0700, Christopher Barker wrote:
>> Another (or additional) option is for both MPL and wx to support
>> the new array interface protocol in numpy.

>> Travis posted a patch to PIL for support a while back, I don't know
>> if it's going to get applied or not, but it's worth looking at.
> 
> Looks like it has been added already.

Very cool. Now we just need MPL and wx to support it...

In the meantime, this note from Robin Dunn on the wxpython-users list:

> wx.Image.SetData makes a copy and gives ownership of the copy to the
> image.  This allows it to work even when the source buffer doesn't
> live as long as the image does.

This is probably how the original wx back-end worked.

> There is also the
> wx.Image.SetDataBuffer method, which will have the wxImage use the
> buffer passed in without making a copy, but if the buffer doesn't
> live as long as the image does it will likely cause a crash.

This would probably be the easiest way to get top performance at the 
moment. If we can make the Agg data a buffer, and somehow do the 
reference counting right so it doesn't get deleted while the wxImage is 
still around (that may not be hard -- the wxImage has to be converted to 
a wxBitmap to be drawn anyway)

Another issue is the data layout of the Agg buffer: is it RGB or RGBA 
(or something else?) wxImage requires 24bit RGB. It can support an alpha 
channel, but as far as I can tell, the alpha data is stored in a 
separate array, rather than as an RGBA array.

I'm poking into the code a bit now, and see:

def _py_convert_agg_to_wx_image(agg, bbox):

     image = wx.EmptyImage(int(agg.width), int(agg.height))
     image.SetData(agg.tostring_rgb())

We might be able to just change that to:
image.SetDataBuffer(agg.tostring_rgb())

Does the agg.tostring_rgb() call make a copy?

If so, then maybe a agg.Getbuffer() method is in order.

Also, if it does, then that string will get garbage collected right 
away, and delete the memory buffer. We'd need to keep that around 
somehow. maybe a subclass of wx.Image that holds a reference to the 
string. Then they'll both get deleted when the wx.Image is deleted..

I also took a look at:

def _clipped_image_as_bitmap(

This is way too ugly!

1) maybe it would be a good idea to have a:

agg.subImageToString_rgb(x,y,w,h)

This must be used in all the back-ends

2) If you do need to do the sub-sampling with wx code, I think you could do:

def _clipped_image_as_bitmap(image, bbox):
     """
     Convert the region of a wx.Image described by bbox to a wx.Bitmap.
     """
     l, b, width, height = bbox.get_bounds()
     r = l + width
     t = b + height

     subImage = image.GetSubImage( wx.Rect( (l,b),(width,height) ) )
     destBmp = wx.BitmapFromImage(subImage)

     return destBmp

Much simpler (and probably faster)

3) Another option would be to use numpy arrays to pass this kind of data 
around. We could then use numpy to sub-sample the image. MPL depends on 
numpy anyway, so it's not an added dependency. That may have to wait 
until the 'grand unification" is complete, and we can drop support for 
Numeric and numarray.

Sorry I don't have time to build and test this code right now.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> When I run the following: figure(); plot([1,2]) figure();
    Darren> plot([1,2])

    Darren> and then I use the zoom widget in one figure, and then try
    Darren> to use the zoom widget in the other figure without turning
    Darren> off the first zoom widget, I get an error. Is this
    Darren> desirable?

Hi Darren -- I just modified the code to use per canvas widget
locking.  Now every FigureCanvas has a widgetlock attr.
Unfortunately, I cannot adequately test right now because I am working
over X11 and the interactive widget stuff like examples/lasso_demo.py
is too slow.  Could you try that demo, as well as multiple figures
with pan/zoom and make sure you don't see any strangness?

Thanks,
JDH

>>>>> "Asheesh" == Asheesh Laroia <as...@as...> writes:

    Asheesh> On Mon, 14 Aug 2006, John Hunter wrote:
    >> Hey Asheesh -- sorry we missed this the first time.  I just
    >> tried to apply it but the patch didn't go through because of
    >> the dir naming conventions you are using on your system. Could
    >> you try to get an svn co, apply your patch, and then submit an
    >> 'svn diff' ?

    Asheesh> That's attached.  Also, try using "patch -p1" next
    Asheesh> time. (-;

OK, it's in -- thanks!

JDH

On Mon, 14 Aug 2006, John Hunter wrote:

> Hey Asheesh -- sorry we missed this the first time.  I just tried to 
> apply it but the patch didn't go through because of the dir naming 
> conventions you are using on your system. Could you try to get an svn 
> co, apply your patch, and then submit an 'svn diff' ?

That's attached.  Also, try using "patch -p1" next time. (-;

I license this under the same terms at matplotlib is currently publicly 
distributed.

-- Asheesh.

-- 
Your boyfriend takes chocolate from strangers.

>>>>> "Asheesh" == Asheesh Laroia <as...@as...> writes:

    Asheesh> This patch does not change default behavior but provides
    Asheesh> a useful feature enhancement that we use at Creative
    Asheesh> Commons.  It would be great if you, our humble upstream,
    Asheesh> would accept it in the new point release.  Would you?

    Asheesh> Thanks!  I'm subscribed to matplotlib-devel and welcome
    Asheesh> comments.  I've re-attached the patch in the case that it
    Asheesh> got lost.

Hey Asheesh -- sorry we missed this the first time.  I just tried to
apply it but the patch didn't go through because of the dir naming
conventions you are using on your system. Could you try to get an svn
co, apply your patch, and then submit an 'svn diff' ?

Thanks!
JDH

Hi Asheesh,

It looks like your first email got overlooked. Sorry about that. Would you 
also post a bug report at the sourceforge webpage? I'll look at your patch 
when I get a chance.

Darren


On Monday 14 August 2006 8:17 pm, Asheesh Laroia wrote:
> On Tue, 18 Jul 2006, Asheesh Laroia wrote:
> > For pie charts, autopct lets a format string with the pie's value be
> > printed on the chart.  The default fraction of the radius that the text
> > is printed at is 0.6; I wanted the text farther out at 0.85.
> >
> > This small patch (against matplotlib 0.87.4) allows one to customize that
> > radius by a new keyword argument, pctradius.  The old behavior is still
> > the default.
>
> This patch does not change default behavior but provides a useful feature
> enhancement that we use at Creative Commons.  It would be great if you,
> our humble upstream, would accept it in the new point release.  Would you?
>
> Thanks!  I'm subscribed to matplotlib-devel and welcome comments.  I've
> re-attached the patch in the case that it got lost.
>
> -- Asheesh.

-- 
Darren S. Dale, Ph.D.
dd...@co...

On Tue, 18 Jul 2006, Asheesh Laroia wrote:

> For pie charts, autopct lets a format string with the pie's value be printed 
> on the chart.  The default fraction of the radius that the text is printed at 
> is 0.6; I wanted the text farther out at 0.85.
>
> This small patch (against matplotlib 0.87.4) allows one to customize that 
> radius by a new keyword argument, pctradius.  The old behavior is still the 
> default.

This patch does not change default behavior but provides a useful feature 
enhancement that we use at Creative Commons.  It would be great if you, 
our humble upstream, would accept it in the new point release.  Would you?

Thanks!  I'm subscribed to matplotlib-devel and welcome comments.  I've 
re-attached the patch in the case that it got lost.

-- Asheesh.

-- 
You are a bundle of energy, always on the go.

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Numpy 1.0b2 was released last night and Travis hopes this
    Charlie> will remain binary compatible with numpy 1.0.  Are there
    Charlie> any objections to a minor release bump?  I could do this
    Charlie> an soon as tomorrow.

Let's shoot for Tuesday evening, in advance of scipy.  I'm going to
make one more attempt before then to get the damned widget lock
working right....

JDH

Numpy 1.0b2 was released last night and Travis hopes this will remain
binary compatible with numpy 1.0.  Are there any objections to a minor
release bump?  I could do this an soon as tomorrow.

- Charlie

Hi,

I am using matplotlib 87.4 and I encountered a problem with fill. The outlines
of the filled region look weird when using the TkAgg backend. Same applies when
saved to a png file, so this seems to be a problem of all *Agg backends. The PS
backend is fine. Here is a somewhat longer example, that shows this behaviour.
For comparison, drawing the same outlines with plot gives a perfectly smooth
result.


from pylab import *
clf()
x = linspace(0,1, 100)
y1 = x**2
y2 = 1.03*y1
xx = concatenate((x, x[::-1]))
yy = concatenate((y1, y2[::-1]))
fillh = fill(xx, yy, ec = 'k', lw = 0.4)
fillh = fillh[0]
fillh.set_fill(False)
ph = plot(x, y1+0.1, 'k-',
     x, y2+0.1, 'k-', lw = 0.4)
savefig('jaggyfill.png', dpi = 150)
savefig('jaggyfill.eps')
show()

The more points I use, the worse the result. I create a png file since I need
alpha filling, eps doesn't support this. Creating a high resolution png and
downscaling improves the result, but this is tedious and time consuming. Any
help is appreciated!

Thanks in advance

Gregor Thalhammer

PS. Is this the right place to discuss such problems?

Hi folks,

I recently required a multi-column legend for a matplotlib graph. I
hacked up the Legend class to support this. I figured this might be
useful to others, so I'm attaching a patch in the hopes that someone
who is a regular contributor will review it and check it in.

Disclaimer: I spent an hour learning python for the express purpose of
making these graphs. That's the extent of my python experience so
some things might have been done the long way around.

It adds two parameters to the legend class:

The first 'rowspercolumn' specifies how often to start a new
column. If it is -1 then the current single-column behaviour is
reproduced. I set this to -1 in my matplotlibrc file, and pass a
specific number to the legend command when I want a multi-column
legend. 

The second 'columnsep' specifies the distance between the right side
of one column's label and the left side of the line of the next
column. 

Columns are sized horizontally to fit the largest label in the
column. I've tested it "extensively" on my case, with various
combinations of columns and legend entries. It seems to be stable. But
"extensively" is probably not a huge amount, honestly, and I'm new to
matplotlib so I may not have covered all the cases.

Cheers,
Colin

p.s. the patch is against the MacOS X binary distro which is at
0.87.4.

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> When I run the following: figure(); plot([1,2]) figure();
    Darren> plot([1,2])

    Darren> and then I use the zoom widget in one figure, and then try
    Darren> to use the zoom widget in the other figure without turning
    Darren> off the first zoom widget, I get an error. Is this
    Darren> desirable?

No -- I hadn't considered this use case.  The locking should be on a
per figure basis.  I introduced locking to handle the case where
someone wants to use a widget that draws onto the canvas (like the
lasso tool) w/o interfering with the other tools that are handling
events.  Eg, if pan/zoom is enabled and you are also trying to draw a
lasso, all hell breaks loose.

I've commented this out and will re-implement after further
consideration.  Thanks for the heads-up.

JDH

When I run the following:

figure(); plot([1,2])
figure(); plot([1,2])

and then I use the zoom widget in one figure, and then try to use the zoom 
widget in the other figure without turning off the first zoom widget, I get 
an error. Is this desirable?

---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent 
call last)

/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py in 
zoom(self, *args)
    305     def zoom( self, *args ):
    306         self.buttons[ 'Pan' ].setOn( False )
--> 307         NavigationToolbar2.zoom( self, *args )
    308
    309     def dynamic_update( self ):

/usr/lib64/python2.4/site-packages/matplotlib/backend_bases.py in zoom(self, 
*args)
   1564             self._idRelease = 
self.canvas.mpl_connect('button_release_event', self.release_zoom)
   1565             self.mode = 'Zoom to rect mode'
-> 1566             widgets.lock(self)
   1567         else:
   1568             #pass

/usr/lib64/python2.4/site-packages/matplotlib/widgets.py in __call__(self, o)
     31         'reserve the lock for o'
     32         if not self.available(o):
---> 33             raise ValueError('already locked')
     34         self._owner = o
     35

ValueError: already locked



Darren