From: <edi...@gm...> - 2006-08-15 21:53:15
Attachments:
mathtext.py
|
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 |
From: John H. <jdh...@ac...> - 2006-08-18 16:43:29
|
>>>>> "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 |
From: <edi...@gm...> - 2006-08-20 14:25:51
|
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 |
From: Darren D. <dd...@co...> - 2006-08-20 15:24:23
|
On Sunday 20 August 2006 10:25 am, Edin Salkovi=C4=87 wrote: > Here are the reasons for rewriting mathtext2 that I can come up with: > > * One of the reasons I started the complete rewrite of the parser is that > I'm a newbie at parsing, and I wanted to try it out a bit. I didn't > understand why was it so difficult to parse TeX (or anything a little bit > complicated for that matter). Well, now I know ;) > > * The other reason was that I didn't understand fully the current parsing > code, or more precisely, the part when what's interpreted get's rendered. > And I'm not talking about glyphs, but about the complex constructs > (scripts, frac's etc.) > > * The third reason was that I can now try out in pararel the new and the > old code. Also, because I'm not touching the PS and SVG backends for now = we > can have the following code in the current mathtext: > > if rcParams[some_parameter]: > from matplotlib.mathtext2 import math_parse_s_ft2font > else: > math_parse_s_ft2font =3D math_parse_s_ft2font_common('BMP') > math_parse_s_ft2font_svg =3D math_parse_s_ft2font_common('SVG') > math_parse_s_ps =3D math_parse_s_ft2font_common('PS') > math_parse_s_pdf =3D math_parse_s_ft2font_common('PDF') > > Also, I thought that the author of the current code base did some design > mistakes at the begining. And, being a developer newbie, it's a lot easier > to start things from scratch, than make fixes to old stuff you don't > understand well. Just a general comment. Eric Raymond observed in The Cathedral and the Baza= ar=20 that "Good programmers know what to write. Great ones know what to rewrite= =20 (and reuse)." In the future, I suggest you consider that it may be in your= =20 own long term interest to try to understand and extend existing code instea= d=20 of rewriting it from scratch. You'll learn quickly by being exposed to othe= r=20 people's ideas and techniques, and you will get faster results since you=20 won't be reinventing the wheel. > As for the mathtext_demo.py part, even real TeX can't handle it :).=20 If TeX isn't yielding the result you expect, then you were expecting the wr= ong=20 result. > The point is that, i.e. \cal sets the current fontface to "cal", and the= =20 > change is propagated till the end of the current scope (or untill it hits= =20 > \rm, for example). Old mathtext applies it only to the first item after t= he=20 > command.=20 What does this have to do with real TeX? Maybe you could post an example. I= t=20 is possibly just an mpl bug that needs to be addressed. Darren |
From: Jouni K S. <jk...@ik...> - 2006-08-21 06:27:49
Attachments:
foo.tex
|
Darren Dale <dd...@co...> writes: > On Sunday 20 August 2006 10:25 am, Edin Salković wrote: >> Also, I thought that the author of the current code base did some >> design mistakes at the begining. And, being a developer newbie, >> it's a lot easier to start things from scratch, than make fixes to >> old stuff you don't understand well. > > Just a general comment. Eric Raymond observed in The Cathedral and > the Bazaar that "Good programmers know what to write. Great ones > know what to rewrite (and reuse)." See also: http://www.joelonsoftware.com/articles/fog0000000069.html >> The point is that, i.e. \cal sets the current fontface to "cal", >> and the change is propagated till the end of the current scope (or >> untill it hits \rm, for example). Old mathtext applies it only to >> the first item after the command. > > What does this have to do with real TeX? Maybe you could post an > example. It is possibly just an mpl bug that needs to be addressed. Run the attached file through LaTeX to see what he means. Does Matplotlib attempt to replicate some subset of (La)TeX syntax exactly, or is it just a "TeX-like" syntax? -- Jouni |
From: Darren D. <dd...@co...> - 2006-08-21 12:47:10
|
On Monday 21 August 2006 02:27, Jouni K Seppanen wrote: > Darren Dale <dd...@co...> writes: > > On Sunday 20 August 2006 10:25 am, Edin Salkovi=C4=87 wrote: > >> Also, I thought that the author of the current code base did some > >> design mistakes at the begining. And, being a developer newbie, > >> it's a lot easier to start things from scratch, than make fixes to > >> old stuff you don't understand well. > > > > Just a general comment. Eric Raymond observed in The Cathedral and > > the Bazaar that "Good programmers know what to write. Great ones > > know what to rewrite (and reuse)." > > See also: http://www.joelonsoftware.com/articles/fog0000000069.html > > >> The point is that, i.e. \cal sets the current fontface to "cal", > >> and the change is propagated till the end of the current scope (or > >> untill it hits \rm, for example). Old mathtext applies it only to > >> the first item after the command. > > > > What does this have to do with real TeX? Maybe you could post an > > example. It is possibly just an mpl bug that needs to be addressed. > > Run the attached file through LaTeX to see what he means. Does > Matplotlib attempt to replicate some subset of (La)TeX syntax exactly, > or is it just a "TeX-like" syntax? I think what he meant to say was that old mathtext didnt behave the way TeX= =20 does, is that correct Edin? My feeling is that mpl should replicate the=20 (La)TeX syntax exactly. Imagine the confusion if mathtext gives one result,= =20 and usetex gives another.=20 |
From: <edi...@gm...> - 2006-08-21 18:18:12
|
Thanks all for the tips, Darren, that's exactly what I had in mind - mathtext should copy the syntax of (La)TeX to a tollerable extent (without those dirty macros), so at least the high level TeX constructs behave the same. This should allow users to plot everyday plots easily with mathtext, and when they want a publication ready EPS (perhaps one day mathtext will be good enough for it), they'll just add the option usetex, with no other code change. I think it's easier to stick with plain TeX's syntax because it's very well documented. Cheers, Edin On 8/21/06, Darren Dale <dd...@co...> wrote: > I think what he meant to say was that old mathtext didnt behave the way TeX > does, is that correct Edin? My feeling is that mpl should replicate the > (La)TeX syntax exactly. Imagine the confusion if mathtext gives one result, > and usetex gives another. > |