matplotlib-devel Mailing List for matplotlib

DQpTZW50IHZpYSBCbGFja0JlcnJ5IGZyb20gVC1Nb2JpbGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IEtlbiBNY0l2b3IgPG1jaXZvckBpaXQuZWR1Pg0KDQpEYXRlOiBGcmks
IDI3IEp1bCAyMDA3IDE3OjM1OjA1IA0KVG86Sm9obiBIdW50ZXIgPGpkaDIzNThAZ21haWwuY29t
Pg0KQ2M6bWF0cGxvdGxpYiBkZXZlbG9wbWVudCBsaXN0IDxtYXRwbG90bGliLWRldmVsQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldD4NClN1YmplY3Q6IFJlOiBbbWF0cGxvdGxpYi1kZXZlbF0gbXBsMSBk
cmFmdA0KDQoNCk9uIEp1bCAyNSwgMjAwNywgYXQgMTI6MDkgUE0sIEpvaG4gSHVudGVyIHdyb3Rl
Og0KPg0KPiBIaSBLZW4gLS0gc29ycnkgZm9yIHRoZSByYWRpbyBzaWxlbmNlLCBJJ20gbm90IGlu
dGVudGlvbmFsbHkgaWdub3JpbmcNCj4geW91LiAgUmVhbCBsaWZlIGhhcyBtYWRlIHNvbWUgZGVt
YW5kcyBvbiBteSB0aW1lIG9mIGxhdGUsIGFuZCBwcm9iYWJseQ0KPiB3aWxsIHVudGlsIG5leHQg
d2VlaywgYnV0IEkgd2FzIGFibGUgdG8gZG93bmxvYWQsIHJlYWQgdGhyb3VnaCBhbmQNCj4gdGVz
dCB5b3VyIGNvZGUuDQoNCkkgYXBwcmVjaWF0ZSB5b3UgbWFraW5nIHRoZSB0aW1lIHRvIHRha2Ug
YSBsb29rIGF0IG15IGNvZGUgaW4gc3BpdGUgIA0Kb2YgaXQuDQoNCj4gQnV0IEkgZG9uJ3QgdGhp
bmsgdGhhdCBjbG9zZXMgdGhlIGJvb2sgb24gdGhlIHN1YmplY3QgLS0gZm9yICANCj4gZXhhbXBs
ZSwgSSBoYXZlIHJlYWxpemVkIEkgYW0gaW50cm9kdWNpbmcgdG9vIG11Y2ggY29tcGxleGl0eSBh
bmQgIA0KPiB0cmFpdCBmb3J3YXJkaW5nLCBhbmQgSSB0aGluayBJIGtub3cgYSB3YXkgdG8gd29y
ayBhcm91bmQgdGhpcywgc28gIA0KPiBJIHdpbGwgYmUgaGFja2luZyB0aHJvdWdoIG15IHZlcnNp
b24gb25lIG1vcmUgdGltZSB3aGlsZSBhdCB0aGUgIA0KPiBzYW1lIHRpbWUgdGFraW5nIGEgY2xv
c2VyIGxvb2sgYXQgeW91cnMuDQoNCkknZCBoYXJkbHkgZXhwZWN0IGl0IHRvIGNsb3NlIHRoZSBi
b29rIG9uIHRoZSBzdWJqZWN0LiAgQWx0aG91Z2ggaXQgIA0KZnVuY3Rpb25zIGFzIGEgcHJvb2Yt
b2YtY29uY2VwdCwgbXkgcmVuZGVyaW5nIG1vZGVsIG5lZWRzIG1vcmUgd29yayAgDQpiZWZvcmUg
aXQgY2FuIGhhbmRsZSBzcGVjaWFsIGNhc2VzIGxpa2UgdGhlIGJsZW5kZWQgYWZmaW5lICANCnRy
YW5zZm9ybWF0aW9uIHRvIHBsb3QgYW4gYXhpcy4gIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCBo
b3cgYmVzdCB0byAgDQphY2NvbXBsaXNoIHRoaXMgYW5kIHdpbGwgdHJ5IHRvIGhhdmUgc29tZXRo
aW5nIGZvciB5b3UgdG8gbG9vayBhdCBieSAgDQplYXJseSBuZXh0IHdlZWsuICBQbGVhc2UgZHJv
cCBtZSBhIGxpbmUgd2hlbiB5b3UncmUgc2F0aXNmaWVkIHdpdGggIA0KeW91ciBjaGFuZ2VzIHRv
IG1wbDEucHksIGFzIEknbSBsb29raW5nIGZvcndhcmQgdG8gc2VlaW5nIHRoZW0uDQoNCj4gSSBh
bHNvIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIGFib3V0IHRoZSAiaGFyZCB0byBvcHRpbWl6ZSIg
cGFydCwgIA0KPiBiZWNhdXNlIHRoYXQgaXMgbm90IGludHVpdGl2ZWx5IGNsZWFyIHRvIG1lLg0K
DQpNb3ZpbmcgdG8gYSByZW5kZXJpbmcgbW9kZWwgd2hlbiB0aGUgcHJpbWl0aXZlcyBtb2RpZnkg
dGhlIENUTSAgDQppbnN0ZWFkIG9mIHJlcGxhY2luZyBpdCB3aXRoIGEgcHJlLWNhbGN1bGF0ZWQg
dmFsdWUgcmVtb3ZlcyB0aGUgIA0KZGVwZW5kZW5jeSBiZXR3ZWVuIHByaW1pdGl2ZXMgYW5kIHRo
ZWlyIGNvbnRhaW5lcnMuICBBIFByaW1pdGl2ZSAgDQpvYmplY3QsIGxpa2UgYSBQYXRoLCBtYXkg
YmUgcmV1c2VkIGFuZCBzaGFyZWQgYmV0d2VlbiByZW5kZXJlcnMuICBUaGUgIA0KbmF0aXZlIHZl
cnNpb24gb2YgYSBQcmltaXRpdmUgb2JqZWN0IGlzIHN0b3JlZCBieSB0aGUgUHJpbWl0aXZlICAN
Cm9iamVjdCBpdHNlbGYsIHNvIGl0IGNhbiBiZSByZXVzZWQgYnkgYW55IENhbnZhcyB0aGF0IGRy
YXdzIHRoZSAgDQpQcmltaXRpdmUuICBUaGlzIGFsc28gbWVhbnMgdGhhdCB5b3UgaW5jdXIgdmVy
eSBsaXR0bGUgY29zdCBpbiAgDQpjbGVhcmluZyBhIFJlbmRlcmVyIGFuZCB0aGVuIHJlcG9wdWxh
dGluZyBpdCB3aXRoIGV4aXN0aW5nICANClByaW1pdGl2ZXMuICBBbiBBcnRpc3QtbGV2ZWwgaW1w
bGVtZW50YXRpb24gb2Ygei1vcmRlciBjb3VsZCBsZXZlcmFnZSAgDQp0aGlzIHRvIGF2b2lkIGhh
dmluZyB0byBzb3J0IHByaW1pdGl2ZXMgYnkgei1vcmRlciBldmVyeSB0aW1lIGEgIA0KZmlndXJl
IGlzIHJlbmRlcmVkLg0KDQpTaW5jZSBwcmltaXRpdmVzIG1vZGlmeSBncmFwaGljcyBzdGF0ZSBp
bnN0ZWFkIG9mIHJlcGxhY2luZyBpdCAgDQp3aG9sZXNhbGUgdGhlIGl0J3MgZWFzaWVyIGZvciB0
aGUgQ2FudmFzIHRvIHB1c2ggYXMgZmV3IGNoYW5nZXMgdG8gIA0KdGhlIGJhY2tlbmQgYXMgcG9z
c2libGUuICBGb3IgZXhhbXBsZSwgaWYgbm9uZSBvZiB0aGUgY2hpbGQgIA0KcHJpbWl0aXZlcyBv
ZiBhIFNjYWxlZFZpZXcgaGF2ZSB0aGVpciBvd24gdHJhbnNmb3JtcyB0aGVuIHRoZSBDVE0gIA0K
b25seSBnZXRzIG1vZGlmaWVkIG9uY2Ugd2hlbiB0aGUgU2NhbGVkVmlldyBpcyByZW5kZXJlZC4g
IFRoZSBzYW1lIGlzICANCnRydWUgZm9yIGFsbCBvZiB0aGUgb3RoZXIgZ3JhcGhpY3Mgc3RhdGUg
cGFyYW1ldGVycywgbGlrZSBsaW5ld2lkdGggIA0KYW5kIHN0cm9rZWNvbG9yLiAgVGhpcyBzYXZl
cyBvbiB1bm5lY2Vzc2FyeSBiYWNrZW5kIG92ZXJoZWFkIChlLmcuICANCmNyZWF0aW5nIHRoZSBz
YW1lIGFnZy50cmFuc19hZmZpbmUgcmVwZWF0ZWRseSkuICBJdCBjb3VsZCBhbHNvIGxlYWQgIA0K
dG8gdGlnaHRlciBQREYgYW5kIEVQUyBvdXRwdXQuDQoNCkZpbmFsbHksIHRoZSBSZW5kZXJlciBj
bGFzcyBpcyBjYW52YXMtaW5kZXBlbmRlbnQgc28gaXQgY2FuIGJlIHVzZWQgIA0KdG8gZHJhdyBv
biBtdWx0aXBsZSBjYW52YXNlcyBkdXJpbmcgdGhlIGNvdXJzZSBvZiBpdHMgbGlmZXRpbWUuICBJ
ICANCmhvcGUgdGhpcyB3aWxsIHN1YnN0YW50aWFsbHkgc2ltcGxpZnkgdGhlIHByb2Nlc3Mgb2Yg
c2F2aW5nIGEgZmlndXJlICANCnRoYXQgd2FzIGRyYXduIGludGVyYWN0aXZlbHkuICBJJ20gYWxz
byBjb250ZW1wbGF0aW5nIG1ha2luZyAgDQpSZW5kZXJlcnMgYWJsZSB0byBjb250YWluIGNoaWxk
IFJlbmRlcmVycyBzbyBwYXJ0cyBvZiBhIGZpZ3VyZSBjYW4gYmUgIA0Kc2VsZWN0aXZlbHkgdXBk
YXRlZC4gIEZvciBleGFtcGxlLCBkcmF3aW5nIHRoZSBub24tQXhpcyBjaGlsZHJlbiBvZiAgDQph
biBBeGVzIGJ5IHVzaW5nIGEgc3VicmVuZGVyZXIgY291bGQgZnVydGhlciBpbXByb3ZlIGFuaW1h
dGlvbiAgDQpwZXJmb3JtYW5jZS4NCg0KPiBJIGNvbmZlc3MgdG8gYmVpbmcgYSBtZXRhLWNsYXNz
IGlnbm9yYW11cywgc28gSSBhbSBpbnRyaWd1ZWQgdG8gc3R1ZHkNCj4gaG93IHlvdSBoYW5kbGVk
IHRoZSBjYW52YXMgcHJpbWl0aXZlIGNhY2hlIHByb2JsZW0gdXNpbmcgbWV0YSBjbGFzc2VzLg0K
DQpJIGhhdGUgdG8gZGlzYXBwb2ludCB5b3UsIGJ1dCBtZXRhY2xhc3NlcyBhcmVuJ3QgaW52b2x2
ZWQuICBSaWdodCBub3cgIA0KdGhlIGNhY2hpbmcgaXMgaW1wbGVtZW50ZWQgY29vcGVyYXRpdmVs
eSBieSBDYW52YXMgYW5kICANCkNhbnZhc1ByaW1pdGl2ZSB0byByZWR1Y2UgZHVwbGljYXRlIGNv
ZGUuICAgDQpDYW52YXNQcmltaXRpdmUuZ2V0X2NhbnZhc19wcmltaXRpdmUoKSBoYW5kbGVzIHRo
ZSBjYWNoaW5nIGxvZ2ljIGFuZCAgDQpjYWxscyBDYW52YXNQcmltaXRpdmUuY3JlYXRlX2NhbnZh
c19wcmltaXRpdmUoKSB0byBjcmVhdGUgYSBuZXcgIA0KbmF0aXZlIG9iamVjdCBpZiBuZWNlc3Nh
cnkuICBTdWJjbGFzc2VzIG9mIENhbnZhc1ByaW1pdGl2ZW92ZXJyaWRlICANCmNyZWF0ZV9jYW52
YXNfcHJpbWl0aXZlKCkgdG8gZGVsZWdhdGUgdGhlIGNhbGwgdG8gdGhlIGFwcHJvcHJpYXRlICAN
Cm1ldGhvZCBvZiBDYW52YXMsIGUuZy4gUGF0aC5jcmVhdGVfY2FudmFzX3ByaW1pdGl2ZSgpIHJl
dHVybnMgdGhlICANCnJlc3VsdCBvZiBDYW52YXMuY3JlYXRlX2NhbnZhc19wYXRoKCkuICBTdWJj
bGFzc2VzIG9mIENhbnZhcyB0aGF0IGRvICANCm5vdCBjYWNoZSBQcmltaXRpdmVzIHNob3VsZCBu
b3Qgb3ZlcnJpZGUgdGhlIGNyZWF0ZV9jYW52YXNfeHh4KCkgIA0KbWV0aG9kcy4NCg0KPiBIb3cg
Zm9yIGV4YW1wbGUsIGlmIG9uZSBtb2RpZmllcyBhIFJlY3RhbmdsZSBvYmplY3Qgd2hpY2ggZW1i
b2RpZXMgYQ0KPiBwYXRoIHByaW1pdGl2ZSwgd291bGQgdGhlIGNhbnZhcyBnZXQgdGhlIG5vdGlm
aWNhdGlvbiB0byB1cGRhdGUgaXQncw0KPiBpbnRlcm5hbCBwYXRoIHJlcHJlc2VudGF0aW9uIChl
Z2cgdGhlIGFnZ19wYXRoX3N0b3JhZ2UpPy4NCg0KTmF0aXZlIGNhbnZhcyBvYmplY3RzIGFyZSBh
bHdheXMgY3JlYXRlZCBhdCByZW5kZXItdGltZSwgc28gcmVjdGFuZ2xlICANCndvdWxkIGp1c3Qg
dXBkYXRlIGl0cyBhc3NvY2lhdGVkIFBhdGggaW5zdGFuY2Ugd2hlbiBpdHMgYm91bmRzICANCmNo
YW5nZWQuICBUaGUgbmV4dCB0aW1lIHRoZSBQYXRoIGlzIGRyYXduLCBDYW52YXMuZHJhd19wYXRo
KCkgd291bGQgIA0KY2FsbCBDYW52YXNQcmltaXRpdmUuZ2V0X2NhbnZhc19wcmltaXRpdmUoKSBh
bmQgZW5kIHVwIHdpdGggYSBuZXcgQUdHICANCnBhdGguICBUaGF0IGJlaW5nIHNhaWQsIGl0IG1p
Z2h0IGJlIG1vcmUgZWZmaWNpZW50IGlmIGFsbCBSZWN0YW5nbGVzICANCnNoYXJlIG9uZSBQYXRo
IHRoYXQgZHJhd3MgYSB1bml0IHNxdWFyZSBhbmQgY2hhbmdlIGl0cyBzaXplIGJ5ICANCnVwZGF0
aW5nIHRoZSBDVE0uDQoNCj4gV2l0aCB0cmFpdHMsIEkgdXNlIHRoZSB0cmFpdCBldmVudCBoYW5k
bGluZyBtZWNoYW5pc20gc28gdGhhdCB3aGVuICANCj4gYW55IG9mDQo+IHRoZSBib3ggcHJvcGVy
dGllcyAobGVmdCwgd2lkdGgsIHRvcCwgZXRjLi4uKSBhcmUgbW9kaWZpZWQsIHRoZQ0KPiBQYXRo
UHJpbWl0aXZlQWdnIHdvdWxkIGdldCBhIGNhbGxiYWNrLiAgU28gd2hlbiB0aGUgdXNlciBkb2Vz
DQo+DQo+IHJlY3QubGVmdCA9IDAuMQ0KPg0KPiB0aGUgYWdnIHBhdGgga25vd3MgdG8gdXBkYXRl
IGl0c2VsZi4gIFRoaXMgaXMgcHJldHR5IGNvb2wuDQoNClllcyBpdCBpcywgYW5kIEkgYWdyZWUg
dGhhdCBtcGwxIHNob3VsZCBoYXZlIGFuIGF0dHJpYnV0ZS1iYXNlZCBBUEkgIA0KZm9yIG1vZGlm
eWluZyBwbG90IG9iamVjdCBwYXJhbWV0ZXJzLg0KDQo+IHZpcy1hLXZpcyBwcm9wZXJ0aWVzIHZz
IHRyYWl0cywgSSBzZWNvbmQgUGV0ZXIncyBjb21tZW50IHRoYXQgb25jZQ0KPiB5b3UndmUgd3Jp
dHRlbiA4LDAwMCBzZXR0ZXJzIGFuZCBnZXR0ZXJzIGFuZCBtYW51YWxseSBjb25zdHJ1Y3RlZA0K
PiBwcm9wZXJ0aWVzLCB5b3UnbGwgcHJvYmFibHkgZXZvbHZlIHRvd2FyZCBzb21ldGhpbmcgbGlr
ZSB0cmFpdHMsIHcvbw0KPiBhbGwgdGhlIGZlYXR1cmVzLiAgVGhpcyBpcyBhIGxpYnJhcnkgdGhh
dCBoYXMgYmVlbiBidWcgYW5kIHBlcmZvcm1hbmNlDQo+IHZldHRlZCBpbiBwcm9kdWN0aW9uIGFw
cGxpY2F0aW9ucyBmb3IgeWVhcnMsIHNvIHdlIHNob3VsZCBzZXJpb3VzbHkNCj4gY29uc2lkZXIg
aXQgYXMgYSBwcm9wZXJ0aWVzIGFsdGVybmF0aXZlLg0KDQpUcmFpdHMgZG9lcyBsb29rIGV4Y2Vs
bGVudCBhdCB3aGF0IGl0IGRvZXMsIGJ1dCBJJ20gc3RpbGwgb2YgdGhlICANCm9waW5pb24gdGhh
dCB0aGUgY29zdCBvZiBhZGRpbmcgYSBsYXJnZSBleHRlcm5hbCBkZXBlbmRlbmN5IHRoYXQgaXMg
IA0Kbm90IGF2YWlsYWJsZSBpbiBEZWJpYW4gb3IgVWJ1bnR1IG91dHdlaWdocyB0aGUgYmVuZWZp
dHMgb2YgcmVwbGFjaW5nICANCnZhbmlsbGEgcHJvcGVydGllcyB3aXRoIHRyYWl0cy4NCg0KPiBJ
IHN0cm9uZ2x5IGVuY291cmFnZSB5b3UgdG8gZG93bmxvYWQgRmVybmFuZG8ncyBtcGxjb25maWcg
c2FuZGJveCAgDQo+IHN0dWZmIGFuZCB0cnkgdGhlIGVkaXRfdHJhaXRzIGRlbW8gaW4gdGhlIHBy
ZXNlbmNlIG9mIGEgd3ggZW5hYmxlZCAgDQo+IHRyYWl0cy4NCg0KSSdsbCBnaXZlIGl0IGEgdHJ5
Lg0KDQo+IEhlIGlzIHNvbWV3aGF0IGJsb3duIGF3YXkgYnkgdGhlIGZhY3QgdGhhdCBoZSBnb3Qg
YSBzb3BoaXN0aWNhdGVkLCAgDQo+IG5lc3RlZCBHVUkgZGlhbG9nIHcvbyB3cml0aW5nICphbnkq
IGNvZGUuICBTaW5jZSB5b3UgYXJlIGEgIA0KPiBjb21taXR0ZWQgd3ggdXNlciwgeW91IG1pZ2h0
IGZpbmQgdGhpcyBwYXJ0aWN1bGFybHkgYXBwZWFsaW5nLg0KDQpObyBvbmUncyBjb21taXR0ZWQg
bWUgeWV0LCBtd2FoYWhhISAgQWN0dWFsbHksIHRoYXQgZmVhdHVyZSBkb2VzICANCmxpdHRsZSB0
byBhZHZhbmNlIG15IHByaW1hcnkgdXNlIGNhc2UgZm9yIG1wbCwgZW1iZWRkaW5nIHBsb3RzIGlu
ICANCmFwcGxpY2F0aW9ucy4gIEkgbXkgZXhwZXJpZW5jZSB5b3UgaGF2ZSB0byBwdXQgZW5vdWdo
IGVmZm9ydCBpbnRvICANCm1ha2luZyB0aGUgcGxvdHMgbG9vayBnb29kIHRoYXQgeW91IGRvbid0
IHdhbnQgdXNlcnMgdG8gYmUgYWJsZSB0byAgDQplZGl0IHRoZW0gYXQgcnVudGltZS4gIFRoYXQg
YmVpbmcgc2FpZCwgSSB3b3VsZG4ndCBiZSBzdXJwcmlzZWQgdG8gIA0KbGVhcm4gdGhhdCBvdGhl
cnMnIGV4cGVyaWVuY2VzIGRpZmZlci4NCg0KPiBCdXQgYXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBJ
IHRoaW5rIHRoZSAqbm90aWZpY2F0aW9uKiBhc3BlY3Qgb2YgIA0KPiB0cmFpdHMgaXMgdGhlIGtp
bGxlciBmZWF0dXJlLg0KDQpJIGtub3csIGFuZCBJIHN0aWxsIHRoaW5rIHRoYXQgZm9yIG1hdHBs
b3RsaWIgaXQncyBhIGJhZCBTb2Z0d2FyZSAgDQpFbmdpbmVlcmluZyBtb3ZlIGR1ZSB0byB0aGUg
aW1wbGljaXQgaW50ZXItb2JqZWN0IGRlcGVuZGVuY2llcyBpdCAgDQpjcmVhdGVzLiAgSSBjYW4n
dCBzZWUgd2h5IGRyYXdpbmcgcGxvdHMgc2hvdWxkIHJlcXVpcmUgdGhhdCBtdWNoICANCiJzcG9v
a3kgYWN0aW9uIGF0IGEgZGlzdGFuY2UiLiAgSSBjb3VsZCBiZSB3cm9uZywgYnV0IGZvciBub3cg
SSdsbCAgDQprZWVwIHdvcmtpbmcgdG8gZmluZCBhIHdheSB0aGF0IGRvZXNuJ3QuDQoNCj4gSSB0
aGluayB5b3VyIGFwcHJvYWNoIG9mIHdvcmtpbmcgb24gYSBkaXNwbGF5IFBERiByZW5kZXJlciBp
bnRlcmZhY2UNCj4gaXMgYWxzbyBhIGdvb2Qgb25lLCBmb3Igc2V2ZXJhbCByZWFzb25zLiAgSXQg
dXNlcyBhbiBlc3RhYmxpc2hlZA0KPiBzcGVjaWZpY2F0aW9uIGluc3RlYWQgb2YgYSBob21lIGdy
b3duIG9uZSwgYW5kIGl0IG1ha2VzIGl0IGVhc2llciBmb3INCj4gdXMgdG8gY29uc2lkZXIgdGhp
bmdzIGxpa2UgaW50ZWdyYXRpbmcgd2l0aCBLaXZhIG9yIENoYWNvLg0KDQpJdCdzIG5pY2UgdG8g
aGVhciB5b3UgbGlrZSBpdC4gIFRob3NlIGFyZSB0d28gb2YgdGhlIHNwZWNpZmljIGdvYWxzIEkg
IA0KaGF2ZSBpbiBtaW5kLiAgSSBhbHNvIGxpa2UgdGhlIGlkZWEgb2YgaGF2aW5nIGEgZ2VuZXJp
YyByZXRhaW5lZCAgDQpkcmF3aW5nIHN5c3RlbSBhdmFpbGFibGUgaW4gUHl0aG9uLg0KDQo+IEkg
YW0gZ2xhZCB5b3UgaW50ZXJwcmV0ZWQgbXkgbXBsMSBza2V0Y2ggaW4gdGhlIHJpZ2h0IHZlaW4s
IGFzIGEgIA0KPiBsYWIgaW4gd2hpY2gNCj4gcGVvcGxlIGNhbiBhZHZvY2F0ZSBpZGVhcyBhcyB3
b3JraW5nIGNvZGUuDQoNCldlbGwsIEknbSBnbGFkIHlvdSd2ZSB0YWtlbiBteSBjcml0aWNpc21z
IG9mIG1wbDEucHkgaW4gdGhlIHNwaXJpdCAgDQp0aGV5IHdlcmUgaW50ZW5kZWQgaW4uICBJIGFs
c28gYXBwcmVjaWF0ZSB5b3UgdGFraW5nIHRoZSB0aW1lIHRvICANCnJldmlldyB0aGUgY29kZSBJ
IHN1Ym1pdHRlZCBpbnN0ZWFkIG9mIGp1c3QgdGVsbGluZyBtZSBob3cgdmVyeSBuaWNlICANCmFu
ZCBjb252ZW5pZW50IHRyYWl0cyBhcmUuICA7LSkNCg0KPiBIb3BlZnVsbHkgbmV4dCB3ZWVrIHdl
IGNhbiBjb21lIHRvIHNvbWUgY29uc2Vuc3VzIGFuZCBzdGFydCBtZXJnaW5nICANCj4gb3VyIHR3
byBsaW5lcy4NCg0KVGhhdCBzb3VuZHMgbGlrZSBhIHBsYW4uICBJJ2xsIHRyeSB0byBtYWtlIHNv
bWUgcHJvZ3Jlc3Mgb24gdGhlICANCmJsZW5kZWQgYWZmaW5lcyBmb3IgZHJhd2luZyBheGlzIHRp
Y2ttYXJrcyBhbmQgdGhlIEFydGlzdHMgbGF5ZXIuDQoNCktlbg0K

