matplotlib-devel Mailing List for matplotlib

SGkgYWxsLAoKSXMgaXQgdGhhdCB0aGUgY29kZSBpbiB0aGUgbWF0aHRleHQgbW9kdWxlIGxvb2tz
IHVnbHkgb3IgaXMgaXQganVzdCBtZQpub3QgdW5kZXJzdGFuZGluZyBpdD8KQWxzbywgaWYgYW55
b25lIGhhcyBzb21lIGdvb2Qgb25saW5lIHNvdXJjZXMgYWJvdXQgcGFyc2luZyBldGMuIG9uIHRo
ZQpuZXQsIEkgdndvdWxkIHJlYWx5IGFwcHJlY2lhdGUgaXQuCgpDb25zaWRlcmluZyB0aGUgZm9s
b3dpbmcgY29kZSAocGlja2VkIG9uIHJhbmRvbSwgZnJvbSBtYXRodGV4dC5weSkKCj09PQpkZWYg
bWF0aF9wYXJzZV9zX2Z0MmZvbnQocywgZHBpLCBmb250c2l6ZSwgYW5nbGU9MCk6CiAgICAiIiIK
ICAgIFBhcnNlIHRoZSBtYXRoIGV4cHJlc3Npb24gcywgcmV0dXJuIHRoZSAoYmJveCwgZm9udHMp
IHR1cGxlIG5lZWRlZAogICAgdG8gcmVuZGVyIGl0LgoKICAgIGZvbnRzaXplIG11c3QgYmUgaW4g
cG9pbnRzCgogICAgcmV0dXJuIGlzIHdpZHRoLCBoZWlnaHQsIGZvbnRzCiAgICAiIiIKCiAgICBt
YWpvciwgbWlub3IxLCBtaW5vcjIsIHRtcCwgdG1wID0gc3lzLnZlcnNpb25faW5mbwogICAgaWYg
bWFqb3I9PTIgYW5kIG1pbm9yMT09MjoKICAgICAgICByYWlzZSBTeXN0ZW1FeGl0KCdtYXRodGV4
dCBicm9rZW4gb24gcHl0aG9uMi4yLiAgV2UgaG9wZSB0bwpnZXQgdGhpcyBmaXhlZCBzb29uJykK
CiAgICBjYWNoZUtleSA9IChzLCBkcGksIGZvbnRzaXplLCBhbmdsZSkKICAgIHMgPSBzWzE6LTFd
ICAjIHN0cmlwIHRoZSAkIGZyb20gZnJvbnQgYW5kIGJhY2sKICAgIGlmIG1hdGhfcGFyc2Vfc19m
dDJmb250LmNhY2hlLmhhc19rZXkoY2FjaGVLZXkpOgogICAgICAgIHcsIGgsIGJmb250cyA9IG1h
dGhfcGFyc2Vfc19mdDJmb250LmNhY2hlW2NhY2hlS2V5XQogICAgICAgIHJldHVybiB3LCBoLCBi
Zm9udHMuZm9udHMudmFsdWVzKCkKCiAgICBiYWtvbWFGb250cyA9IEJha29tYVRydWVUeXBlRm9u
dHMoKQogICAgRWxlbWVudC5mb250cyA9IGJha29tYUZvbnRzCiAgICBoYW5kbGVyLmNsZWFyKCkK
ICAgIGV4cHJlc3Npb24ucGFyc2VTdHJpbmcoIHMgKQoKICAgIGhhbmRsZXIuZXhwci5zZXRfc2l6
ZV9pbmZvKGZvbnRzaXplLCBkcGkpCgogICAgIyBzZXQgdGhlIG9yaWdpbiBvbmNlIHRvIGFsbG93
IHcsIGggY29tcHV0aW9uCiAgICBoYW5kbGVyLmV4cHIuc2V0X29yaWdpbigwLCAwKQogICAgeG1p
biA9IG1pbihbZS54bWluKCkgZm9yIGUgaW4gaGFuZGxlci5zeW1ib2xzXSkKICAgIHhtYXggPSBt
YXgoW2UueG1heCgpIGZvciBlIGluIGhhbmRsZXIuc3ltYm9sc10pCiAgICB5bWluID0gbWluKFtl
LnltaW4oKSBmb3IgZSBpbiBoYW5kbGVyLnN5bWJvbHNdKQogICAgeW1heCA9IG1heChbZS55bWF4
KCkgZm9yIGUgaW4gaGFuZGxlci5zeW1ib2xzXSkKCiAgICAjIG5vdyBzZXQgdGhlIHRydWUgb3Jp
Z2luIC0gZG9lc24ndCBhZmZlY3Qgd2l0aCBhbmQgaGVpZ2h0CiAgICB3LCBoID0gIHhtYXgteG1p
biwgeW1heC15bWluCiAgICAjIGEgc21hbGwgcGFkIGZvciB0aGUgY2FudmFzIHNpemUKICAgIHcg
Kz0gMgogICAgaCArPSAyCgogICAgaGFuZGxlci5leHByLnNldF9vcmlnaW4oMCwgaC15bWF4KQoK
ICAgIEVsZW1lbnQuZm9udHMuc2V0X2NhbnZhc19zaXplKHcsaCkKICAgIGhhbmRsZXIuZXhwci5y
ZW5kZXIoKQogICAgaGFuZGxlci5jbGVhcigpCgogICAgbWF0aF9wYXJzZV9zX2Z0MmZvbnQuY2Fj
aGVbY2FjaGVLZXldID0gdywgaCwgYmFrb21hRm9udHMKICAgIHJldHVybiB3LCBoLCBiYWtvbWFG
b250cy5mb250cy52YWx1ZXMoKQoKbWF0aF9wYXJzZV9zX2Z0MmZvbnQuY2FjaGUgPSB7fQo9PT09
CgpJIGRvbid0IHVuZGVyc3RhbmQsIGZvciBleGFtcGxlLCB3aGF0IGRvZXMgdGhlIHN0YXRlbWVu
dDoKCmV4cHJlc3Npb24ucGFyc2VTdHJpbmcoIHMgKQoKZG8/CgoiZXhwcmVzc2lvbiIgaXMgZGVm
aW5lZCBnbG9iYWx5LCBhbmQgaXMgY2FsbGVkICh0aGF0IGlzIC0gaXRzIG1ldGhvZCkKb25seSBv
bmNlIGluIHRoZSBhYm92ZSBkZWZpbml0aW9uIG9mIHRoZSBmdW5jdGlvbiwgYnV0IEkgZG9uJ3QK
dW5kZXJzdGFuZCAtIHdoYXQgZG9lcyB0aGF0IHBhcnRpY3VsYXIgbGluZSBkbz8hPwoKLS0tLS0t
ClJlZ2FyZGluZyB0aGUgdW5pY29kZSBzdXBwb3J0IGluIG1hdGh0ZXh0LCBtYXRodGV4dCBjdXJy
ZW50bHkgdXNlcyB0aGUKZm9sb3dpbmcgZGljdGlvbmFyeSBmb3IgZ2V0dGluZyB0aGUgZ2x5cGgg
aW5mbyBvdXQgb2YgdGhlIGZvbnQgZmlsZXM6CgpsYXRleF90b19iYWtvbWEgPSB7CgogICAgcidc
b2ludCcgICAgICAgICAgICAgICAgOiAoJ2NtZXgxMCcsICA0NSksCiAgICByJ1xiaWdvZG90JyAg
ICAgICAgICAgICA6ICgnY21leDEwJywgIDUwKSwKICAgIHInXGJpZ29wbHVzJyAgICAgICAgICAg
IDogKCdjbWV4MTAnLCAgNTUpLAogICAgcidcYmlnb3RpbWVzJyAgICAgICAgICAgOiAoJ2NtZXgx
MCcsICA1OSksCiAgICByJ1xzdW0nICAgICAgICAgICAgICAgICA6ICgnY21leDEwJywgIDUxKSwK
ICAgIHInXHByb2QnICAgICAgICAgICAgICAgIDogKCdjbWV4MTAnLCAgMjQpLAouLi4KfQoKSSBt
YW5hZ2VkIHRvIGJ1aWxkIHRoZSBmb2xsb3dpbmcgZGljdGlvbmFyeShsaXR0bGUgbW9yZSBsZWZ0
IHRvIGJlIGRvbmUpOgp0ZXhfdG9fdW5pY29kZSA9IHsKcidcUycgOiB1J1x1MDBhNycsCnInXFAn
IDogdSdcdTAwYjYnLApyJ1xHYW1tYScgOiB1J1x1MDM5MycsCnInXERlbHRhJyA6IHUnXHUwMzk0
JywKcidcVGhldGEnIDogdSdcdTAzOTgnLApyJ1xMYW1iZGEnIDogdSdcdTAzOWInLApyJ1xYaScg
OiB1J1x1MDM5ZScsCnInXFBpJyA6IHUnXHUwM2EwJywKcidcU2lnbWEnIDogdSdcdTAzYTMnLApy
J1xVcHNpbG9uJyA6IHUnXHUwM2E1JywKcidcUGhpJyA6IHUnXHUwM2E2JywKcidcUHNpJyA6IHUn
XHUwM2E4JywKcidcT21lZ2EnIDogdSdcdTAzYTknLApyJ1xhbHBoYScgOiB1J1x1MDNiMScsCnIn
XGJldGEnIDogdSdcdTAzYjInLApyJ1xnYW1tYScgOiB1J1x1MDNiMycsCnInXGRlbHRhJyA6IHUn
XHUwM2I0JywKcidcdmFyZXBzaWxvbicgOiB1J1x1MDNiNScsCnInXHpldGEnIDogdSdcdTAzYjYn
LApyJ1xldGEnIDogdSdcdTAzYjcnLApyJ1x2YXJ0aGV0YScgOiB1J1x1MDNiOCcsCnInXGlvdGEn
IDogdSdcdTAzYjknLApyJ1xrYXBwYScgOiB1J1x1MDNiYScsCnInXGxhbWJkYScgOiB1J1x1MDNi
YicsCnInXG11JyA6IHUnXHUwM2JjJywKcidcbnUnIDogdSdcdTAzYmQnLApyJ1x4aScgOiB1J1x1
MDNiZScsCnInXHBpJyA6IHUnXHUwM2MwJywKcidcdmFycmhvJyA6IHUnXHUwM2MxJywKcidcdmFy
c2lnbWEnIDogdSdcdTAzYzInLApyJ1xzaWdtYScgOiB1J1x1MDNjMycsCnInXHRhdScgOiB1J1x1
MDNjNCcsCnInXHVwc2lsb24nIDogdSdcdTAzYzUnLApyJ1x2YXJwaGknIDogdSdcdTAzYzYnLApy
J1xjaGknIDogdSdcdTAzYzcnLApyJ1xwc2knIDogdSdcdTAzYzgnLApyJ1xvbWVnYScgOiB1J1x1
MDNjOScsCnInXGVsbCcgOiB1J1x1MjExMycsCnInXHdwJyA6IHUnXHUyMTE4JywKcidcT21lZ2En
IDogdSdcdTIxMjYnLApyJ1xSZScgOiB1J1x1MjExYycsCnInXEltJyA6IHUnXHUyMTExJywKcidc
YWxlcGgnIDogdSdcdTA1ZDAnLApyJ1xhbGVwaCcgOiB1J1x1MjEzNScsCnInXHNwYWRlc3VpdCcg
OiB1J1x1MjY2MCcsCnInXGhlYXJ0c3VpdCcgOiB1J1x1MjY2MScsCnInXGRpYW1vbmRzdWl0JyA6
IHUnXHUyNjYyJywKcidcY2x1YnN1aXQnIDogdSdcdTI2NjMnLApyJ1xmbGF0JyA6IHUnXHUyNjZk
JywKcidcbmF0dXJhbCcgOiB1J1x1MjY2ZScsCnInXHNoYXJwJyA6IHUnXHUyNjZmJywKcidcbGVm
dGFycm93JyA6IHUnXHUyMTkwJywKcidcdXBhcnJvdycgOiB1J1x1MjE5MScsCnInXHJpZ2h0YXJy
b3cnIDogdSdcdTIxOTInLApyJ1xkb3duYXJyb3cnIDogdSdcdTIxOTMnLApyJ1xSaWdodGFycm93
JyA6IHUnXHUyMWQyJywKcidcTGVmdHJpZ2h0YXJyb3cnIDogdSdcdTIxZDQnLApyJ1xsZWZ0cmln
aHRhcnJvdycgOiB1J1x1MjE5NCcsCnInXHVwZG93bmFycm93JyA6IHUnXHUyMTk1JywKcidcZm9y
YWxsJyA6IHUnXHUyMjAwJywKcidcZXhpc3RzJyA6IHUnXHUyMjAzJywKcidcZW1wdHlzZXQnIDog
dSdcdTIyMDUnLApyJ1xEZWx0YScgOiB1J1x1MjIwNicsCnInXG5hYmxhJyA6IHUnXHUyMjA3JywK
cidcaW4nIDogdSdcdTIyMDgnLApyJ1xuaScgOiB1J1x1MjIwYicsCnInXHByb2QnIDogdSdcdTIy
MGYnLApyJ1xjb3Byb2QnIDogdSdcdTIyMTAnLApyJ1xzdW0nIDogdSdcdTIyMTEnLApyJy0nIDog
dSdcdTIyMTInLApyJ1xtcCcgOiB1J1x1MjIxMycsCnInLycgOiB1J1x1MjIxNScsCnInXGFzdCcg
OiB1J1x1MjIxNycsCnInXGNpcmMnIDogdSdcdTIyMTgnLApyJ1xidWxsZXQnIDogdSdcdTIyMTkn
LApyJ1xwcm9wdG8nIDogdSdcdTIyMWQnLApyJ1xpbmZ0eScgOiB1J1x1MjIxZScsCnInXG1pZCcg
OiB1J1x1MjIyMycsCnInXHdlZGdlJyA6IHUnXHUyMjI3JywKcidcdmVlJyA6IHUnXHUyMjI4JywK
cidcY2FwJyA6IHUnXHUyMjI5JywKcidcY3VwJyA6IHUnXHUyMjJhJywKcidcaW50JyA6IHUnXHUy
MjJiJywKcidcb2ludCcgOiB1J1x1MjIyZScsCnInOicgOiB1J1x1MjIzNicsCnInXHNpbScgOiB1
J1x1MjIzYycsCnInXHdyJyA6IHUnXHUyMjQwJywKcidcc2ltZXEnIDogdSdcdTIyNDMnLApyJ1xh
cHByb3gnIDogdSdcdTIyNDgnLApyJ1xhc3ltcCcgOiB1J1x1MjI0ZCcsCnInXGVxdWl2JyA6IHUn
XHUyMjYxJywKcidcbGVxJyA6IHUnXHUyMjY0JywKcidcZ2VxJyA6IHUnXHUyMjY1JywKcidcbGwn
IDogdSdcdTIyNmEnLApyJ1xnZycgOiB1J1x1MjI2YicsCnInXHByZWMnIDogdSdcdTIyN2EnLApy
J1xzdWNjJyA6IHUnXHUyMjdiJywKcidcc3Vic2V0JyA6IHUnXHUyMjgyJywKcidcc3Vwc2V0JyA6
IHUnXHUyMjgzJywKcidcc3Vic2V0ZXEnIDogdSdcdTIyODYnLApyJ1xzdXBzZXRlcScgOiB1J1x1
MjI4NycsCnInXHVwbHVzJyA6IHUnXHUyMjhlJywKcidcc3FzdWJzZXRlcScgOiB1J1x1MjI5MScs
CnInXHNxc3Vwc2V0ZXEnIDogdSdcdTIyOTInLApyJ1xzcWNhcCcgOiB1J1x1MjI5MycsCnInXHNx
Y3VwJyA6IHUnXHUyMjk0JywKcidcb3BsdXMnIDogdSdcdTIyOTUnLApyJ1xvbWludXMnIDogdSdc
dTIyOTYnLApyJ1xvdGltZXMnIDogdSdcdTIyOTcnLApyJ1xvc2xhc2gnIDogdSdcdTIyOTgnLApy
J1xvZG90JyA6IHUnXHUyMjk5JywKcidcdmRhc2gnIDogdSdcdTIyYTInLApyJ1xkYXNodicgOiB1
J1x1MjJhMycsCnInXHRvcCcgOiB1J1x1MjJhNCcsCnInXGJvdCcgOiB1J1x1MjJhNScsCnInXGJp
Z3dlZGdlJyA6IHUnXHUyMmMwJywKcidcYmlndmVlJyA6IHUnXHUyMmMxJywKcidcYmlnY2FwJyA6
IHUnXHUyMmMyJywKcidcYmlnY3VwJyA6IHUnXHUyMmMzJywKcidcZGlhbW9uZCcgOiB1J1x1MjJj
NCcsCnInXGNkb3QnIDogdSdcdTIyYzUnLApyJ1xsY2VpbCcgOiB1J1x1MjMwOCcsCnInXHJjZWls
JyA6IHUnXHUyMzA5JywKcidcbGZsb29yJyA6IHUnXHUyMzBhJywKcidccmZsb29yJyA6IHUnXHUy
MzBiJywKcidcbGFuZ2xlJyA6IHUnXHUyN2U4JywKcidccmFuZ2xlJyA6IHUnXHUyN2U5JywKcidc
ZGFnJyA6IHUnXHUyMDIwJywKcidcZGRhZycgOiB1J1x1MjAyMScsCn0KCnVuaWNvZGVfdG9fdGV4
IGlzIHN0cmFpZ2h0IGZvcndhcmQuCkFtIEkgb24gdGhlIHJpZ2h0IHRyYWNrPyBXaGF0IHNob3Vs
ZCBJIGRvIG5leHQ/CgpJIGFsc28gbm90aWNlZCB0aGF0IHNvbWUgVGVYIGNvbW1hbmRzIChjb21t
YW5kcyBpbiB0aGUgc2Vuc2UgdGhhdCB0aGV5CmNhbiBoYXZlIGFyZ3VtZW50cyBlbmNsb3NlZCBp
biBicmFja2V0cyB7fSkgYXJlIGRlZmluZWQgYXMgb25seQpzeW1ib2xzOiBcc3FydCBhbG9uZSwg
Zm9yIGV4YW1wbGUsIGRpc3BsYXlzIGp1c3QgdGhlIGJlZ2luaW5nIG9mIHRoZQpzcXVhcmUgcm9v
dDriiJosIGFuZCBcc3FydHsxMjN9IHRyaWdnZXJzIGFuIGVycm9yLgoKVGhhdCdzIGl0IGZvciBu
b3cKVGhhbmtzIGluIGFkdmFuY2UsCkVkaW4K

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
 Edin> Hi all, Is it that the code in the mathtext module looks
 Edin> ugly or is it just me not understanding it? Also, if anyone
 Edin> has some good online sources about parsing etc. on the net,
 Edin> I vwould realy appreciate it.
