matplotlib-devel Mailing List for matplotlib (Page 2)

On Thu, May 29, 2008 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
> To what bug do you refer? There seem to be related zoom-to-rect bugs in
> both the trunk and the branch. In both, zooming in to a region comparable
> to, or smaller than, a "pixel" (meaning a grid cell in the data array), gets
> unbearably slow. In the branch, it has the additional characteristic of
> fading out. I think this bug may be inherent in Agg, and has been around
> indefinitely.
Yes, this is a problem in either the _image or _backend_agg
implementation, not agg itself, and should be fixed.
But I was referring to a different problem. In the thread:
"[Matplotlib-users] matploblib communication problem, graphics
question" I wrote about a zoom to rect bug (I'll paste the relevant
bit below), but for the life of me I can't replicate it on my machine
here (TkAgg). I'll have to test at home on wxagg on OSX which is
where I was having the problems:
Here was the OP:
In testing this stuff, I found a bug bug in image handling on the
trunk -- if you zoom to part of an image with zoom-to-rect, the part
that you get zoomed to is not the part you select. This is most
apparent if you load an image with easily recognizable features, eg a
picture of a person. This problem is on the trunk but not the branch
-- here is some example code:
In [8]: fig = plt.figure()
In [9]: ax = fig.add_subplot(111)
In [10]: ax.set_aspect('auto')
In [11]: X = imread('/Users/jdhunter/Desktop/IMG_0907.JPG')
In [12]: ax.imshow(X, origin='lower', aspect='auto')
Out[12]: <matplotlib.image.AxesImage object at 0x112586b0>
In [13]: ax.figure.canvas.draw()
In [14]: ax.cla()
In [15]: ax.set_aspect('auto')
In [16]: ax.imshow(X, origin='upper', aspect='auto')
Out[16]: <matplotlib.image.AxesImage object at 0x11258690>
In [17]: fig.canvas.draw()

John Hunter wrote:
> On Thu, May 29, 2008 at 12:09 PM, John Hunter <jd...@gm...> wrote:
>> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
>>> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?
>> We are now ready to do 0.98pre -- fire when ready Charlie.
> 
> 91.3 is now ready too.
> 
> Since there is still a bug in zoom-to-rect for images in 98pre, let's
> make 91.3 the default visible to the users who just click on
> "download" and I'll make a link to the 98pre download section in the
> newsbox section of the web-page.
To what bug do you refer? There seem to be related zoom-to-rect bugs in 
both the trunk and the branch. In both, zooming in to a region 
comparable to, or smaller than, a "pixel" (meaning a grid cell in the 
data array), gets unbearably slow. In the branch, it has the additional 
characteristic of fading out. I think this bug may be inherent in Agg, 
and has been around indefinitely.
Or are you referring to some other bug?
Eric
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, May 29, 2008 at 12:09 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
>> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?
>
> We are now ready to do 0.98pre -- fire when ready Charlie.
91.3 is now ready too.
Since there is still a bug in zoom-to-rect for images in 98pre, let's
make 91.3 the default visible to the users who just click on
"download" and I'll make a link to the 98pre download section in the
newsbox section of the web-page.
JDH

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?
We are now ready to do 0.98pre -- fire when ready Charlie.
JDH