On Jul 25, 2007, at 12:09 PM, John Hunter wrote:
>
> Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring
> you. Real life has made some demands on my time of late, and probably
> will until next week, but I was able to download, read through and
> test your code.
I appreciate you making the time to take a look at my code in spite 
of it.
> But I don't think that closes the book on the subject -- for 
> example, I have realized I am introducing too much complexity and 
> trait forwarding, and I think I know a way to work around this, so 
> I will be hacking through my version one more time while at the 
> same time taking a closer look at yours.
I'd hardly expect it to close the book on the subject. Although it 
functions as a proof-of-concept, my rendering model needs more work 
before it can handle special cases like the blended affine 
transformation to plot an axis. I've been thinking about how best to 
accomplish this and will try to have something for you to look at by 
early next week. Please drop me a line when you're satisfied with 
your changes to mpl1.py, as I'm looking forward to seeing them.
> I also would like to hear more about the "hard to optimize" part, 
> because that is not intuitively clear to me.
Moving to a rendering model when the primitives modify the CTM 
instead of replacing it with a pre-calculated value removes the 
dependency between primitives and their containers. A Primitive 
object, like a Path, may be reused and shared between renderers. The 
native version of a Primitive object is stored by the Primitive 
object itself, so it can be reused by any Canvas that draws the 
Primitive. This also means that you incur very little cost in 
clearing a Renderer and then repopulating it with existing 
Primitives. An Artist-level implementation of z-order could leverage 
this to avoid having to sort primitives by z-order every time a 
figure is rendered.
Since primitives modify graphics state instead of replacing it 
wholesale the it's easier for the Canvas to push as few changes to 
the backend as possible. For example, if none of the child 
primitives of a ScaledView have their own transforms then the CTM 
only gets modified once when the ScaledView is rendered. The same is 
true for all of the other graphics state parameters, like linewidth 
and strokecolor. This saves on unnecessary backend overhead (e.g. 
creating the same agg.trans_affine repeatedly). It could also lead 
to tighter PDF and EPS output.
Finally, the Renderer class is canvas-independent so it can be used 
to draw on multiple canvases during the course of its lifetime. I 
hope this will substantially simplify the process of saving a figure 
that was drawn interactively. I'm also contemplating making 
Renderers able to contain child Renderers so parts of a figure can be 
selectively updated. For example, drawing the non-Axis children of 
an Axes by using a subrenderer could further improve animation 
performance.
> I confess to being a meta-class ignoramus, so I am intrigued to study
> how you handled the canvas primitive cache problem using meta classes.
I hate to disappoint you, but metaclasses aren't involved. Right now 
the caching is implemented cooperatively by Canvas and 
CanvasPrimitive to reduce duplicate code. 
CanvasPrimitive.get_canvas_primitive() handles the caching logic and 
calls CanvasPrimitive.create_canvas_primitive() to create a new 
native object if necessary. Subclasses of CanvasPrimitiveoverride 
create_canvas_primitive() to delegate the call to the appropriate 
method of Canvas, e.g. Path.create_canvas_primitive() returns the 
result of Canvas.create_canvas_path(). Subclasses of Canvas that do 
not cache Primitives should not override the create_canvas_xxx() 
methods.
> How for example, if one modifies a Rectangle object which embodies a
> path primitive, would the canvas get the notification to update it's
> internal path representation (egg the agg_path_storage)?.
Native canvas objects are always created at render-time, so rectangle 
would just update its associated Path instance when its bounds 
changed. The next time the Path is drawn, Canvas.draw_path() would 
call CanvasPrimitive.get_canvas_primitive() and end up with a new AGG 
path. That being said, it might be more efficient if all Rectangles 
share one Path that draws a unit square and change its size by 
updating the CTM.
> With traits, I use the trait event handling mechanism so that when 
> any of
> the box properties (left, width, top, etc...) are modified, the
> PathPrimitiveAgg would get a callback. So when the user does
>
> rect.left = 0.1
>
> the agg path knows to update itself. This is pretty cool.
Yes it is, and I agree that mpl1 should have an attribute-based API 
for modifying plot object parameters.
> vis-a-vis properties vs traits, I second Peter's comment that once
> you've written 8,000 setters and getters and manually constructed
> properties, you'll probably evolve toward something like traits, w/o
> all the features. This is a library that has been bug and performance
> vetted in production applications for years, so we should seriously
> consider it as a properties alternative.
Traits does look excellent at what it does, but I'm still of the 
opinion that the cost of adding a large external dependency that is 
not available in Debian or Ubuntu outweighs the benefits of replacing 
vanilla properties with traits.
> I strongly encourage you to download Fernando's mplconfig sandbox 
> stuff and try the edit_traits demo in the presence of a wx enabled 
> traits.
I'll give it a try.
> He is somewhat blown away by the fact that he got a sophisticated, 
> nested GUI dialog w/o writing *any* code. Since you are a 
> committed wx user, you might find this particularly appealing.
No one's committed me yet, mwahaha! Actually, that feature does 
little to advance my primary use case for mpl, embedding plots in 
applications. I my experience you have to put enough effort into 
making the plots look good that you don't want users to be able to 
edit them at runtime. That being said, I wouldn't be surprised to 
learn that others' experiences differ.
> But at the end of the day, I think the *notification* aspect of 
> traits is the killer feature.
I know, and I still think that for matplotlib it's a bad Software 
Engineering move due to the implicit inter-object dependencies it 
creates. I can't see why drawing plots should require that much 
"spooky action at a distance". I could be wrong, but for now I'll 
keep working to find a way that doesn't.
> I think your approach of working on a display PDF renderer interface
> is also a good one, for several reasons. It uses an established
> specification instead of a home grown one, and it makes it easier for
> us to consider things like integrating with Kiva or Chaco.
It's nice to hear you like it. Those are two of the specific goals I 
have in mind. I also like the idea of having a generic retained 
drawing system available in Python.
> I am glad you interpreted my mpl1 sketch in the right vein, as a 
> lab in which
> people can advocate ideas as working code.
Well, I'm glad you've taken my criticisms of mpl1.py in the spirit 
they were intended in. I also appreciate you taking the time to 
review the code I submitted instead of just telling me how very nice 
and convenient traits are. ;-)
> Hopefully next week we can come to some consensus and start merging 
> our two lines.
That sounds like a plan. I'll try to make some progress on the 
blended affines for drawing axis tickmarks and the Artists layer.
Ken

