Re: [matplotlib-devel] Mathtext questions, continued...
> "Edin" == Edin Salkovi§ <[EMAIL PROTECTED]> 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 = 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 = r'$\cal{R}\prod_{i=\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?
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.
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"] = "rm", where env is the
Edin> environment in the current scope.
Can we use classes here rather than dictionaries? Syntactically, I
prefer env.facetype = "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
[matplotlib-devel] weird outline with fill
Hi,
I am using matplotlib 87.4 and I encountered a problem with fill. The outlines
of the filled region look weird when using the TkAgg backend. Same applies when
saved to a png file, so this seems to be a problem of all *Agg backends. The PS
backend is fine. Here is a somewhat longer example, that shows this behaviour.
For comparison, drawing the same outlines with plot gives a perfectly smooth
result.
from pylab import *
clf()
x = linspace(0,1, 100)
y1 = x**2
y2 = 1.03*y1
xx = concatenate((x, x[::-1]))
yy = concatenate((y1, y2[::-1]))
fillh = fill(xx, yy, ec = 'k', lw = 0.4)
fillh = fillh[0]
fillh.set_fill(False)
ph = plot(x, y1+0.1, 'k-',
x, y2+0.1, 'k-', lw = 0.4)
savefig('jaggyfill.png', dpi = 150)
savefig('jaggyfill.eps')
show()
The more points I use, the worse the result. I create a png file since I need
alpha filling, eps doesn't support this. Creating a high resolution png and
downscaling improves the result, but this is tedious and time consuming. Any
help is appreciated!
Thanks in advance
Gregor Thalhammer
PS. Is this the right place to discuss such problems?
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]
As a probably final installment in the thread about optimizing the wx
back-end, here is a post from the wxPython list, in which someone posted
SWIG code for making a PyBuffer from his data set, then using it to
create a wx.Image without copying. A similar approach could be used for
the wxAgg back-end.
-Chris
Original Message
Subject: [wxPython-users] Re: using wxImage in C++ python extension
Date: Fri, 18 Aug 2006 16:48:08 + (UTC)
From: Andrew Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Hi all :)
I've followed the combined advice of Robin and Christopher in using a python
buffer object to instance a wx.Image in the python wrapper layer. It
all seems
to be working - and I don't think there are any 'data copies' going on ;)
To keep my underlying C++ python-free, I introduced the buffer (and
creation of
the wx.Image) via my .i Swig file. In case anyone who is reading is
keen trying
to solve a similar problem, I've included the code that I added to my .i
file in
order to implement the change below. (I'd appreciate any comments regarding
errors or shortcomings that anyone spots in my implementation.)
Sorry I didn't reply to the thread earlier. A combination of being tied
up with
more boring work, moving house and background research into using python
buffers
with Swig means that I've only just got this far.
One remaining question I have is: Does the call to wx.EmptyImage that I make
cause any memory to be allocated? I see from Robin's recent post that in my
case this call is now redundant (as I will soon be using
ImageFromBuffer) - but
I'm curious to know the answer anyway ;)
Thanks for all the help. The more I use wxPython the more I like it...
Andrew ;)
/* the RawImage C++ class that we are wrapping offers a method that
returns a pointer to an internal 'unsigned char' buffer of display
data. To make the python class generated by SWIG a bit more
friendly to the rest of our wxPython code we instruct SWIG to make
two modifications during the wrapping process. First we add a
method to the C++ class that will return a version of the internal
display buffer wrapped up as a 'python buffer object' (performing
this in the C++ wrapper class keeps the wrapped C++ python-free)...
*/
%extend RawImage {
PyObject* RawImage::getDisplayBuffer(void) {
// return a new 'python buffer object' that intialised using
// the memory address and length of our display buffer...
void* pvBufferData = (void*)self->pcGetDisplayData();
int iBufferSize = self->getDisplayBufferSize();
return PyBuffer_FromMemory(pvBufferData, iBufferSize);
}
}
/* ... we also add a method to the python wrapper class that will use
the buffer offered by our new C++ method to create a wx.Image
(neither of these methods actually copies the image data)...
*/
%extend RawImage {
%pythoncode %{
def getImage(self):
# create an unintialised wx.Image of the correct size...
wximage = wx.EmptyImage(self.getWidth(), self.getHeight(), clear=False)
# then define the data content of the image...
wximage.SetDataBuffer(self.getDisplayBuffer())
return wximage
%}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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
[EMAIL PROTECTED]
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