It's probably you not understanding it :-) In my opinion, the code is
pretty nice and modular, with a few exceptions, but I'm biased.
Parsers can be a little hard to understand at first. You might start
by trying to understand pyparsing
 http://pyparsing.wikispaces.com
and work through some of the basic examples there. Once you have your
head wrapped around that, it will get easier.
 Edin> Considering the foowing code (picked on random, from
 Edin> mathtext.py)
 Edin> I don't understand, for example, what does the statement:
 Edin> expression.parseString( s )
 Edin> do?
 Edin> "expression" is defined globaly, and is called (that is -
 Edin> its method) only once in the above definition of the
 Edin> function, but I don't understand - what does that particular
 Edin> line do?!?
It's not defined globally, but at module level. There is only one
expression that represents a TeX math expression (at least as far as
mathtext is concerned) so it is right that there is only one of them
at module level. It's like saying "a name is a first name followed by
an optional middle initial followed by a last name". You only need to
define this one, and then you set handlers to handle the different
components.
The expression assigns subexpressions to handlers. The statement
below says that an expression is one or more of a space, font element,
an accent, a symbol, a subscript, etc...
expression =3D OneOrMore(
 space ^ font ^ accent ^ symbol ^ subscript ^ superscript ^ subsupersc=
ript ^ group ^ composite ).setParseAction(handler.expression).setName("e=
xpression")
A subscript, for example, is a symbol group followed by an underscore
followed by a symbol group
subscript << Group( Optional(symgroup) + Literal('_') + symgroup )
and the handler is defined as
subscript =3D Forward().setParseAction(handler.subscript).setName("subscr=
ipt")
which means that the function handler.subscript will be called every
time the pattern is matched. The tokens will be the first symbol
group, the underscore, and the second symbol group. Here is the
implementation of that function
 def subscript(self, s, loc, toks):
 assert(len(toks)=3D=3D1)
 #print 'subsup', toks
 if len(toks[0])=3D=3D2:
 under, next =3D toks[0]
 prev =3D SpaceElement(0)
 else:
 prev, under, next =3D toks[0] =20
 if self.is_overunder(prev):
 prev.neighbors['below'] =3D next
 else:
 prev.neighbors['subscript'] =3D next
 return loc, [prev]
This grabs the tokens and assigns them to the names "prev" and "next".
Every element in the TeX expression is a special case of an Element,
and every Element has a dictionary mapping surrounding elements to
relative locations, either above or below or right or superscript or
subscript. The rest of this function takes the "next" element, and
assigns it either below (eg for \Sum_0円) or subscript (eg for x_0) and
the layout engine will then take this big tree and lay it out. See
for example the "set_origin" function?
 Edin> ------ Regarding the unicode s
upport in mathtext, mathtext
 Edin> currently uses the folowing dictionary for getting the glyph
 Edin> info out of the font files:
 Edin> latex_to_bakoma =3D {
 Edin> r'\oint' : ('cmex10', 45), r'\bigodot' : ('cmex10', 50),
 Edin> r'\bigoplus' : ('cmex10', 55), r'\bigotimes' : ('cmex10',
 Edin> 59), r'\sum' : ('cmex10', 51), r'\prod' : ('cmex10', 24),
 Edin> ...
 Edin> }
 Edin> I managed to build the following dictionary(little more left
 Edin> to be done): tex_to_unicode =3D { r'\S' : u'\u00a7', r'\P' :
 Edin> u'\u00b6', r'\Gamma' : u'\u0393', r'\Delta' : u'\u0394',
 Edin> r'\Theta' : u'\u0398', r'\Lambda' : u'\u039b', r'\Xi' :
 Edin> u'\u039e', r'\Pi' : u'\u03a0', r'\Sigma' : u'\u03a3',
 Edin> unicode_to_tex is straight forward. Am I on the right
 Edin> track? What should I do next?
Yes, this looks like the right approach. Once you have this
dictionary mostly working, you will need to try and make it work with
a set of unicode fonts. So instead of having the tex symbol point to
a file name and glyph index, you will need to parse a set of unicode
fonts to see which unicode symbols they provide and build a mapping
from unicode name -> file, glyph index. Then when you encounter a tex
symbol, you can use your tex_to_unicode dict combined with your
unicode -> filename, glyphindex dict to get the desired glyph.
 Edin> I also noticed that some TeX commands (commands in the sense
 Edin> that they can have arguments enclosed in brackets {}) are
 Edin> defined as only symbols: \sqrt alone, for example, displays
 Edin> just the begining of the square root:=BA, and \sqrt{123}
 Edin> triggers an error.
We don't have support for \sqrt{123} because we would need to do
something a little fancier (draw the horizontal line over 123). This
is doable and would be nice. To implement it, one approach would be
add some basic drawing functionality to the freetype module, eg to
tell freetype to draw a line on it's bitmap. Another approach would
simply be to grab the bitmap to freetype and pass it off to agg and
use the agg renderer to decorate it. This is probably preferable.
But I think this is a lower priority right now.
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Based on a quick look, I think it would be easy to make
 Eric> LineCollection and PolyCollection accept a numerix array in
 Eric> place of [(x,y), (x,y), ...] for each line segment or
 Eric> polygon; specifically, this could replaced by an N x 2
 Eric> array, where the first column would be x and the second
 Eric> would be y. Backwards compatibility could be maintained
 Eric> easily. This would eliminate quite a bit of useless
 Eric> conversion back and forth among lists, tuples, and arrays.
 Eric> As it is, each sequence of sequences is converted to a pair
 Eric> of arrays in backend_bases, and typically it started out as
 Eric> either a 2-D numerix array or a pair of 1-D arrays in the
 Eric> code that is calling the collection constructor.
I think this is a useful enhancement. I would think that representing
each segment as (x,y) where x and y are 1D arrays, might be slightly
more natural than using an Nx2 but others may disagree.
How often does it come up that we want a homogeneous line collection,
ie a bunch of lines segments with the same properties (color,
linewidth...)? The most expensive part of the agg line collection
renderer is probably the multiple calls to render_scanlines, which is
necessary every time we change the linewidth or color. 
If all of the lines in a collection shared the same properties, we
could draw the entire path with a combination of lineto/moveto, and
just stroke and render it once (agg has an upper limit on path length
though, since at some point I added the following to draw_lines
 if ((i%10000)==0) {
 //draw the path in chunks
 _render_lines_path(path, gc);
 path.remove_all();
 path.move_to(thisx, thisy);
 }
Ie I render it every 10000 points. 
Actually, as I type this I realize the case of homogeneous lines (and
polys) can be handled by the backend method "draw_path". One
possibility is for the LineCollection to detect the homogeneous case
len(linewidths)==1 and len(colors)==1 and call out to draw_path
instead of draw_line_collection (the same could be done for a regular
poly collection). Some extra extension code would probably be
necessary to build the path efficiently from numerix arrays, and to
handle the "chunking" problem to avoid extra long paths, but for
certain special cases (scatters and quiver w/o color mapping) it would
probably be a big win. The downside is that not all backend implement
draw_paths, but the Collection front-end could detect this and fall
back on the old approach if draw_paths is not implemented.
JDH

Hello,
I use matplotlib 0.87.3 on win32 with wxpython.
 From the command line, the numeric package is set correctly : numpy 
(read from matplotlibrc) and all woks fine.
I try to use matplotlib from pyxpcom (the connector between xpcom and 
python in the mozilla world), it seems matplotlib doesn't read 
matplotlibrc since it looks for numeric package which is not installed.
I don't undestand, is there a reason the matplotlibrc file is not read, 
interpreted ?
thanks a lot,
Cyril.

Eric Firing wrote:
> Jordan,
>
> I understand what you wrote. I am a bit worried about the amount of 
> complexity it would add to the collection code, however, and it seems 
> like it would be useful only in quite special situations--and in those 
> situations, there may be reasonable alternatives. For example, the ps 
> backend uses nan as a flag or separator to skip drawing a line 
> segment; if all backends did this, then it would provide a more 
> general way to accomplish what you want to do.
>
> I will keep your idea in mind, but I want to start off with a much 
> simpler change.
I would tend to agree that nan entries would be a better idea than what 
I was talking about. I'll think about trying to modify the backend 
codes to support this behaviour, if they don't already.
Jordan

I have one suggestion, slightly off-topic, and I'm not sure how useful 
it would be: you might think about making LineCollection accept a 3-D 
numerix array. This came up for me while I was looking at turning the 
quiver arrows into line segments. As I understand it (and as the 
documentation says) LineCollection takes a set of a lines which are 
composed of continuous line segments, like:
segments = ( line0, line1, line2 )
linen = ( (x0,y0), (x1,y1), (x2, y2) )
I'd like an extra level of organization, like so:
linegroups = ( group0, group1, group2)
groupi = ( line0, line1, line2 )
linen = ( (x0,y0), (x1,y1), (x2, y2) )
Where "linegroups" would be the input to LineCollection. I assume it's 
fairly obvious how this turns into a rank 3 array.
The reason for this is that it allows for the drawing of non-continuous 
lines. This came up with the quiver arrow stuff because, as it stands, 
drawing a line-based arrow requires you to back-track over a previous 
line at least once. This created some rendering problems, where the 
back-tracked line was darker than the others, at least on the agg 
backend. This can be fixed by backtracking along every line in the 
arrow, so you are essentially drawing the arrow twice, but that seems 
inefficient. It is possible to draw 3 seperate line segments for each 
arrow, but then the colormapping no longer works; each line segment gets 
a different color, and the arrows look like a mess.
As I said, I don't know how useful this would be; it only comes up when 
drawing non-closed line segments that need to be addressed as a single 
object. Does what I wrote make sense?
Jordan
Eric Firing wrote:
> Based on a quick look, I think it would be easy to make LineCollection 
> and PolyCollection accept a numerix array in place of [(x,y), (x,y), 
> ...] for each line segment or polygon; specifically, this could replaced 
> by an N x 2 array, where the first column would be x and the second 
> would be y. Backwards compatibility could be maintained easily. This 
> would eliminate quite a bit of useless conversion back and forth among 
> lists, tuples, and arrays. As it is, each sequence of sequences is 
> converted to a pair of arrays in backend_bases, and typically it started 
> out as either a 2-D numerix array or a pair of 1-D arrays in the code 
> that is calling the collection constructor.
>
> Using a single 2-D array makes it easier to determine whether one is 
> dealing with 'old-style' inputs or 'new-style' inputs, but it might 
> still be reasonable to allow [X, Y] instead or in addition, where X and 
> Y are 1-D numerix arrays.
>
> Any objections or alternative suggestions?
>
> Eric
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>