John Hunter wrote:
> On 7/26/07, Darren Dale <dd...@co...> wrote:
>>> where Math is a wrapper object that signals to "text" that its contents
>>> are to be passed to the mathtext interpreter.
>> I would like to voice my opinion against this idea. I think the backward
>> imcompatibility will be rare, and does not justify the additionaly complexity
>> of the far more common need to interpret mathtext.
> 
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX. Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
> 
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
> 
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text. Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option. In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
> 
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
> 
> Michael, do you have a preference or an alternate proposal?
> JDH
Let's rule out option 3 completely; it is an example of the type of 
cleverness that ends up causing more trouble and confusion than it is worth.
I also oppose using something other than the $ to delimit math, if 
delimiters are needed, which I think they are. At least in *Tex, a 
string of characters (a word) is rendered very differently depending on 
whether it is inside an equation or outside.
I suspect that options 1 and 4 will cause endless questions to 
matplotlib-users, and grumbling among people in the business and 
financial community who use lots of dollar signs and no math.
That leaves some variant of 2 and the Math('string') idea. I find the 
latter quite pythonic; it is a very concise, readable, and general way 
of attaching extra information to a string object, and it does not 
require passing yet another kwarg through a sequence of function and 
method calls. But if it is judged to be too out-of-character with the 
rest of the mpl api, or if in practice it would cause trouble that I 
don't see yet, then I am happy to let it go. I have not thought it 
through carefully, and I am not attached to it.
If a variant of 2 is chosen, one might shorten the kwarg to "math". Or 
use "format='math'" or something like that. This is more flexible than 
a boolean kwarg, leaving the door open to additional options for 
interpretation of strings--but not quite as flexible and powerful as the 
math('string') idea.
Eric

