matplotlib-devel Mailing List for matplotlib (Page 3)

John Hunter wrote:
> I'm getting prompted for username and password when I try and commit
> (normally I am not prompted since they are stored), and am not given
> access when I give them
>
> Authentication realm: <https://svn.sourceforge.net:443> SourceForge
> Subversion area
> Username: svn: Commit failed (details follow):
> svn: MKACTIVITY of
> '/svnroot/matplotlib/!svn/act/e139267f-8d18-0410-9ae4-f3e99be941f3':
> authorization failed (https://svn.sourceforge.net)
>
> Anyone else having problems, or aware of any issues?
>
> JDH
>
> 
John: Yes, I just had a similar problem. Turns out my SF password had 
expired. I logged in on the SF web page, and it prompted me for a new 
one. After than, SVN worked with the new password.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I'm getting prompted for username and password when I try and commit
(normally I am not prompted since they are stored), and am not given
access when I give them
Authentication realm: <https://svn.sourceforge.net:443> SourceForge
Subversion area
Username: svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/matplotlib/!svn/act/e139267f-8d18-0410-9ae4-f3e99be941f3':
authorization failed (https://svn.sourceforge.net)
Anyone else having problems, or aware of any issues?
JDH

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
 Edin> Conclusion =3D=3D=3D=3D=3D=3D=3D=3D John, what should I do? Ple=
ase comment.
I don't think we should be distracted by Type1 fonts or the lack of a
good set of free unicode trueype math fonts. We will have those soon
enough (or at some point). What I would like to see is an
infrastructure where the user can point to an arbitrary set of unicode
fonts and have mathtext work with that font set. Then when the STIX
or some other set of unicode fonts become available, we can point to
them. Users who have proprietary unicode math fonts can use them.
I don't think we are at the point now where we can easily test
mathtext with an arbitrary set of unicode fonts. I'd like to be there
before we get distracted on other things. Or am I missing something?
JDH

On Wednesday 12 July 2006 07:10, Edin Salkovi=C4=87 wrote:
> After some thorough research on the subject I decided to post my
> conclusions/thoughts here. Beware, this is a long one.
>
> Font problems
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> There are no good, complete, free, unicode, Open/TrueType math fonts
> currently. We will have to wait for the STIX fonts.
The STIX fonts have been delayed a number of times, but they just received =
the=20
last set of glyphs. This is good news.

 Due to a change of plan I won't be stuck in a library this
afternoon, so I won't be working on this transfer, but I am still
interested to now weather others agree that it would be useful to port
this part of the matplotlib website on the scipy wiki.
 Gael

 Hello list,
	I would like to move the "screenshot" section of the matplotlib
web site to the scipy.org wiki. The reason I suggest this is that I
think that we effectively have a 2 cookbooks in 2 different places. Is
anybody opposed to this ? I will be stuck in a library with not much to
do in a few hours, so I think I will start working on that.
 Gael

QWZ0ZXIgc29tZSB0aG9yb3VnaCByZXNlYXJjaCBvbiB0aGUgc3ViamVjdCBJIGRlY2lkZWQgdG8g
cG9zdCBteQpjb25jbHVzaW9ucy90aG91Z2h0cyBoZXJlLiBCZXdhcmUsIHRoaXMgaXMgYSBsb25n
IG9uZS4KCkZvbnQgcHJvYmxlbXMKPT09PT09PT09PQpUaGVyZSBhcmUgbm8gZ29vZCwgY29tcGxl
dGUsIGZyZWUsIHVuaWNvZGUsIE9wZW4vVHJ1ZVR5cGUgbWF0aCBmb250cwpjdXJyZW50bHkuIFdl
IHdpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUgU1RJWCBmb250cy4gT24gdGhlIHNpdGUgaXQKc2F5
cyB0aGF0IHRoZSBiZXRhIHZlcnNpb24gb2YgdGhlIGZvbnRzIHdpbGwgYmUgYXZhaWxhYmxlIGlu
CnNlcHRlbWJlciwgc28gcHJvYmFibHkgdGhlIG5leHQgU29DIGNvdWxkIGNvdmVyIHRoYXQgLSBp
ZiB3ZSdyZSBsdWNreQo7KS4KCkkgaGFkIGEgbG9vayBhdCB0aGUgZm9sbG93aW5nIE9wZW4vVHJ1
ZVR5cGUgdW5pY29kZSBmb250czoKICogQ01VIGZvbnRzLiBUaGlzIGZvbnRzIHByYWN0aWNhbHkg
ZG9uJ3QgaGF2ZSBhbnkgbWF0aCBzeW1ib2xzLCBzbwp0aGV5J3JlIG5vdCBhIHNvbHV0aW9uLgog
KiBUaGUgZm9udHMgdXNlZCBieSBPcGVuIE9mZmljZSAtIE9wZW4gU3ltYm9sIChvcGVuc19fXy50
dGYpLCB3aGljaApoYXMgYSBkZWNlbnQgc2V0IG9mIHN5bWJvbHMgKHVuaWNvZGUpLiBUaGlzIGZv
bnRzIHdlcmUgbWFkZSB0byBwbGF5CndlbGwgd2l0aCBUaW1lcywgYW5kIGNvdWxkIGJlIHVzZWQg
aW4gbWF0aHRleHQgd2l0aCBwZXJoYXBzIE5pbWJ1cwpSb21hbiBmb250cy4KICogRnJlZUZvbnQu
IEdQTCBmb250cywgYXZhaWxhYmxlIG9uIGFueSBMaW51eCBib3guIFRoZXkgaGF2ZSBhbgpleHRl
bnNpdmUgbGlzdCBvZiBzdXBwb3J0ZWQgc3ltYm9scy4gUHJvYmFibHkgdGhlIGJlc3QgZnJlZSBU
cnVlVHlwZQpmb250cyBvdXQgdGhlcmUuCgpUaGUgYmVzdCBzb2x1dGlvbiB0byB0aGUgcHJvYmxl
bSBvZiBnb29kIGZvbnRzIHdvdWxkIGJlIHVzaW5nIHRoZQpjdXJyZW50bHkgYXZhaWxhYmxlIENN
IGFuZCBBTVMgKGFuZCBvdGhlcikgVHlwZTEgZm9udHMgd2hpY2ggYXJlIGZyZWUKYW5kIGNvbWUg
d2l0aCBldmVyeSBUZVggZGlzdHJpYnV0aW9uLiBUaGVzZSBmb250cyBhcmUgY29tcGxldGUsIGFu
ZApoYXZlIHByZXR0eSBnb29kIFVuaWNvZGUgc3VwcG9ydCB3aGljaCBpcyBpbHVzdHJhdGVkIGJ5
IHRoZSBmb2xsb3dpbmcKY29kZToKCmZyb20gbWF0cGxvdGxpYi5mdDJmb250IGltcG9ydCBGVDJG
b250CmltcG9ydCB1bmljb2RlZGF0YQoKIyBQYXRoIHRvIGEgVHlwZTEgZm9udApmaWxlbmFtZSA9
IHInYzpcdGV4bWZcZm9udHNcdHlwZTFcYmx1ZXNreVxzeW1ib2xzXG1zYW0xMC5wZmInCgpmID0g
RlQyRm9udChmaWxlbmFtZSkKaW5kZXhlcyA9IGYuZ2V0X2NoYXJtYXAoKQpmb3IgaW5kZXgsIHVu
aSBpbiBpbmRleGVzLml0ZW1zKCk6CiAgICB0cnk6CiAgICAgICAgbmFtZSA9IHVuaWNvZGVkYXRh
Lm5hbWUodW5pY2hyKHVuaSkpCiAgICBleGNlcHQgVmFsdWVFcnJvcjoKICAgICAgICBuYW1lID0g
Tm9uZQogICAgcHJpbnQgZi5nZXRfZ2x5cGhfbmFtZShpbmRleCksIGluZGV4LCBuYW1lLCByZXBy
KHVuaWNocih1bmkpKQoKd2hpY2ggb3V0cHV0cwoKc3BhY2UgMTI4IFNQQUNFIHUnICcKZGlhbW9u
ZCA2IEJMQUNLIERJQU1PTkQgU1VJVCB1J1x1MjY2NicKdGhlcmVmb3JlIDQxIFRIRVJFRk9SRSB1
J1x1MjIzNCcKYmVjYXVzZSA0MiBCRUNBVVNFIHUnXHUyMjM1JwptdWNobGVzcyAxMTAgTVVDSCBM
RVNTLVRIQU4gdSdcdTIyNmEnCm11Y2hncmVhdGVyIDExMSBNVUNIIEdSRUFURVItVEhBTiB1J1x1
MjI2YicKZGJsYXJyb3dsZWZ0IDE4IExFRlQgUklHSFQgRE9VQkxFIEFSUk9XIHUnXHUyMWQ0Jwpk
YmxhcnJvd3JpZ2h0IDE5IFJJR0hUV0FSRFMgRE9VQkxFIEFSUk9XIHUnXHUyMWQyJwpsZXNzb3Jn
cmVhdGVyIDU1IExFU1MtVEhBTiBPUiBHUkVBVEVSLVRIQU4gdSdcdTIyNzYnCmdyZWF0ZXJvcmxl
c3MgNjMgR1JFQVRFUi1USEFOIE9SIExFU1MtVEhBTiB1J1x1MjI3NycKYW5nbGUgOTIgQU5HTEUg
dSdcdTIyMjAnCnByb3BvcnRpb25hbCA5NSBQUk9QT1JUSU9OQUwgVE8gdSdcdTIyMWQnCgptc2Ft
MTAgZm9udCB3YXMgdXNlZCBpbiB0aGUgYWJvdmUgY29kZSwgYnV0IG90aGVyIGZvbnRzIGJlaGF2
ZSBzaW1pbGFybHkuCgpVbmZvcnR1bmF0ZWx5IHRoZSBtb3N0IGltcG9ydGFudCBmdW5jdGlvbiBp
biBGVDJGb250IGNsYXNzCgpmLmdldF9nbHlwaChpbmRleCkKCnJhaXNlcwoKVmFsdWVFcnJvcjog
R2x5cGggaW5kZXggb3V0IG9mIHJhbmdlCgpmb3IgVHlwZTEgZm9udHMsIGJ1dCBJIHRoaW5rIHRo
YXQgdGhpcyBjb3VsZCBiZSBlYXNpbHkgZml4ZWQuCgpDdXJyZW50IEMrKyBjb2RlIGZvciBnZXRf
Z2x5cGg6CmNoYXIgRlQyRm9udDo6Z2V0X2dseXBoX19kb2NfX1tdID0KImdldF9nbHlwaChudW0p
XG4iCiJcbiIKIlJldHVybiB0aGUgZ2x5cGggb2JqZWN0IHdpdGggbnVtIG51bVxuIgo7ClB5OjpP
YmplY3QKRlQyRm9udDo6Z2V0X2dseXBoKGNvbnN0IFB5OjpUdXBsZSAmIGFyZ3MpewogIF9WRVJC
T1NFKCJGVDJGb250OjpnZXRfZ2x5cGgiKTsKCiAgYXJncy52ZXJpZnlfbGVuZ3RoKDEpOwogIGlu
dCBudW0gPSBQeTo6SW50KGFyZ3NbMF0pOwoKICBpZiAoIChzaXplX3QpbnVtID49IGdtcy5zaXpl
KCkpCiAgICB0aHJvdyBQeTo6VmFsdWVFcnJvcigiR2x5cGggaW5kZXggb3V0IG9mIHJhbmdlIik7
CgogIC8vdG9kbzogcmVmY291bnQ/CiAgcmV0dXJuIFB5Ojphc09iamVjdChnbXNbbnVtXSk7Cn0K
ClRoZSBwcm9ibGVtIHdpdGggdGhpcyBzb2x1dGlvbiAoaWYgd2UgZ2V0IGdldF9nbHlwaCB0byB3
b3JrIHdpdGgKVHlwZTEpIGNvdWxkIGJlIHRoZSBiYWNrZW5kcy4gQWdnIHdvdWxkbid0IGhhdmUg
dG8gY2hhbmdlIG11Y2ggKGlmIGF0CmFsbCksIGJ1dCBJIGRvbid0IGtub3cgYWJvdXQgdGhlIFBT
IGFuZCBTVkcgYmFja2VuZHMuIFR5cGUgMSBmb250cyBhcmUKaW5zdGFsbGFibGUgb24gYm90aCB3
aW5kb3dzICh2aWEgLnBmbSBmaWxlcykgYW5kIFVuaXggc3lzdGVtcywgc28gSQpndWVzcyBTVkcg
ZmlsZXMgY291bGQgYmUgdmlld2VkL2NoYW5nZWQgd2l0aG91dCBtdWNoIGhhc3NsZSwgYW5kIHRo
ZQpQUyBiYWNrZW5kIGNvdWxkIGJlIGNoYW5nZWQgYSBiaXQgdG8gc3VwcG9ydCBUeXBlMSBmb250
cy4KCkFsc28sIGFsbCB0aGUgY2hhcmFjdGVycyBhcmUgc3ByZWFkIGFyb3VuZCBpbiBhIHByZXR0
eSBsYXJnZSBudW1iZXIgb2YKZmlsZXMsIGJ1dCBJIHN1cHBvc2UgdGhhdCB3aXRoIGEgbGl0dGxl
IGNvZGUgdGhpcyBjYW4gYmUgc3VycGFzc2VkLgoKVW5pY29kZSBwcm9ibGVtcwo9PT09PT09PT09
PT09ClRoZSBmb2xsb3dpbmcgaXMgYXNzZW1ibGVkIGZyb20gdGhlIHJlcG9ydCDCuCJVbmljb2Rl
IFN1cHBvcnQgZm9yCk1hdGhlbWF0aWNzIiwgd2hpY2ggaXMgdGhlIGZpcnN0IHNvdXJjZSBvZiBp
bmZvcm1hdGlvbiByZWdhcmRpbmcKbWF0aGVtYXRpY3MgYW5kIFVuaWNvZGUuCgpUaGUgYmlnZ2Vz
dCBwcm9ibGVtIHdpdGggKnByb3BlciogbWF0aCBVbmljb2RlIGFyZSB0aGUgIk1hdGhlbWF0aWNh
bApBbHBoYW51bWVyaWMgU3ltYm9scyIsIHdoaWNoIGFyZSBmb3VuZCBpbiB0aGUgMUQ0MDAuLjFE
N0ZGIHJhbmdlLCBub3QKaW4gdGhlIEJhc2ljIE11bHRpbGluZ3VhbCBQbGFuZS4gVGhlc2UgYXJl
IG5vdCBmb3VuZCBpbiBhbnkgZnJlZSBmb250LgpJIGFsc28gbm90aWNlZCB0aGF0IFB5dGhvbidz
IHN1cHBvcnQgZm9yIFVuaWNvZGUgb3V0c2lkZSB0aGUgQk1QIHBsYW5lCmlzIG5vdCB2ZXJ5IGdv
b2QuIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSB3b3JrcyBvbiBMaW51eCAoVWJ1bnR1IDYuMDYpLApi
dXQgZG9lc24ndCB3b3JrIG9uIFdpbmRvd3MgWFAgKDMyKToKCj4+PiBpbXBvcnQgdW5pY29kZWRh
dGEKPj4+IHVuaWNvZGVkYXRhLm5hbWUoVSdVXFUwMDAxZDQwMCcpClRyYWNlYmFjayAobW9zdCBy
ZWNlbnQgY2FsbCBsYXN0KToKICBGaWxlICI8c3RkaW4+IiwgbGluZSAxLCBpbiA/ClR5cGVFcnJv
cjogbmVlZCBhIHNpbmdsZSBVbmljb2RlIGNoYXJhY3RlciBhcyBwYXJhbWV0ZXIKClRoZSBvdXRw
dXQgc2hvdWxkIHNheToKTUFUSEVNQVRJQ0FMIEJPTEQgQ0FQSVRBTCBBCgpUaGUgIk1hdGhlbWF0
aWNhbCBBbHBoYW51bWVyaWMgU3ltYm9scyIgYmxvY2sgY29udGFpbnM6CiAqIE1hdGhlbWF0aWNh
bCBib2xkIGxldHRlcnMKICogTWF0aGVtYXRpY2FsIGl0YWxpYyBsZXR0ZXJzICh1c2VkIGZvciB2
YXJpYWJsZXMsIGRlZmF1bHQgZm9udCBpbgpUZVggbWF0aCBtb2RlKQogKiBNYXRoZW1hdGljYWwg
Ym9sZCBpdGFsaWMgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgc2NyaXB0IChjYWxsaWdyYXBoaWMp
IGxldHRlcnMKICogTWF0aGVtYXRpY2FsIGJvbGQgc2NyaXB0IGxldHRlcnMKICogTWF0aGVtYXRp
Y2FsIGZyYWt0dXIgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgZG91YmxlLXN0cnVjayBsZXR0ZXJz
CiAqIE1hdGhlbWF0aWNhbCBib2xkIGZyYWt0dXIgbGV0dGVycwogKiBNYXRoZW1hdGljYWwgc2Fu
cy1zZXJpZiBsZXR0ZXJzCiAqIE1hdGhlbWF0aWNhbCBzYW5zLXNlcmlmIGJvbGQgbGV0dGVycwog
KiBNYXRoZW1hdGljYWwgc2Fucy1zZXJpZiBpdGFsaWMgbGV0dGVycwogKiBNYXRoZW1hdGljYWwg
c2Fucy1zZXJpZiBib2xkIGl0YWxpYyBsZXR0ZXJzCiAqIE1hdGhlbWF0aWNhbCBtb25vc3BhY2Ug
bGV0dGVycwogKiBEb3RsZXNzIHN5bWJvbHMKICogQm9sZCBHcmVlayBzeW1ib2xzCiAqIEFkZGl0
aW9uYWwgYm9sZCBHcmVlayBzeW1ib2xzCiAqIEl0YWxpYyBHcmVlayBzeW1ib2xzCiAqIEFkZGl0
aW9uYWwgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogQm9sZCBpdGFsaWMgR3JlZWsgc3ltYm9scwog
KiBBZGRpdGlvbmFsIGJvbGQgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogU2Fucy1zZXJpZiBib2xk
IEdyZWVrIHN5bWJvbHMKICogU2Fucy1zZXJpZiBib2xkIGl0YWxpYyBHcmVlayBzeW1ib2xzCiAq
IEFkZGl0aW9uYWwgc2Fucy1zZXJpZiBib2xkIEdyZWVrIHN5bWJvbHMKICogQWRkaXRpb25hbCBz
YW5zLXNlcmlmIGJvbGQgaXRhbGljIEdyZWVrIHN5bWJvbHMKICogQm9sZCBkaWdpdHMKICogRG91
YmxlLXN0cnVjayBkaWdpdHMKICogU2Fucy1zZXJpZiBkaWdpdHMKICogU2Fucy1zZXJpZiBib2xk
IGRpZ2l0cwogKiBNb25vc3BhY2UgZGlnaXRzCgpUaGVzZSB3ZXJlIGFsbCBwdXQgaW4gdGhlIFVu
aWNvZGUgY2hhcmFjdGVyIHNldCBiZWNhdXNlIG9mIHRoZWlyCnNlbWFudGljIG1lYW5pbmdzIGlu
IG1hdGhlbWF0aWNzLCBhbHRob3VnaCBwcmFjdGljYWxseSBhbGwgYXJlIGp1c3QKZm9udCB2YXJp
YXRpb25zICg8Zm9udD4pLiBUaGUgcm9tYW4gbWF0aCBsZXR0ZXJzIChzZXJpZiwgbm9ybWFsLCB1
c2VkCmZvciBkaWdpdHMpIGRlZmF1bHQgdG8gdGhlICJCYXNpYyBMYXRpbiIgYmxvY2suCgpJdCBp
cyBpbnRlcmVzdGluZyB0byBub3RlIHRoYXQgdGhlICJNYXRoZW1hdGljYWwgQWxwaGFudW1lcmlj
IFN5bWJvbHMiCmJsb2NrIGRvZXNuJ3Qgc2VlbSB0byBiZSBzdXBwb3J0ZWQgYnksIGZvciBleGFt
cGxlLCBBcmlhbCBVbmljb2RlIE1TCihpdCBzdXBwb3J0cyBvbmx5IHRoZSBCTVApLgoKVGhpcyBp
c3N1ZSBjYW5ub3QgYmUgc3VjY2Vzc2Z1bGx5IHNvbHZlZCB1bnRpbCB0aGUgU1RJWCBmb250cyBj
b21lCm91dC4gSWYgdGhleSBwYWNrYWdlIHRoZW0gcmlnaHQgKGFuZCB0aGV5IG91Z2h0IHRvKSwg
d2UgY291bGQgaGF2ZSBhCnNpbmdsZSAudHRmIGZpbGUgZm9yIGFsbCB0aGUgZ2x5cGhzIG5lZWRl
ZCBmb3IgbWF0aHRleHQuIFVudGlsIHRoZW4sCmFueSBzb2x1dGlvbiB3aWxsIG5lZWQgc29tZSBz
b3J0IG9mIG1hcHBpbmcgYmV0d2VlbiB1bmljb2RlIGJsb2NrcwooY2hhcmFjdGVyIHJhbmdlcykg
YW5kIGZvbnRmaWxlcyAoYXQgbGVhc3QgZm9yIGl0YWxpYywgY2FsbGlncmFwaGljCmV0Yy4gZm9u
dHMpCgpQb3NzaWJsZSBlbmhhbmNlbWVudHMKPT09PT09PT09PT09PT09PT0KSSB0aGluayB0aGVy
ZSBzaG91bGQgYmUgYSB0aGluIFB5dGhvbiB3cmFwcGVyIGFyb3VuZCB0aGUgRnJlZVR5cGUyCkZU
MkZvbnQgY2xhc3MuIFRoZW4sIGZvciBleGFtcGxlLCBhbGwgdGhlIGNhY2hpbmcgY291bGQgYmUg
aGFuZGxlZCBieQp0aGF0IGNsYXNzLiBUaGlzIHdvdWxkIGFsbG93IG5vdCBvbmx5IGNhY2hpbmcg
Zm9yIG1hdGh0ZXh0LCBidXQgZXZlbgpmb3IgKnBsYWluIHRleHQqIGFuZCB3b3VsZCBjbGVhbiB1
cCBjb2RlLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgYWRkaW5nCm5ldyBmdW5jdGlvbmFsaXR5LCB3
aXRob3V0IG1lc3NpbmcgYXJvdW5kIHdpdGggQysrLCBhbmQgd2l0aG91dApicmVha2luZyBvbGQg
Y29kZS4KCk9uZSBjb3VsZCB0aGVuLCBmb3IgZXhhbXBsZSwgaGF2ZSBhIEZUMkZvbnQgY2xhc3Mg
bWV0aG9kCmdldF91bmljb2RlX2dseXBoIHRoYXQgd291bGQgcmV0dXJuIHRoZSBnbHlwaCBiYXNl
ZCBvbiBoaXMgdW5pY29kZQppbmRleCwgb3IgYmV0dGVyIHlldCwgdGhlIG5leHQgY29kZSB3b3Vs
ZCBiZSBlYXN5IGltcGxlbWVudGFibGU6CmdseXBocyA9IEZUMkZvbnQoJy9wYXRoL3RvL2ZvbnQn
KQpnbHlwaGEgPSBnbHlwaHNbJ2EnXQoKb3IgZXZlbjoKdGV4dF90b19yZW5kZXIgPSBnbHlwaHMu
dGV4dCgnU29tZSBsYW1lIHRleHQnKQoKb3Igc29tZXRoaW5nIHNpbWlsYXIuIEFnYWluLCB0aGlz
IHdvdWxkIG5vdCBicmVhayBvbGQgY29kZSBhbmQgd291bGQKZWFzZSB3cml0aW5nIG5ldyBjb2Rl
LiBIb3dldmVyLCBhcyBKb2huIG9uY2Ugc2FpZDoKClRoZSBmb250IGxpYnJhcnkgaXMgcHJvYmFi
bHkgYW4gU09DIHByb2plY3Qgb2YKaXQncyBvd24sIGJlY2F1c2Ugd2Ugd291bGQgbGlrZSB0byBz
ZXR0bGUgb24gb25lIGZyZWV0eXBlIGxpYnJhcnkgdGhhdApib3RoIG1hdHBsb3RsaWIgYW5kIGVu
dGhvdWdodC9jaGFjbyBjYW4gdXNlLiBIb3cgdG8gZGVhbCB3aXRoIHRoaXMKaXNzdWUgd2l0aG91
dCBiZWNvbWluZyBjb25zdW1lZCBieSBpdCB3aWxsIHJlcXVpcmUgc29tZSB0aG91Z2h0LgoKQ29u
Y2x1c2lvbgo9PT09PT09PQpKb2huLCB3aGF0IHNob3VsZCBJIGRvPyBQbGVhc2UgY29tbWVudC4K
CkkgdGhpbmsgdGhhdCB0aGUgYmVzdCBzb2x1dGlvbiByaWdodCBub3cgYXJlIHVuZm9ydHVuYXRl
bHkgdGhlIEJhS29NYQpmb250cy4gSWYgd2UgY291bGQgZ2V0IHRoZSBUeXBlMSBmb250cyB0byB3
b3JrIHRoZW4gSSBjb3VsZCBwcm9iYWJseQplYXNpbHkgaW5nZWdyYXRlIHRoZW0gaW50byB0aGUg
ZXhpc3RpbmcgbW9kZWwuIEkgY291bGQgYWxzbyB0cnkgdG8gZG8Kc29tZXRoaW5nIHdpdGggdGhl
IE9wZW4gU3ltYm9sIGZvbnRzLCBhbmQgdGhlIEZyZWVGb250ICh3aW5kb3dzIHVzZXJzCmNvdWxk
IGRvd2xvYWQgdGhlbSBzZXBwYXJhdGVseSkuCgpDaGVlcnMsCkVkaW4K

On 7/7/06, John Hunter <jdh...@ac...> wrote:
>
> We'd like to do a bugfix release for the next release of enthought
> python, which will include the latest mpl. Apparently, there is a
> problem with 0.87.3 and numpy which has been fixed in svn.
>
> If there is anything we should wait on, let us know, otherwise we'll
> probably try to roll out 0.87.4 early next week.
>
> Thanks,
> JDH
http://cheeseshop.python.org/pypi/matplotlib/
http://sourceforge.net/project/showfiles.php?group_id=80706
===============================================================
2006年07月11日 Released 0.87.4 at revision 2558
2006年07月07日 Fixed a usetex bug with older versions of latex - DSD
2006年07月07日 Add compatibility for NumPy 1.0 - TEO
2006年06月29日 Added a Qt4Agg backend. Thank you James Amundson - DSD
2006年06月26日 Fixed a usetex bug. On windows, usetex will prcess
 postscript output in the current directory rather than
 in a temp directory. This is due to the use of spaces
 and tildes in windows paths, which cause problems with
 latex. The subprocess module is no longer used. - DSD
2006年06月22日 Various changes to bar(), barh(), and hist().
 Added 'edgecolor' keyword arg to bar() and barh().
 The x and y args in barh() have been renamed to width
 and bottom respectively, and their order has been swapped
 to maintain a (position, value) order ala matlab. left,
 height, width and bottom args can now all be scalars or
 sequences. barh() now defaults to edge alignment instead
 of center alignment. Added a keyword arg 'align' to bar(),
 barh() and hist() that controls between edge or center bar
 alignment. Fixed ignoring the rcParams['patch.facecolor']
 for bar color in bar() and barh(). Fixed ignoring the
 rcParams['lines.color'] for error bar color in bar()
 and barh(). Fixed a bug where patches would be cleared
 when error bars were plotted if rcParams['axes.hold']
 was False. - MAS
2006年06月22日 Added support for numerix 2-D arrays as alternatives to
 a sequence of (x,y) tuples for specifying paths in
 collections, quiver, contour, pcolor, transforms.
 Fixed contour bug involving setting limits for
 color mapping. Added numpy-style all() to numerix. - EF
2006年06月20日 Added custom FigureClass hook to pylab interface - see
 examples/custom_figure_class.py
2006年06月16日 Added colormaps from gist (gist_earth, gist_stern,
 gist_rainbow, gist_gray, gist_yarg, gist_heat, gist_ncar) - JW
2006年06月16日 Added a pointer to parent in figure canvas so you can
 access the container with fig.canvas.manager. Useful if
 you want to set the window title, eg in gtk
 fig.canvas.manager.window.set_title, though a GUI neutral
 method would be preferable JDH
2006年06月16日 Fixed colorbar.py to handle indexed colors (i.e.,
 norm = no_norm()) by centering each colored region
 on its index. - EF
2006年06月15日 Added scalex and scaley to Axes.autoscale_view to support
 selective autoscaling just the x or y axis, and supported
 these command in plot so you can say plot(something,
 scaley=False) and just the x axis will be autoscaled.
 Modified axvline and axhline to support this, so for
 example axvline will no longer autoscale the y axis. JDH
2006年06月13日 Fix so numpy updates are backward compatible - TEO
2006年06月12日 Updated numerix to handle numpy restructuring of
 oldnumeric - TEO
2006年06月12日 Updated numerix.fft to handle numpy restructuring
 Added ImportError to numerix.linear_algebra for numpy -TEO
2006年06月11日 Added quiverkey command to pylab and Axes, using
 QuiverKey class in quiver.py. Changed pylab and Axes
 to use quiver2 if possible, but drop back to the
 newly-renamed quiver_classic if necessary. Modified
 examples/quiver_demo.py to illustrate the new quiver
 and quiverkey. Changed LineCollection implementation
 slightly to improve compatibility with PolyCollection. - EF
2006年06月11日 Fixed a usetex bug for windows, running latex on files
 with spaces in their names or paths was failing - DSD
2006年06月09日 Made additions to numerix, changes to quiver to make it
 work with all numeric flavors. - EF
2006年06月09日 Added quiver2 function to pylab and method to axes,
 with implementation via a Quiver class in quiver.py.
 quiver2 will replace quiver before the next release;
 it is placed alongside it initially to facilitate
 testing and transition. See also
 examples/quiver2_demo.py. - EF
2006年06月08日 Minor bug fix to make ticker.py draw proper minus signs
 with usetex - DSD

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>>>>> 
>>>>>>
>
> Eric> Correction: I did fix the first problem, and the second
> Eric> problem is not at all what I thought. Instead, the
> Eric> examples/data/lena.jpg file in my svn mpl directory is
> Eric> corrupted. I have no idea why. Looking directly at the
>
>This usually happens whenever Andrew commits -- don't know why
>(platform dependent new line problem, perhaps?)
>
>peds-pc311:~/mpl> svn log | grep astraw|head
>r2480 | astraw | 2006年06月15日 06:33:07 -0500 (2006年6月15日) | 1 line
>r2430 | astraw | 2006年06月06日 15:12:33 -0500 (2006年6月06日) | 1 line
>r2279 | astraw | 2006年04月10日 10:35:31 -0500 (2006年4月10日) | 3
>lines
>r2180 | astraw | 2006年03月20日 15:38:12 -0600 (2006年3月20日) | 1 line
>
> 
>
Hmm -- "usually happens"? I never noticed that. And I'm mystified as to
whether the output of svn log shows that. Let me know if I play any more
evil-line-ending tricks.
Anyhow, I think I fixed the corrupted file issue. I changed the deleted
the svn:eol-style property and added the set svn:mime-type property to
image/jpg and re-uploaded lena.jpg. I suspect this may have been a
victim of the cvs2svn switch, or perhaps I never checked it into cvs
properly.
Cheers!
Andrew

On 7/11/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
> Eric> Correction: I did fix the first problem, and the second
> Eric> problem is not at all what I thought. Instead, the
> Eric> examples/data/lena.jpg file in my svn mpl directory is
> Eric> corrupted. I have no idea why. Looking directly at the
>
> This usually happens whenever Andrew commits -- don't know why
> (platform dependent new line problem, perhaps?)
Is that file tagged as binary in the repo? If it is, it should be
impervious to OS-dependent EOL conventions...
Cheers,
f

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Correction: I did fix the first problem, and the second
 Eric> problem is not at all what I thought. Instead, the
 Eric> examples/data/lena.jpg file in my svn mpl directory is
 Eric> corrupted. I have no idea why. Looking directly at the
This usually happens whenever Andrew commits -- don't know why
(platform dependent new line problem, perhaps?)
peds-pc311:~/mpl> svn log | grep astraw|head
r2480 | astraw | 2006年06月15日 06:33:07 -0500 (2006年6月15日) | 1 line
r2430 | astraw | 2006年06月06日 15:12:33 -0500 (2006年6月06日) | 1 line
r2279 | astraw | 2006年04月10日 10:35:31 -0500 (2006年4月10日) | 3
lines
r2180 | astraw | 2006年03月20日 15:38:12 -0600 (2006年3月20日) | 1 line
JDH

Eric Firing wrote:
> Andrew Straw wrote:
> 
> 
>>Actually, this has been in MPL for a while. For example, see the
>>image_demo3.py example. You don't need the __array_interface__ for this
>>bit of functionality.
> 
> 
> It's broken.
> 
> The first problem is that the kw "aspect = 'preserve'" is no longer 
> needed or supported. Removing that (as I will do in svn shortly), I get 
> a somewhat scrambled image.
Correction: I did fix the first problem, and the second problem is not 
at all what I thought. Instead, the examples/data/lena.jpg file in my 
svn mpl directory is corrupted. I have no idea why. Looking directly 
at the version on svn via the svn browser, I see that it is corrupted also.
Eric

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> Last I checked if I recall correctly, about a year ago, the
 John> PS backend merely dumped a raster image and didn't do real
 John> vector graphics. Has this changed?
Looks like it has:
 http://lwn.net/Articles/189905

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
 Christopher> Just as a note, if you have Cairo, you have PS, PDF,
 Christopher> SVG, raster, and, indeed, native draw-to-the-screen
 Christopher> functionality.
Last I checked if I recall correctly, about a year ago, the PS backend
merely dumped a raster image and didn't do real vector graphics. Has
this changed?
JDH

John Hunter wrote:
> I've talked with Eric Jones many times about the desirability
> of sharing a single low-level drawing model, probably based on
> PDF/KIVA, that have backends for PS, SVG, PDF and one raster format
> (eg Agg or Cairo). 
Just as a note, if you have Cairo, you have PS, PDF, SVG, raster, and, 
indeed, native draw-to-the-screen functionality.
They're not all robust and complete, but it's seeing a lot of 
development. A robust, numpy-aware PyCairo would be really nice.
In short, Cairo has essentially the same goals (plus a few more) as 
Kiva, except it's written in C. There's some discussion of using it in 
wxWidgets, and, of course, it's already used in newer GTKs.
-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...

Yes, this has been fixed.
Mark Bakker wrote:
> Sorry to bother you again, but I recently upgraded from 0.87.2 to 
> 0.87.3, and
> cannot save eps files anymore. I get a 'subprocess' error.
> I am running Python 2.3, mpl 0.87.3, and TkAgg (although that 
> shouldn't matter).
> Error occurs whether using toolbar or savefig to save.
> Here's the script and the errror. Has this been fixed in svn?
>
> >>> from pylab import *
> >>> plot([1,2,3])
> [<matplotlib.lines.Line2D instance at 0x01B50418>]
> >>> savefig('c:/temp/test.eps')
> Traceback (most recent call last):
> File "<pyshell#2>", line 1, in ?
> savefig('c:/temp/test.eps')
> File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 811, 
> in savefig
> return fig.savefig(*args, **kwargs)
> File "C:\Python23\Lib\site-packages\matplotlib\figure.py", line 660, 
> in savefig
> self.canvas.print_figure(*args, **kwargs)
> File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
> line 184, in print_figure
> agg.print_figure(filename, dpi, facecolor, edgecolor, orientation,
> File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py", 
> line 481, in print_figure
> from backend_ps import FigureCanvasPS # lazy import
> File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_ps.py", 
> line 10, in ?
> from subprocess import Popen, STDOUT, PIPE
> ImportError: No module named subprocess
> ------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Sorry to bother you again, but I recently upgraded from 0.87.2 to 0.87.3,
and
cannot save eps files anymore. I get a 'subprocess' error.
I am running Python 2.3, mpl 0.87.3, and TkAgg (although that shouldn't
matter).
Error occurs whether using toolbar or savefig to save.
Here's the script and the errror. Has this been fixed in svn?
>>> from pylab import *
>>> plot([1,2,3])
[<matplotlib.lines.Line2D instance at 0x01B50418>]
>>> savefig('c:/temp/test.eps')
Traceback (most recent call last):
 File "<pyshell#2>", line 1, in ?
 savefig('c:/temp/test.eps')
 File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 811, in
savefig
 return fig.savefig(*args, **kwargs)
 File "C:\Python23\Lib\site-packages\matplotlib\figure.py", line 660, in
savefig
 self.canvas.print_figure(*args, **kwargs)
 File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 184, in print_figure
 agg.print_figure(filename, dpi, facecolor, edgecolor, orientation,
 File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 481, in print_figure
 from backend_ps import FigureCanvasPS # lazy import
 File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_ps.py",
line 10, in ?
 from subprocess import Popen, STDOUT, PIPE
ImportError: No module named subprocess

>>>>> "Robert" == Robert Hetland <rhe...@ma...> writes:
 Robert> I'm not suggesting immediate development for a PDF backend
 Robert> (although if it came automatically with kiva, I would use
 Robert> it), I think eps +ghostscript is good enough for now.
As you may know, we have a prototype of a PDF backend, though it is
missing many features.
JDH

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> The weird thing is that this used to work fine in the past.
 Mark> At least, I am pretty sure it did. Then again, I am
 Mark> watching the Worlcup final at this time. So a significant
 Mark> part of my brain is doing something else, Mark
At some point, we upgraded our tk filesave dialog to use the more
modern one. We could always revert to the old one, which would
likely fix this but let's give it a day and see if we can't have the
best of both worlds. Hopefully, the effbot will pick up on my c.l.py
post...
JDH

The weird thing is that this used to work fine in the past.
At least, I am pretty sure it did.
Then again, I am watching the Worlcup final at this time.
So a significant part of my brain is doing something else,
Mark
On 7/9/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> John was asking whether there was something left to be fixed
> Mark> befor 0.88. In 0.87.3, there is still a bug left that has
> Mark> been reported several times I think.
>
> Interesting. the tk ask file dialog seems to be triggering a destgroy
> event on the main window, which removes it from mpl figure
> management. Here is a minimal Tk script which exposes the problem.
> When you press the mouse button, you get a file dialog that when you
> close it triggers a destroy event and calls the callback function
>
> I don't know if this is a tk bug or if we are misusing the Tk code.
> Tk experts?
>
>
> I'll post on python-list.
>
> JDH
>
> import Tkinter as Tk
> from tkFileDialog import asksaveasfilename
>
> def button(event):
> fname = asksaveasfilename(
> title='Save the figure'
> )
>
>
>
>
> window = Tk.Tk()
> frame = Tk.Frame(window, width=500,height=500)
> frame.bind('<Button-1>', button)
> frame.pack()
>
>
> def callback(*args):
> print 'called callback'
> window.bind("<Destroy>", callback)
>
> window.mainloop()
>
>
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> John was asking whether there was something left to be fixed
 Mark> befor 0.88. In 0.87.3, there is still a bug left that has
 Mark> been reported several times I think.
Interesting. the tk ask file dialog seems to be triggering a destgroy
event on the main window, which removes it from mpl figure
management. Here is a minimal Tk script which exposes the problem.
When you press the mouse button, you get a file dialog that when you
close it triggers a destroy event and calls the callback function
I don't know if this is a tk bug or if we are misusing the Tk code.
Tk experts?
I'll post on python-list.
JDH
import Tkinter as Tk
from tkFileDialog import asksaveasfilename
def button(event):
 fname = asksaveasfilename(
 title='Save the figure'
 )
 
window = Tk.Tk()
frame = Tk.Frame(window, width=500,height=500)
frame.bind('<Button-1>', button)
frame.pack()
def callback(*args):
 print 'called callback'
window.bind("<Destroy>", callback)
window.mainloop()

On 7/9/06, Mark Bakker <ma...@gm...> wrote:
> John was asking whether there was something left to be fixed befor 0.88.
> In 0.87.3, there is still a bug left that has been reported several times I
> think.
>
> In interactive mode on TkAgg, after solving by clicking on the 'save' button
> in toolbar2,
> mpl loses its knowledge of the figure. Any plotting statement given after
> that
> creates a new figure, rather than add to the existing one. I wish I knew how
> to fix this.
> I am (still, but not much longer) running Python 2.3, but I think Fernando
> reported
> the bug in Python 2.4 as well.
Confirmed: bug is still there, with current SVN mpl under python2.4.
Cheers,
f

John was asking whether there was something left to be fixed befor 0.88.
In 0.87.3, there is still a bug left that has been reported several times I
think.
In interactive mode on TkAgg, after solving by clicking on the 'save' button
in toolbar2,
mpl loses its knowledge of the figure. Any plotting statement given after
that
creates a new figure, rather than add to the existing one. I wish I knew how
to fix this.
I am (still, but not much longer) running Python 2.3, but I think Fernando
reported
the bug in Python 2.4 as well.
Thanks,
Mark

On Saturday 08 July 2006 10:28 am, Darren Dale wrote:
> On Friday 07 July 2006 6:45 pm, Fernando Perez wrote:
> > On 7/7/06, Jeff Whitaker <js...@fa...> wrote:
> > > John: setupext.py in svn 2545 uses numpy.get_include(), which
> > > apparently is not available in 0.9.8. In 0.9.8, it's
> > > get_numpy_include().
> >
> > And in current numpy, get_numpy_include fires a deprecation warning (I
> > just fixed this in my code). Such are the joys of living on the
> > bleeding edge :)
>
> Sorry, I was the one who changed get_numpy_include to get_include. I guess
> I was thinking that anyone who is using svn mpl would also be using svn
> numpy. Should I change it back to get_numpy_include?
This is fixed in svn. I wrapped get_include in a try statement for the time 
being, get_numpy_include gets called in the event of an attribute error.
Darren

On Friday 07 July 2006 6:45 pm, Fernando Perez wrote:
> On 7/7/06, Jeff Whitaker <js...@fa...> wrote:
> > John: setupext.py in svn 2545 uses numpy.get_include(), which
> > apparently is not available in 0.9.8. In 0.9.8, it's
> > get_numpy_include().
>
> And in current numpy, get_numpy_include fires a deprecation warning (I
> just fixed this in my code). Such are the joys of living on the
> bleeding edge :)
Sorry, I was the one who changed get_numpy_include to get_include. I guess I 
was thinking that anyone who is using svn mpl would also be using svn numpy. 
Should I change it back to get_numpy_include?