I agree, this looks good. 
I'd really like to get a 98pre out soon, so I can distribute my own project 
which requires it.
On Thursday 29 May 2008 12:04:29 pm Michael Droettboom wrote:
> Disregard this -- I think John's solution looks good.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I'm happy to deal with this, but I wonder about the best path.
> >
> > Is it reasonable to assume that we have unicode support available in
> > LaTeX and can just turn it on always, or do we need to (for instance)
> > convert all the Unicode minus signs back into "-" and put the whole
> > thing inside "$ $" (something that I suspect will be tricky in general
> > also). Or, should we just back this minus sign stuff out (again), until
> > we have a good general solution?
> >
> > BTW -- this change is only on the trunk, which is still expected to have
> > some rough edges. Personally, I'm less concerned about fixing this asap
> > than if it were on the maintenance branch.
> >
> > Cheers,
> > Mike
> >
> > Darren Dale wrote:
> >> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote:
> >>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote:
> >>>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
> >>>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
> >>>>>> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...>
> >>
> >> wrote:
> >>>>>>> Should we still proceed with this now that numpy 1.1.0 is out? Any
> >>>>>>> holdups?
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>> So let's focus on clearing these bugs (and anything else the other
> >>>>>> devs raise), hopefully in the next couple days, and then push out
> >>>>>> the maintenance release followed by the pre-release of the branch.
> >>>>>>
> >>>>>> I'll also work on getting the site docs ready to go.
> >>>>>
> >>>>> On tuesday we ran into a spot of trouble at work, I've been having to
> >>>>> put in extra hours and work at home in the evening to try to handle
> >>>>> it. Unfortunately I probably won't be in a position to help with
> >>>>> docs and bugs until the weekend.
> >>>>
> >>>> There is a bug in texmanager that I need to fix before we release 91.3
> >>>> or 98pre. I'll try to squeeze it in this morning.
> >>>
> >>> It looks like my problem is fixed on the branch and the trunk, thanks
> >>> to Mike for helping sort out the merge.
> >>
> >> Looks like something else just turned up in ticker.py on the trunk.
> >> Somebody replaced minus signs with unicode, a good idea, but it breaks
> >> latex if unicode support is not enabled for usetex. I don't have time to
> >> fix it.
> >>
> >> File "monte_carlo.py", line 37, in <module>
> >> show()
> >>
> >> File
> >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py",
> >> line 66, in show
> >> figManager.canvas.draw()
> >>
> >> File
> >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.p
> >>y", line 133, in draw
> >> FigureCanvasAgg.draw(self)
> >>
> >> File
> >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> >> line 255, in draw
> >> self.figure.draw(self.renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line
> >> 792, in draw
> >> for a in self.axes: a.draw(renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line
> >> 1452, in draw
> >> a.draw(renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line
> >> 680, in draw
> >> tick.draw(renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line
> >> 179, in draw
> >> self.label1.draw(renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line
> >> 761, in draw
> >> Text.draw(self, renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line
> >> 295, in draw
> >> bbox, info = self._get_layout(renderer)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line
> >> 195, in _get_layout
> >> line, self._fontproperties, ismath=self.is_math_text(line))
> >>
> >> File
> >> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> >> line 127, in get_text_width_height_descent
> >> Z = texmanager.get_grey(s, size, self.dpi)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py",
> >> line 366, in get_grey
> >> pngfile = self.make_png(tex, fontsize, dpi)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py",
> >> line 300, in make_png
> >> dvifile = self.make_dvi(tex, fontsize)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py",
> >> line 269, in make_dvi
> >> texfile = self.make_tex(tex, fontsize)
> >> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py",
> >> line 248, in make_tex
> >> fh.write(s)
> >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in
> >> position 290: ordinal not in range(128)
> >>
> >> ------------------------------------------------------------------------
> >>- This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Disregard this -- I think John's solution looks good.
Cheers,
Mike
Michael Droettboom wrote:
> I'm happy to deal with this, but I wonder about the best path. 
>
> Is it reasonable to assume that we have unicode support available in 
> LaTeX and can just turn it on always, or do we need to (for instance) 
> convert all the Unicode minus signs back into "-" and put the whole 
> thing inside "$ $" (something that I suspect will be tricky in general 
> also). Or, should we just back this minus sign stuff out (again), until 
> we have a good general solution?
>
> BTW -- this change is only on the trunk, which is still expected to have 
> some rough edges. Personally, I'm less concerned about fixing this asap 
> than if it were on the maintenance branch.
>
> Cheers,
> Mike
>
> Darren Dale wrote:
> 
>> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote:
>> 
>> 
>>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote:
>>> 
>>> 
>>>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
>>>> 
>>>> 
>>>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
>>>>> 
>>>>> 
>>>>>> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> 
>>>>>> 
>>>>>> 
>> wrote:
>> 
>> 
>>>>>>> Should we still proceed with this now that numpy 1.1.0 is out? Any
>>>>>>> holdups?
>>>>>>> 
>>>>>>> 
>>>>> [...]
>>>>>
>>>>> 
>>>>> 
>>>>>> So let's focus on clearing these bugs (and anything else the other
>>>>>> devs raise), hopefully in the next couple days, and then push out the
>>>>>> maintenance release followed by the pre-release of the branch.
>>>>>>
>>>>>> I'll also work on getting the site docs ready to go.
>>>>>> 
>>>>>> 
>>>>> On tuesday we ran into a spot of trouble at work, I've been having to
>>>>> put in extra hours and work at home in the evening to try to handle it.
>>>>> Unfortunately I probably won't be in a position to help with docs and
>>>>> bugs until the weekend.
>>>>> 
>>>>> 
>>>> There is a bug in texmanager that I need to fix before we release 91.3 or
>>>> 98pre. I'll try to squeeze it in this morning.
>>>> 
>>>> 
>>> It looks like my problem is fixed on the branch and the trunk, thanks to
>>> Mike for helping sort out the merge.
>>> 
>>> 
>> Looks like something else just turned up in ticker.py on the trunk. Somebody 
>> replaced minus signs with unicode, a good idea, but it breaks latex if 
>> unicode support is not enabled for usetex. I don't have time to fix it.
>>
>> File "monte_carlo.py", line 37, in <module>
>> show()
>> 
>> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", 
>> line 66, in show
>> figManager.canvas.draw()
>> 
>> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", 
>> line 133, in draw
>> FigureCanvasAgg.draw(self)
>> 
>> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
>> line 255, in draw
>> self.figure.draw(self.renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in 
>> draw
>> for a in self.axes: a.draw(renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in 
>> draw
>> a.draw(renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in 
>> draw
>> tick.draw(renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in 
>> draw
>> self.label1.draw(renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in 
>> draw
>> Text.draw(self, renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in 
>> draw
>> bbox, info = self._get_layout(renderer)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in 
>> _get_layout
>> line, self._fontproperties, ismath=self.is_math_text(line))
>> 
>> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
>> line 127, in get_text_width_height_descent
>> Z = texmanager.get_grey(s, size, self.dpi)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
>> 366, in get_grey
>> pngfile = self.make_png(tex, fontsize, dpi)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
>> 300, in make_png
>> dvifile = self.make_dvi(tex, fontsize)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
>> 269, in make_dvi
>> texfile = self.make_tex(tex, fontsize)
>> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
>> 248, in make_tex
>> fh.write(s)
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position 
>> 290: ordinal not in range(128)
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm happy to deal with this, but I wonder about the best path. 
Is it reasonable to assume that we have unicode support available in 
LaTeX and can just turn it on always, or do we need to (for instance) 
convert all the Unicode minus signs back into "-" and put the whole 
thing inside "$ $" (something that I suspect will be tricky in general 
also). Or, should we just back this minus sign stuff out (again), until 
we have a good general solution?
BTW -- this change is only on the trunk, which is still expected to have 
some rough edges. Personally, I'm less concerned about fixing this asap 
than if it were on the maintenance branch.
Cheers,
Mike
Darren Dale wrote:
> On Thursday 29 May 2008 11:32:10 am Darren Dale wrote:
> 
>> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote:
>> 
>>> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
>>> 
>>>> On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
>>>> 
>>>>> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> 
>>>>> 
> wrote:
> 
>>>>>> Should we still proceed with this now that numpy 1.1.0 is out? Any
>>>>>> holdups?
>>>>>> 
>>>> [...]
>>>>
>>>> 
>>>>> So let's focus on clearing these bugs (and anything else the other
>>>>> devs raise), hopefully in the next couple days, and then push out the
>>>>> maintenance release followed by the pre-release of the branch.
>>>>>
>>>>> I'll also work on getting the site docs ready to go.
>>>>> 
>>>> On tuesday we ran into a spot of trouble at work, I've been having to
>>>> put in extra hours and work at home in the evening to try to handle it.
>>>> Unfortunately I probably won't be in a position to help with docs and
>>>> bugs until the weekend.
>>>> 
>>> There is a bug in texmanager that I need to fix before we release 91.3 or
>>> 98pre. I'll try to squeeze it in this morning.
>>> 
>> It looks like my problem is fixed on the branch and the trunk, thanks to
>> Mike for helping sort out the merge.
>> 
>
> Looks like something else just turned up in ticker.py on the trunk. Somebody 
> replaced minus signs with unicode, a good idea, but it breaks latex if 
> unicode support is not enabled for usetex. I don't have time to fix it.
>
> File "monte_carlo.py", line 37, in <module>
> show()
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", 
> line 66, in show
> figManager.canvas.draw()
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", 
> line 133, in draw
> FigureCanvasAgg.draw(self)
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 255, in draw
> self.figure.draw(self.renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in 
> draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in 
> draw
> a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in 
> draw
> tick.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in 
> draw
> self.label1.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in 
> draw
> Text.draw(self, renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in 
> draw
> bbox, info = self._get_layout(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in 
> _get_layout
> line, self._fontproperties, ismath=self.is_math_text(line))
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 127, in get_text_width_height_descent
> Z = texmanager.get_grey(s, size, self.dpi)
> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
> 366, in get_grey
> pngfile = self.make_png(tex, fontsize, dpi)
> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
> 300, in make_png
> dvifile = self.make_dvi(tex, fontsize)
> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
> 269, in make_dvi
> texfile = self.make_tex(tex, fontsize)
> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
> 248, in make_tex
> fh.write(s)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position 
> 290: ordinal not in range(128)
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 29, 2008 at 10:46 AM, Darren Dale <dar...@co...> r
> Looks like something else just turned up in ticker.py on the trunk. Somebody
> replaced minus signs with unicode, a good idea, but it breaks latex if
> unicode support is not enabled for usetex. I don't have time to fix it.
I just committed a fix for this -- when you get a minute, let me know
if it works for you.
We should get a usetex example in backend_driver...
JDH

On Thursday 29 May 2008 11:32:10 am Darren Dale wrote:
> On Thursday 29 May 2008 08:28:20 am Darren Dale wrote:
> > On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
> > > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
> > > > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> 
wrote:
> > > > > Should we still proceed with this now that numpy 1.1.0 is out? Any
> > > > > holdups?
> > >
> > > [...]
> > >
> > > > So let's focus on clearing these bugs (and anything else the other
> > > > devs raise), hopefully in the next couple days, and then push out the
> > > > maintenance release followed by the pre-release of the branch.
> > > >
> > > > I'll also work on getting the site docs ready to go.
> > >
> > > On tuesday we ran into a spot of trouble at work, I've been having to
> > > put in extra hours and work at home in the evening to try to handle it.
> > > Unfortunately I probably won't be in a position to help with docs and
> > > bugs until the weekend.
> >
> > There is a bug in texmanager that I need to fix before we release 91.3 or
> > 98pre. I'll try to squeeze it in this morning.
>
> It looks like my problem is fixed on the branch and the trunk, thanks to
> Mike for helping sort out the merge.
Looks like something else just turned up in ticker.py on the trunk. Somebody 
replaced minus signs with unicode, a good idea, but it breaks latex if 
unicode support is not enabled for usetex. I don't have time to fix it.
 File "monte_carlo.py", line 37, in <module>
 show()
 
File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4.py", 
line 66, in show
 figManager.canvas.draw()
 
File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py", 
line 133, in draw
 FigureCanvasAgg.draw(self)
 
File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 255, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 792, in 
draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1452, in 
draw
 a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 680, in 
draw
 tick.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axis.py", line 179, in 
draw
 self.label1.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 761, in 
draw
 Text.draw(self, renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 295, in 
draw
 bbox, info = self._get_layout(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/text.py", line 195, in 
_get_layout
 line, self._fontproperties, ismath=self.is_math_text(line))
 
File "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 127, in get_text_width_height_descent
 Z = texmanager.get_grey(s, size, self.dpi)
 File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
366, in get_grey
 pngfile = self.make_png(tex, fontsize, dpi)
 File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
300, in make_png
 dvifile = self.make_dvi(tex, fontsize)
 File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
269, in make_dvi
 texfile = self.make_tex(tex, fontsize)
 File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line 
248, in make_tex
 fh.write(s)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2212' in position 
290: ordinal not in range(128)

On Thursday 29 May 2008 08:28:20 am Darren Dale wrote:
> On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
> > On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
> > > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
> > > > Should we still proceed with this now that numpy 1.1.0 is out? Any
> > > > holdups?
> >
> > [...]
> >
> > > So let's focus on clearing these bugs (and anything else the other
> > > devs raise), hopefully in the next couple days, and then push out the
> > > maintenance release followed by the pre-release of the branch.
> > >
> > > I'll also work on getting the site docs ready to go.
> >
> > On tuesday we ran into a spot of trouble at work, I've been having to put
> > in extra hours and work at home in the evening to try to handle it.
> > Unfortunately I probably won't be in a position to help with docs and
> > bugs until the weekend.
>
> There is a bug in texmanager that I need to fix before we release 91.3 or
> 98pre. I'll try to squeeze it in this morning.
It looks like my problem is fixed on the branch and the trunk, thanks to Mike 
for helping sort out the merge.
Darren

John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>> So, this is more the fault of operating procedure (choosing not to do the
>> numpy renaming on the branch, for instance, which in itself was not a bad
>> decision in isolation), than the tool itself. Note that svnmerge did do the
>> right thing in your merge on about five diffs, and only two couldn't be
>> automatically merged. In my own experience, merges work far more often than
>> not, but as the trunk drifts further away from the branch, no doubt that
>> percentage will go down...
>> 
>
> My (limited) experience has been same -- merges usually ""just work".
> Part of the drift (eg the npy, np differences) we are currently
> dealing with is explained by me doing things the wrong way for a
> while, before I go. As more of us work to keep the branch in sync
> where feasible, these kinds of problems should be less frequent.
>
> 
I didn't mean to imply that doing the rename only on the trunk was 
necessarily a bad thing. It's a balancing act: too many changes to the 
branch runs the risk of introducing bugs, not enough changes can mean 
drift. It's like all the rivers in China: dammed either way.
Cheers,
Mike

Thanks Mike.
On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
> >> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <dar...@co...>
> >
> > wrote:
> >>> I dont understand. I thought the point of svnmerge.py was to sync the
> >>> change, not to introduce conflicts. Is the procedure you just outlined
> >>> the standard operating procedure, or did svnmerge.py encounter
> >>> problems? The procedure in your original post to this thread seems much
> >>> more straight forward.
> >>
> >> I think the point is to keep track of which revisions you've already
> >> merged (and resolved conflicts in) so you don't have to resolve them
> >> again later. Michale pointed out to me offlist that in standard
> >> usage, you do not need to manually give the revision number so my
> >> original instructions advocating them were wrong.
> >
> > I'm sorry, I just don't understand how to use this. I just got a clean
> > checkout of the trunk, ran "svnmerge.py merge":
> >
> > $ svnmerge.py merge
> > property 'svnmerge-integrated' set on '.'
> >
> > property 'svnmerge-blocked' deleted from '.'.
> >
> > --- Merging r5298 through r5299 into '.':
> > U CHANGELOG
> > C lib/matplotlib/texmanager.py
> > C lib/matplotlib/backends/backend_svg.py
> >
> > property 'svnmerge-integrated' set on '.'
> >
> > property 'svnmerge-blocked' deleted from '.'.
> >
> > Thats not what I want, I only want to commit the changes I made to
> > CHANGELOG and texmanager. I tried reverting the changes with svn revert,
> > but now when I do a diff, I get:
> >
> > $ svn diff
> >
> > Property changes on: .
> > ___________________________________________________________________
> > Modified: svnmerge-integrated
> > - /branches/v0_91_maint:1-5294
> > + /branches/v0_91_maint:1-5299
>
> I'm confused by this. Did you do:
>
> svn -R revert .
>
> from the root of the tree? That should back out that property change.
>
> > Can I please just manually merge my changes in from the branch, without
> > svnmerge.py? I really don't have time today to mess around with this.
>
> I can do the merge for you.
>
> [mdroe@wonkabar matplotlib]$ svn update
> U lib/matplotlib/ticker.py
> U CHANGELOG
> Updated to revision 5299.
> [mdroe@wonkabar matplotlib]$ svnmerge merge
> U CHANGELOG
> C lib/matplotlib/texmanager.py
> C lib/matplotlib/backends/backend_svg.py
>
> property 'svnmerge-integrated' set on '.'
>
> # We don't want to merge backend_svg.py -- we just want what's currently
> on the trunk
> [mdroe@wonkabar matplotlib]$ cp
> lib/matplotlib/backends/backend_svg.py.working
> lib/matplotlib/backends/backend_svg.py
>
> # Manually resolve texmanager.py
> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
>
> # Mark everything as resolved
> [mdroe@wonkabar matplotlib]$ svn -R resolved .
> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
>
> # Commit
> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
> Sending .
> Sending CHANGELOG
> Sending lib/matplotlib/texmanager.py
> Transmitting file data ..
> Committed revision 5300.
> [mdroe@wonkabar matplotlib]$
>
>
> Cheers,
> Mike
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
> So, this is more the fault of operating procedure (choosing not to do the
> numpy renaming on the branch, for instance, which in itself was not a bad
> decision in isolation), than the tool itself. Note that svnmerge did do the
> right thing in your merge on about five diffs, and only two couldn't be
> automatically merged. In my own experience, merges work far more often than
> not, but as the trunk drifts further away from the branch, no doubt that
> percentage will go down...
My (limited) experience has been same -- merges usually ""just work".
Part of the drift (eg the npy, np differences) we are currently
dealing with is explained by me doing things the wrong way for a
while, before I go. As more of us work to keep the branch in sync
where feasible, these kinds of problems should be less frequent.
JDH

Darren Dale wrote:
> On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
> 
>> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <dar...@co...> 
>> 
> wrote:
> 
>>> I dont understand. I thought the point of svnmerge.py was to sync the
>>> change, not to introduce conflicts. Is the procedure you just outlined
>>> the standard operating procedure, or did svnmerge.py encounter problems?
>>> The procedure in your original post to this thread seems much more
>>> straight forward.
>>> 
>> I think the point is to keep track of which revisions you've already
>> merged (and resolved conflicts in) so you don't have to resolve them
>> again later. Michale pointed out to me offlist that in standard
>> usage, you do not need to manually give the revision number so my
>> original instructions advocating them were wrong.
>> 
>
> I'm sorry, I just don't understand how to use this. I just got a clean 
> checkout of the trunk, ran "svnmerge.py merge":
>
> $ svnmerge.py merge
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> --- Merging r5298 through r5299 into '.':
> U CHANGELOG
> C lib/matplotlib/texmanager.py
> C lib/matplotlib/backends/backend_svg.py
>
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> Thats not what I want, I only want to commit the changes I made to CHANGELOG 
> and texmanager. I tried reverting the changes with svn revert, but now when I 
> do a diff, I get:
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svnmerge-integrated
> - /branches/v0_91_maint:1-5294
> + /branches/v0_91_maint:1-5299
>
>
> 
I'm confused by this. Did you do:
 svn -R revert .
from the root of the tree? That should back out that property change.
> Can I please just manually merge my changes in from the branch, without 
> svnmerge.py? I really don't have time today to mess around with this.
> 
I can do the merge for you.
[mdroe@wonkabar matplotlib]$ svn update
U lib/matplotlib/ticker.py
U CHANGELOG
Updated to revision 5299.
[mdroe@wonkabar matplotlib]$ svnmerge merge
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py
property 'svnmerge-integrated' set on '.'
# We don't want to merge backend_svg.py -- we just want what's currently 
on the trunk
[mdroe@wonkabar matplotlib]$ cp 
lib/matplotlib/backends/backend_svg.py.working 
lib/matplotlib/backends/backend_svg.py
# Manually resolve texmanager.py
[mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
# Mark everything as resolved
[mdroe@wonkabar matplotlib]$ svn -R resolved .
Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
# Commit
[mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending lib/matplotlib/texmanager.py
Transmitting file data ..
Committed revision 5300.
[mdroe@wonkabar matplotlib]$
Cheers,
Mike

Darren Dale wrote:
> On Thursday 29 May 2008 10:04:34 am you wrote:
> 
>> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...> 
>> 
> wrote:
> 
>>> I am trying to merge a change to texmanager from the branch to the trunk,
>>> but something doesnt look right after I ran svnmerge.py. Look at all the
>>> markup in the diff, I can't commit this, can I?
>>> 
>> No. The > +<<<<<<< .working stuff means there are conflicts in the
>> merge between the branch and trunk, and you have to resolve them by
>> editing all the files which have conflicts to resolve the conflicts,
>> and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
>> like that, and then commit the fixed files.
>> 
Minor point: On my machine at least, I don't have to manually clean up 
the conflict files -- they are removed for me on the next commit. Those 
files are really just for reference. If you use a SVN frontend for 
diffing (such as psvn.el or meld) they are largely unnecessary.
> I dont understand. I thought the point of svnmerge.py was to sync the change, 
> not to introduce conflicts. Is the procedure you just outlined the standard 
> operating procedure, or did svnmerge.py encounter problems? The procedure in 
> your original post to this thread seems much more straight forward.
> 
> Say I attempt to resolve conflicts, do I then run svnmerge.py again to make 
> sure that no additional conflicts are introduced? (arg, hg and bzr make this 
> much easier.)
> 
You don't need to run svnmerge.py again. You just need to resolve the 
conflicts, removing the conflict markers, tell SVN you have done so 
(with "svn resolved"), and then commit ("svn commit -F 
svnmerge-commit-message.txt").
There are differences in the branch and trunk (sometimes called "version 
drift") that make it impossible to merge the files automatically. This 
is an oft cited advantage of hg and bzr, but I don't think any tool that 
doesn't do some sort of deep code introspection could help out here. 
When people say "merging is easier with tool X", they usually mean that 
the branch/merge tracking is better, not that it can resolve conflicts 
any "smarter." SVN proper has virtually no branch/merge tracking, 
svnmerge makes things a little better, but not very well integrated. 
But as for conflicts, according to the bzr manpage, bzr appears to do 
exactly the same thing as SVN in this case, including the creation of 
three extra files (though the details are different):
http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm#id17
For instance, look at the last difference:
@@ -407,7 +414,11 @@
 if Z is None:
 alpha = self.get_grey(tex, fontsize, dpi)
+<<<<<<< .working
 Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
+=======
+ Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>>>>>> .merge-right.r5299
 Z[:,:,0] = r
 Z[:,:,1] = g
 Z[:,:,2] = b
At one point, npy was renamed to np throughout this file, on the trunk, 
but not in the branch. SVN has no way of knowing (since it doesn't 
understand Python syntax) that these two tokens are equivalent. You 
need a human being who understands how the code is supposed to work to 
resolve this.
So, this is more the fault of operating procedure (choosing not to do 
the numpy renaming on the branch, for instance, which in itself was not 
a bad decision in isolation), than the tool itself. Note that svnmerge 
did do the right thing in your merge on about five diffs, and only two 
couldn't be automatically merged. In my own experience, merges work far 
more often than not, but as the trunk drifts further away from the 
branch, no doubt that percentage will go down...
Cheers,
Mike

On Thu, May 29, 2008 at 9:41 AM, Darren Dale <dar...@co...> wrote:
> Thats not what I want, I only want to commit the changes I made to CHANGELOG
> and texmanager. I tried reverting the changes with svn revert, but now when I
> do a diff, I get:
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svnmerge-integrated
> - /branches/v0_91_maint:1-5294
> + /branches/v0_91_maint:1-5299
I already screwed up everything once royally, so I'll let Michael
comment on this.

On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <dar...@co...> 
wrote:
> > I dont understand. I thought the point of svnmerge.py was to sync the
> > change, not to introduce conflicts. Is the procedure you just outlined
> > the standard operating procedure, or did svnmerge.py encounter problems?
> > The procedure in your original post to this thread seems much more
> > straight forward.
>
> I think the point is to keep track of which revisions you've already
> merged (and resolved conflicts in) so you don't have to resolve them
> again later. Michale pointed out to me offlist that in standard
> usage, you do not need to manually give the revision number so my
> original instructions advocating them were wrong.
I'm sorry, I just don't understand how to use this. I just got a clean 
checkout of the trunk, ran "svnmerge.py merge":
$ svnmerge.py merge
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
--- Merging r5298 through r5299 into '.':
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
Thats not what I want, I only want to commit the changes I made to CHANGELOG 
and texmanager. I tried reverting the changes with svn revert, but now when I 
do a diff, I get:
$ svn diff
Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
 - /branches/v0_91_maint:1-5294
 + /branches/v0_91_maint:1-5299
Can I please just manually merge my changes in from the branch, without 
svnmerge.py? I really don't have time today to mess around with this.
Darren

On Thursday 29 May 2008 10:04:34 am you wrote:
> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...> 
wrote:
> > I am trying to merge a change to texmanager from the branch to the trunk,
> > but something doesnt look right after I ran svnmerge.py. Look at all the
> > markup in the diff, I can't commit this, can I?
>
> No. The > +<<<<<<< .working stuff means there are conflicts in the
> merge between the branch and trunk, and you have to resolve them by
> editing all the files which have conflicts to resolve the conflicts,
> and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
> like that, and then commit the fixed files.
I dont understand. I thought the point of svnmerge.py was to sync the change, 
not to introduce conflicts. Is the procedure you just outlined the standard 
operating procedure, or did svnmerge.py encounter problems? The procedure in 
your original post to this thread seems much more straight forward.
Say I attempt to resolve conflicts, do I then run svnmerge.py again to make 
sure that no additional conflicts are introduced? (arg, hg and bzr make this 
much easier.)

On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...> wrote:
> I am trying to merge a change to texmanager from the branch to the trunk, but
> something doesnt look right after I ran svnmerge.py. Look at all the markup
> in the diff, I can't commit this, can I?
No. The > +<<<<<<< .working stuff means there are conflicts in the
merge between the branch and trunk, and you have to resolve them by
editing all the files which have conflicts to resolve the conflicts,
and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
like that, and then commit the fixed files.
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svnmerge-integrated
> - /branches/v0_91_maint:1-5294
> + /branches/v0_91_maint:1-5294,5299
>
> Index: CHANGELOG
> ===================================================================
> --- CHANGELOG (revision 5299)
> +++ CHANGELOG (working copy)
> @@ -1,3 +1,13 @@
> +<<<<<<< .working
> +=======
> +2008年05月29日 Fixed two bugs in texmanager.py:
> + improved comparison of dvipng versions
> + fixed a bug introduced when get_grey method was added
> + - DSD
> +
> +2008年05月29日 Implement path clipping in SVG backend - MGD
> +
> +>>>>>>> .merge-right.r5299
> 2008年05月28日 Fix crashing of PDFs in xpdf and ghostscript when two-byte
> characters are used with Type 3 fonts - MGD
>
> Index: lib/matplotlib/texmanager.py
> ===================================================================
> --- lib/matplotlib/texmanager.py (revision 5299)
> +++ lib/matplotlib/texmanager.py (working copy)
> @@ -33,8 +33,14 @@
>
> """
>
> +<<<<<<< .working
> import copy, glob, md5, os, shutil, sys
> import numpy as np
> +=======
> +import copy, glob, md5, os, shutil, sys, warnings
> +import distutils.version
> +import numpy as npy
> +>>>>>>> .merge-right.r5299
> import matplotlib as mpl
> from matplotlib import rcParams
> from matplotlib._image import readpng
> @@ -44,14 +50,15 @@
> if sys.platform.startswith('win'): cmd_split = '&'
> else: cmd_split = ';'
>
> -def get_dvipng_version():
> +def dvipng_hack_alpha():
> stdin, stdout = os.popen4('dvipng -version')
> for line in stdout:
> if line.startswith('dvipng '):
> version = line.split()[-1]
> mpl.verbose.report('Found dvipng version %s'% version,
> 'helpful')
> - return version
> + version = distutils.version.LooseVersion(version)
> + return version < distutils.version.LooseVersion('1.6')
> raise RuntimeError('Could not obtain dvipng version')
>
>
> @@ -78,7 +85,7 @@
> if not os.path.exists(texcache):
> os.mkdir(texcache)
>
> - dvipngVersion = get_dvipng_version()
> + _dvipng_hack_alpha = dvipng_hack_alpha()
>
> # mappable cache of
> rgba_arrayd = {}
> @@ -364,8 +371,28 @@
> pngfile = self.make_png(tex, fontsize, dpi)
> X = readpng(os.path.join(self.texcache, pngfile))
>
> - if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
> - # hack the alpha channel as described in comment above
> + if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
> + # hack the alpha channel
> + # dvipng assumed a constant background, whereas we want to
> + # overlay these rasters with antialiasing over arbitrary
> + # backgrounds that may have other figure elements under them.
> + # When you set dvipng -bg Transparent, it actually makes the
> + # alpha channel 1 and does the background compositing and
> + # antialiasing itself and puts the blended data in the rgb
> + # channels. So what we do is extract the alpha information
> + # from the red channel, which is a blend of the default
> dvipng
> + # background (white) and foreground (black). So the amount
> of
> + # red (or green or blue for that matter since white and black
> + # blend to a grayscale) is the alpha intensity. Once we
> + # extract the correct alpha information, we assign it to the
> + # alpha channel properly and let the users pick their rgb.
> In
> + # this way, we can overlay tex strings on arbitrary
> + # backgrounds with antialiasing
> + #
> + # red = alpha*red_foreground + (1-alpha)*red_background
> + #
> + # Since the foreground is black (0) and the background is
> + # white (1) this reduces to red = 1-alpha or alpha = 1-red
> alpha = np.sqrt(1-X[:,:,0])
> else:
> alpha = X[:,:,-1]
> @@ -378,26 +405,6 @@
> """
> Returns latex's rendering of the tex string as an rgba array
> """
> - # dvipng assumes a constant background, whereas we want to
> - # overlay these rasters with antialiasing over arbitrary
> - # backgrounds that may have other figure elements under them.
> - # When you set dvipng -bg Transparent, it actually makes the
> - # alpha channel 1 and does the background compositing and
> - # antialiasing itself and puts the blended data in the rgb
> - # channels. So what we do is extract the alpha information
> - # from the red channel, which is a blend of the default dvipng
> - # background (white) and foreground (black). So the amount of
> - # red (or green or blue for that matter since white and black
> - # blend to a grayscale) is the alpha intensity. Once we
> - # extract the correct alpha information, we assign it to the
> - # alpha channel properly and let the users pick their rgb. In
> - # this way, we can overlay tex strings on arbitrary
> - # backgrounds with antialiasing
> - #
> - # red = alpha*red_foreground + (1-alpha)*red_background
> - #
> - # Since the foreground is black (0) and the background is
> - # white (1) this reduces to red = 1-alpha or alpha = 1-red
> if not fontsize: fontsize = rcParams['font.size']
> if not dpi: dpi = rcParams['savefig.dpi']
> r,g,b = rgb
> @@ -407,7 +414,11 @@
> if Z is None:
> alpha = self.get_grey(tex, fontsize, dpi)
>
> +<<<<<<< .working
> Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
> +=======
> + Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
> +>>>>>>> .merge-right.r5299
> Z[:,:,0] = r
> Z[:,:,1] = g
> Z[:,:,2] = b
>

I am trying to merge a change to texmanager from the branch to the trunk, but 
something doesnt look right after I ran svnmerge.py. Look at all the markup 
in the diff, I can't commit this, can I?
$ svn diff
Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
 - /branches/v0_91_maint:1-5294
 + /branches/v0_91_maint:1-5294,5299
Index: CHANGELOG
===================================================================
--- CHANGELOG (revision 5299)
+++ CHANGELOG (working copy)
@@ -1,3 +1,13 @@
+<<<<<<< .working
+=======
+2008年05月29日 Fixed two bugs in texmanager.py:
+ improved comparison of dvipng versions
+ fixed a bug introduced when get_grey method was added
+ - DSD
+
+2008年05月29日 Implement path clipping in SVG backend - MGD
+
+>>>>>>> .merge-right.r5299
 2008年05月28日 Fix crashing of PDFs in xpdf and ghostscript when two-byte
 characters are used with Type 3 fonts - MGD
Index: lib/matplotlib/texmanager.py
===================================================================
--- lib/matplotlib/texmanager.py (revision 5299)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -33,8 +33,14 @@
 """
+<<<<<<< .working
 import copy, glob, md5, os, shutil, sys
 import numpy as np
+=======
+import copy, glob, md5, os, shutil, sys, warnings
+import distutils.version
+import numpy as npy
+>>>>>>> .merge-right.r5299
 import matplotlib as mpl
 from matplotlib import rcParams
 from matplotlib._image import readpng
@@ -44,14 +50,15 @@
 if sys.platform.startswith('win'): cmd_split = '&'
 else: cmd_split = ';'
-def get_dvipng_version():
+def dvipng_hack_alpha():
 stdin, stdout = os.popen4('dvipng -version')
 for line in stdout:
 if line.startswith('dvipng '):
 version = line.split()[-1]
 mpl.verbose.report('Found dvipng version %s'% version,
 'helpful')
- return version
+ version = distutils.version.LooseVersion(version)
+ return version < distutils.version.LooseVersion('1.6')
 raise RuntimeError('Could not obtain dvipng version')
@@ -78,7 +85,7 @@
 if not os.path.exists(texcache):
 os.mkdir(texcache)
- dvipngVersion = get_dvipng_version()
+ _dvipng_hack_alpha = dvipng_hack_alpha()
 # mappable cache of
 rgba_arrayd = {}
@@ -364,8 +371,28 @@
 pngfile = self.make_png(tex, fontsize, dpi)
 X = readpng(os.path.join(self.texcache, pngfile))
- if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
- # hack the alpha channel as described in comment above
+ if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
+ # hack the alpha channel
+ # dvipng assumed a constant background, whereas we want to
+ # overlay these rasters with antialiasing over arbitrary
+ # backgrounds that may have other figure elements under them.
+ # When you set dvipng -bg Transparent, it actually makes the
+ # alpha channel 1 and does the background compositing and
+ # antialiasing itself and puts the blended data in the rgb
+ # channels. So what we do is extract the alpha information
+ # from the red channel, which is a blend of the default 
dvipng
+ # background (white) and foreground (black). So the amount 
of
+ # red (or green or blue for that matter since white and black
+ # blend to a grayscale) is the alpha intensity. Once we
+ # extract the correct alpha information, we assign it to the
+ # alpha channel properly and let the users pick their rgb. 
In
+ # this way, we can overlay tex strings on arbitrary
+ # backgrounds with antialiasing
+ #
+ # red = alpha*red_foreground + (1-alpha)*red_background
+ #
+ # Since the foreground is black (0) and the background is
+ # white (1) this reduces to red = 1-alpha or alpha = 1-red
 alpha = np.sqrt(1-X[:,:,0])
 else:
 alpha = X[:,:,-1]
@@ -378,26 +405,6 @@
 """
 Returns latex's rendering of the tex string as an rgba array
 """
- # dvipng assumes a constant background, whereas we want to
- # overlay these rasters with antialiasing over arbitrary
- # backgrounds that may have other figure elements under them.
- # When you set dvipng -bg Transparent, it actually makes the
- # alpha channel 1 and does the background compositing and
- # antialiasing itself and puts the blended data in the rgb
- # channels. So what we do is extract the alpha information
- # from the red channel, which is a blend of the default dvipng
- # background (white) and foreground (black). So the amount of
- # red (or green or blue for that matter since white and black
- # blend to a grayscale) is the alpha intensity. Once we
- # extract the correct alpha information, we assign it to the
- # alpha channel properly and let the users pick their rgb. In
- # this way, we can overlay tex strings on arbitrary
- # backgrounds with antialiasing
- #
- # red = alpha*red_foreground + (1-alpha)*red_background
- #
- # Since the foreground is black (0) and the background is
- # white (1) this reduces to red = 1-alpha or alpha = 1-red
 if not fontsize: fontsize = rcParams['font.size']
 if not dpi: dpi = rcParams['savefig.dpi']
 r,g,b = rgb
@@ -407,7 +414,11 @@
 if Z is None:
 alpha = self.get_grey(tex, fontsize, dpi)
+<<<<<<< .working
 Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
+=======
+ Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>>>>>> .merge-right.r5299
 Z[:,:,0] = r
 Z[:,:,1] = g
 Z[:,:,2] = b

On Thursday 29 May 2008 06:39:26 am Darren Dale wrote:
> On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
> > On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
> > > Should we still proceed with this now that numpy 1.1.0 is out? Any
> > > holdups?
>
> [...]
>
> > So let's focus on clearing these bugs (and anything else the other
> > devs raise), hopefully in the next couple days, and then push out the
> > maintenance release followed by the pre-release of the branch.
> >
> > I'll also work on getting the site docs ready to go.
>
> On tuesday we ran into a spot of trouble at work, I've been having to put
> in extra hours and work at home in the evening to try to handle it.
> Unfortunately I probably won't be in a position to help with docs and bugs
> until the weekend.
There is a bug in texmanager that I need to fix before we release 91.3 or 
98pre. I'll try to squeeze it in this morning.

On Wednesday 28 May 2008 10:42:57 pm John Hunter wrote:
> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
> > Should we still proceed with this now that numpy 1.1.0 is out? Any
> > holdups?
[...]
> So let's focus on clearing these bugs (and anything else the other
> devs raise), hopefully in the next couple days, and then push out the
> maintenance release followed by the pre-release of the branch.
>
> I'll also work on getting the site docs ready to go.
On tuesday we ran into a spot of trouble at work, I've been having to put in 
extra hours and work at home in the evening to try to handle it. 
Unfortunately I probably won't be in a position to help with docs and bugs 
until the weekend.

A slightly different (and can be minor) issue related with unicode
support in ps backend.
For one of my Korean font, it raises an following exception.
File "/users/research/lee/local/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 688, in draw_unicode
 self.set_font(font.get_sfnt()[(1,0,0,6)], prop.get_size_in_points())
KeyError: (1, 0, 0, 6)
Apparently, the return value of get_sfnt() for this particular font
does not have (1,0,0,6) key.
Agg, png, and Cairo backends are all okay with this font.
Anyhow, as it happens for only one font AFAIK, and as we can use Cairo
backend instead, there may not be much need to fix this unless it can
be easily done.
Regards,
-JJ

Hi Mike,
Yes, it is correct now.
I tried bunch of Korean characters and fonts and they were all fine.
Thanks a lot!
Unfortunately, there's an other problem. Although the glyphs are
rendered at correct location, some of the characters are still
incorrect (pdf backends is fine only ps output is wrong).
I'm attaching pdf one (correct) and ps one (incorrect). You will
easily notice what's wrong.
When a single glyph is consisted of overlapping closed paths, current
ps font definition does not fill those overlapping regions (the source
code has a comment that it assumes the paths are detached.).
In the output font definition, paths are filled with "eofill" command.
If I replace "eofill" with simple "fill" (line 384 of pprdrv_tt.cpp),
then characters are rendered correctly. I tried other non-korean
characters to see if such change is harmful, but no such case is found
as far as I see.
As I know little about postscipt and ttf font, I'm not sure this is a
correct way (although it works fine for me). So, it will be
appreciated if Mike or others confirm this and make a change.
Thanks very much in advance.
Regards,
-JJ
ps. Although it is a very simple fix, a diff file is also attached.
On Wed, May 28, 2008 at 9:38 AM, Michael Droettboom <md...@st...> wrote:
> I seem to have found a fix. The key point was this comment in
> pprdrv_tt2.cpp:
>
> else /* The tt spec. does not clearly indicate */
> { /* whether these values are signed or not. */
> arg1 = *(signed char *)(glyph++);
> arg2 = *(signed char *)(glyph++);
> }
>
> By adding the cast to (signed char *), things seem to work. I guess that's
> what the spec does in practice! This doesn't seem to break Latin compound
> glyphs that used to work (the only thing that has been extensively tested up
> until now), so I'm pretty confident that's the correct fix. This has been
> fixed in SVN. Please try with more Korean characters and let me know if you
> still see anything strange.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>>
>> Correction -- no need to send the image. You said png output was correct,
>> so I'll just compare against that.
>>
>> Michael Droettboom wrote:
>>
>>>
>>> The code that generates the Type 3 fonts for us is fairly old (1995), and
>>> certainly predates the widespread adoption of Unicode, so I'm somewhat not
>>> surprised this doesn't work. I'll have a brief look to see if there are any
>>> obvious fixes, but we're unlikely to implement a full-fledged Unicode
>>> rendering system (like Pango) any time soon. Since I don't read Korean, can
>>> you provide an image file of what the resulting compound glyph is supposed
>>> to look like?
>>>
>>> As a workaround, you could try using the Cairo backend to generate
>>> Postscript and PDF. It may do a better job. You could also try other
>>> Korean fonts -- they may not use compound glyph composition.
>>> Cheers,
>>> Mike
>>>
>>> Jae-Joon Lee wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> I wanted to render some Korean text in my matplotlib figure and this
>>>> is how I did (with python2.5 and trunk version of matplotlib).
>>>>
>>>> # -*- coding: utf-8 -*-
>>>> from pylab import *
>>>>
>>>> import matplotlib.font_manager as fm
>>>> fp=fm.FontProperties(fname="/users/research/lee/.fonts/Eunjin.ttf",
>>>> size=100)
>>>>
>>>> plot([1,2,3])
>>>> text(1.,1.5, u'이', fontproperties=fp)
>>>> savefig("test.eps")
>>>> show()
>>>>
>>>>
>>>> It works fine with GtkAgg (and saving to png file also).
>>>> But ps (fonttype=3) and pdf backends seem to render the characters
>>>> incorrectly.
>>>> Rendering with ps backends (fonttype=42) IS correct on the other hand.
>>>> See attached eps and pdf files. "test_correct.eps" is the correct one
>>>> made with ps fonttype=42.
>>>> "test_wrong.eps" is from fonttype=3.
>>>>
>>>> Just in case, my rc file contains
>>>> text.usetex : False
>>>> ps.useafm : False
>>>>
>>>>
>>>> If I use ps backend with fonttype=3 (the wrong one), the embedded font
>>>> in the output eps file for the above character is defined as follows.
>>>>
>>>> /uniC774{917 0 67 -2 833 678 _sc
>>>> gsave 0 343 translate
>>>> false CharStrings /cho12-1 get exec
>>>> grestore false CharStrings /jung21-1 get exec
>>>> }_d
>>>>
>>>> It is a composition of two glyphs (/cho12-1 and /jung21-1), and my
>>>> guess is the first glyph is somehow misplaced. If I manually change
>>>> the translation of the first glyph to something like (0, -150) instead
>>>> the current value of (0, 343), the output looks okay.
>>>>
>>>> I tried a few other Korean fonts but the results were similar. Some of
>>>> the glyphs are misplaced (in ps(type=3) and pdf backends).
>>>> Although I cannot rule out that the fonts I used have wrong font
>>>> information, but my inclination is this could be a bug in
>>>> "pprdrv_tt2.cpp" (or a related header, e.g.. truetype.h).
>>>>
>>>> The translation of each glyphs seems to be handled by following code
>>>> (around line 594 of pprdrv_tt2.cpp).
>>>>
>>>> if( flags & ARGS_ARE_XY_VALUES )
>>>> {
>>>> if( arg1 != 0 || arg2 != 0 )
>>>> stream.printf("gsave %d %d translate\n",
>>>> topost(arg1), topost(arg2) );
>>>> }
>>>>
>>>> It would be great if someone who is expert on this font issue can look
>>>> into this.
>>>> Just in case, arg1=0, arg2=206, font->HUPM= 300, font->unitsPerEm=600
>>>> for this particular glyph.
>>>> The later two are used inside "topost".
>>>> Regards,
>>>>
>>>> -JJ
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?
I've done a fair amount of testing on the branch (0.91.3),
particularly looking at all the PDF and SVG output from backend
driver, and these backends are in the best shape I've ever seen them.
I don't use these backends in my daily work, so haven't fully
appreciated all the incremental progress that has been made. They are
both now fully feature compliant, which is amazing to me (thanks to
Mike and Jouni and everyone who did all the nitty gritty work here).
I did notice a bug in SVG and PS for the first time, where the polar
lines are not clipped to the polygon axes background ( I filed it at
http://sourceforge.net/tracker/index.php?func=detail&aid=1977271&group_id=80706&atid=560720).
 I think we should take a crack at fixing these since the branch is
otherwise in such good shape that we could perhaps go a long time w/o
another maintenance release.
On the trunk (0.98), the bug I am most concerned with is
http://sourceforge.net/tracker/index.php?func=detail&aid=1976887&group_id=80706&atid=560720
. I find these jaggedy fonts in rotated text particularly grating, so
I want to track this one down.
So let's focus on clearing these bugs (and anything else the other
devs raise), hopefully in the next couple days, and then push out the
maintenance release followed by the pre-release of the branch.
I'll also work on getting the site docs ready to go.
On the issue of numpy 1.1: I am still not clear if our old binaries
are broken. This came up in another thread on OS-X. If our binaries
are broken with numpy 1.1 we need to move with a release ASAP, and
these comparatively minor bugs should not hold us up. If they are
not, I prefer to take a day or two and try and clear the above bugs
first. I tested the mpl 0.91.2 win32 exe installer with the numpy
1.1 exe installer and had no troubles. Is the situation on OS-X
different? Please advise.
JDH