On Thursday 26 July 2007 11:40:23 am Fernando Perez wrote:
> On 7/26/07, Darren Dale <dd...@co...> wrote:
> > On Thursday 26 July 2007 10:30:34 am Ted Drain wrote:
> > > Why do you need an api file at all? Why not have config be a python
> > > package and let config/__init__.py take care of importing
> > > everything?
[...]
> I don't remember the exact details, but we started using the api.py
> approach instead of __init__ on Enthought's lead
[...] 
> You may want to inquire with them for the details
I did ask at enthought-dev, and they said it was primarily due to circular 
dependencies. The use of __init__ is already causing us some headaches in 
mpl, so I decided to stick with api.py, leaving __init__ empty.
I just uploaded my work to matplotlib svn. The idea is that matplotlib would 
import the rcParams (and eventually mplConfig) from config/api, but for just 
think of config/ as a sandbox. The new config system is turned on by default 
in api.py by setting 
USE_NEW_CONFIG = True
If it is True, you can run configtest.py in IPython, which will import the 
traited mplConfig object and rcParams, a thin wrapper to mplConfig. 
configtest will change rcParams['backend'] to Cairo, validate that the change 
occured in mplConfig, and will then try to change the backend to something 
nonsensical and should throw an error.
For now, validation in mplConfig is very similar to validation in the old 
system. I have not taken advantage of the more advanced capabilities of 
traits, like shadow attributes and so forth. For now I just wanted to get 
something that should work with existing matplotlib. 
The first time the traited config module mplconfig is loaded, it checks your 
config_dir (the cwd and then probably ~/.matplotlib) for a matplotlib.conf 
file. If it does not exist, it creates one, loads your old matplotlibrc, 
updates mplConfig based on your matplotlibrc, saves any non-default settings 
to the new matplotlib.conf. If the file does exist, it updates mplConfig 
accordingly.
The config/matpltolib.conf.default file was auto-generated (comments and all, 
thanks to Fernandos wizardry).
Darren

On Friday 27 July 2007 08:38:49 am Michael Droettboom wrote:
> If we go with another delimiter, there are others in TeX to choose
> from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both
> of these are less likely to be legitimate literals. While display math
> normally implies that the math is placed on a separate line (not inline
> with the text), it's not far from what matplotlib does, since it follows
> the display math layout patterns.
I think $$ might be a bad idea, that has a very specific meaning in TeX, which 
is different than $. Like wise, \[ means display math while \( means inline 
math. \( ... \) is considered to be fragile, while $ ... $ is robust, but 
maybe \( \) would be a good solution. Then you could even switch between 
mathtext and usetex, and the usetex code wouldnt have to go through strings 
trying to substitute latex mathmode indicators for mpl indicators.
Darren

On Fri, Jul 27, 2007 at 08:52:27AM -0400, Michael Droettboom wrote:
> Using this "mathtext=True" option (as opposed to using a delimiter that 
> TeX doesn't understand) or something else entirely, would certainly make 
> it easier to make usetex vs. not usetex more consistent.
I think so to.
> More broadly, it will probably never be 100% compatible -- I don't think 
> reimplementing all of TeX is feasible or desirable, and the fact that it 
> is a macro language makes it hard to fully emulate. Defining what is a 
> "hack" vs. normal usage is also subjective, of course...
No, of course, but you are making some progress in this direction, and I
think that would be a great added value coming from your work.
Cheers,
Gaël

Gael Varoquaux wrote:
> On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
> 
>>> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>>> 
>
> 
>> Except for the backward incompatibility, I like this because it is explicit.
>> 
>
> Juust a data point for the discussion. I think it would be very nice if a
> script gave the same result on a system with or without TeX (as long as
> you don't do TeX hacks).
> 
Using this "mathtext=True" option (as opposed to using a delimiter that 
TeX doesn't understand) or something else entirely, would certainly make 
it easier to make usetex vs. not usetex more consistent.
More broadly, it will probably never be 100% compatible -- I don't think 
reimplementing all of TeX is feasible or desirable, and the fact that it 
is a macro language makes it hard to fully emulate. Defining what is a 
"hack" vs. normal usage is also subjective, of course...
Cheers,
Mike

On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)
> Except for the backward incompatibility, I like this because it is explicit.
Juust a data point for the discussion. I think it would be very nice if a
script gave the same result on a system with or without TeX (as long as
you don't do TeX hacks).
My 2 cents,
Gaël

John Hunter wrote:
> Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
> 
Except for the backward incompatibility, I like this because it is explicit.
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.
That's close to what it does at the moment.
> Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option.
I'm not sure the performance hit would be so bad. The parser is 
completely flat until it goes between the $'s. But it would require all 
$'s to be escaped, of course.
> In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
> 
Well, that certainly is no shortage of options! ;) I think the decision 
should ultimately lie with someone with a better sense of the existing 
"feel" of matplotlib than I.
If we go with another delimiter, there are others in TeX to choose 
from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both 
of these are less likely to be legitimate literals. While display math 
normally implies that the math is placed on a separate line (not inline 
with the text), it's not far from what matplotlib does, since it follows 
the display math layout patterns.
Cheers,
Mike

A problem was reported on the users list that saving to a file named
'blah.pdf' using the wxagg backend actually saves a jpeg file named
'blah.pdf.jpg'. I think I can see how to fix this (by adding a block to
FigureCanvasWx.print_figure() similar to the existing blocks for ps and
svg), but would prefer to leave it to someone who actually works with
wx, in case I accidentally break something and never notice. I'll file a
bug on sourceforge.
Overall, the system for determining file format looks like it has
evolved and not been designed: various backends have their own code to
look at the file name extension and then switch to the proper backend.
Wouldn't it make sense to share at least the code that determines the
backend from the extension?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"John Hunter" <jd...@gm...> writes:
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.
Those users are probably also not so likely to want to use mathtext, so
there could be an rc setting for toggling the meaning of $ between the
currency symbol and the math delimiter. Adding rc settings is probably
not good for the API, though.
Is it an option to use something rarer than $ to delimit formulas? Most
of the printable ASCII characters are probably being used by someone,
and the unprintable characters are likely to be difficult to handle. ISO
Latin 1 contains e.g. the little-used currency sign ¤. But perhaps it is
too difficult to type on US keyboards?
(There is a Unicode Technical Note at http://unicode.org/notes/tn28/
which suggests using U+23A8 LEFT CURLY BRACKET MIDDLE PIECE and U+23AC
RIGHT CURLY BRACKET MIDDLE PIECE as math delimiters, but it also has its
own Unicode-based math syntax.)
> Option 1 is to educate them, and require them to \$ quote that symbol.
I guess Option 1' is to move away from $ to something else, and educate
mathtext users. If there are fewer of them (us), this would seem to be
easier globally.
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
You're right that it would be quite different than the rest of the API.
Perhaps your Option 2 (a text property) would cause the least surprise
in the long run, although it would break current mathtext-using code.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 7/26/07, Darren Dale <dd...@co...> wrote:
> On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:
> > This sounds to me like a good case for Guido's mantra of NOT putting
> > keywords in functions and instead just making two separate functions.
> > Why not just
> >
> > text(x,y,"This year I lost a lot of $$$")
> > mtext(x,y,r"This year I lost \$$\infty$")
> >
> > ? Explicit is better than implicit and all that...
>
> what about x/ylabels, titles, ticks, etc?
Oh, I'd forgotten about all of those :) Yes, this is pervasive across
MPL, I answered in haste. Duplicating the entire text-related API may
be a tad much, perhaps ;)
> I think education is the best way to go. Its not that difficult to grasp, its
> an established standard... and we are designing tools primarily for
> scientists and engineers after all. Most of the other options will probably
> have a larger effect on existing code.
Well, I was trying to go with John's concern for non-latex users. I'm
quite happy with a system that treats *every string* via latex. But I
know for many reasons that's not realistic here (and PyX does
precisely that, if I really want it).
Cheers,
f

On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:
> [ That was meant for the list, sorry ]
>
> On 7/26/07, John Hunter <jd...@gm...> wrote:
> > I'm on the fence as to how to handle this case. The majority of our
> > users will think of $ as the US currency symbol, and will have never
> > heard of TeX. Option 1 is to educate them, and require them to \$
> > quote that symbol. Option 2 is to enable a text property eg mathtext,
> > and do
> >
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)
But would this make sense:
text(x, y, 'what is the $\sin(x)$', mathtext=False)
[...]
> This sounds to me like a good case for Guido's mantra of NOT putting
> keywords in functions and instead just making two separate functions.
> Why not just
>
> text(x,y,"This year I lost a lot of $$$")
> mtext(x,y,r"This year I lost \$$\infty$")
>
> ? Explicit is better than implicit and all that...
what about x/ylabels, titles, ticks, etc?
I think education is the best way to go. Its not that difficult to grasp, its 
an established standard... and we are designing tools primarily for 
scientists and engineers after all. Most of the other options will probably 
have a larger effect on existing code.
Darren

[ That was meant for the list, sorry ]
On 7/26/07, John Hunter <jd...@gm...> wrote:
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX. Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text. Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option. In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
I'm not Michael, but I s'pose I can still speak :)
This sounds to me like a good case for Guido's mantra of NOT putting
keywords in functions and instead just making two separate functions.
Why not just
text(x,y,"This year I lost a lot of $$$")
mtext(x,y,r"This year I lost \$$\infty$")
? Explicit is better than implicit and all that...
cheers,
f

On 7/26/07, Darren Dale <dd...@co...> wrote:
> > where Math is a wrapper object that signals to "text" that its contents
> > are to be passed to the mathtext interpreter.
>
> I would like to voice my opinion against this idea. I think the backward
> imcompatibility will be rare, and does not justify the additionaly complexity
> of the far more common need to interpret mathtext.
I'm on the fence as to how to handle this case. The majority of our
users will think of $ as the US currency symbol, and will have never
heard of TeX. Option 1 is to educate them, and require them to \$
quote that symbol. Option 2 is to enable a text property eg mathtext,
and do
text(x, y, 'what is the $\sin(x)$', mathtext=True)
Option 3 is to try and be clever, and interpret an even number of
unquoted dollar symbols as mathtext, or any string that has a quoted
dollar sign symbol as mathtext, else assume plain text. Option 4 is
to treat *all* strings as mathtext, but I think we would pay a pretty
big performance hit to invoke the mathtext machinery for every piece
of text. But it is an option. In option 4, of course, users would be
required to quote all dollar signs, so it is related to option 1 but
slightly different in how it treats strings with no dollar signs.
I'm not too keen on the text(x, y, Math('string')) proposal, which is
a little outside the normal matplotlib approach.
Michael, do you have a preference or an alternate proposal?
JDH