matplotlib-devel Mailing List for matplotlib (Page 5)

I think this is a known bug (and maybe a bug should be filed so it doesn't get lost).
Most of the backends don't have support for clipping which would be required for this to work.
Cheers,
Mike

polar_demo agg and polar_demo pdf/ps/svg show different results. In agg, 
the spiral is clipped to the polar axes. In pdf/ps/svg it is clipped to 
the rectangle containing the axes.
Note: I don't use polar plots, so I'm mentioning this for completeness only.
	- Paul

I'm attaching a screenshot of Safari rendering svg for mathtext_demo.py
(modified to show that formulae can be rotated by arbitrary angles).
For some reason it is picking the wrong symbols from the font.
Firefox on OS X picks the same incorrect symbols, but it is picking them 
from a courier font so the results are really ugly.
	- Paul

The Agg backend has a feature where if "bmp" was specified as a file 
extension, it saves as a raw RGBA image. IMHO, this is perhaps too 
easily confused with the "Microsoft Windows Bitmap" format. There is a 
(someone else's) bug filed against this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1696469&group_id=80706&atid=560720
As part of my recent refactoring of code to map image filetypes to 
backends, I removed this meaning of .bmp. If anyone has any reasons why 
.bmp should stay as a "raw" format, let me know, and I'll put it back 
in. Either way, I'll close the bug as either "fixed" or "rejected".
Cheers,
Mike

Paul Kienzle <pki...@ni...> writes:
> We could store a copy of the png output somewhere in the svn tree. Then,
> whenever we change something we can do a binary comparison on all the
> plots. It would avoid issues such as breakage of polar plots where the 
> author of the changes didn't consider that it would affect polar plot
> output. Similarly for ps/pdf. Differences in fonts between platforms
> might be a problem in this scheme.
For ps/pdf the files would have to be converted to e.g. png for the
comparison to be meaningful. At least pdf files contain a randomly
selected string to identify the file, as well as the creation date, 
and I am not aware of a diff tool for pdf.
Perhaps the template backend could be extended to print out a log of 
all calls to draw_*, and the logs compared. This would enable a kind 
of limited automatic testing of interactive features such as window
resizing and zooming: let the test backend simulate resize or zoom
events and check the draw_* log against a hand-checked version. This
approach could catch bugs like the "handles = ax.lines" which should
have been "handles = ax.lines[:]", which was only visible when alpha 
was less than 1.
(http://article.gmane.org/gmane.comp.python.matplotlib.devel/2574)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Paul Kienzle wrote:
> On Thu, Sep 06, 2007 at 08:14:19AM -0400, Michael Droettboom wrote:
>> On a broader note, I've been using backend_driver.py as my ersatz 
>> "acceptance test suite." Not all of these examples are included in it, 
>> of course. Is there good reason for that, or should I go ahead and add 
>> these to backend_driver? As we're all well aware, matplotlib has an 
>> unusually large configuration space, so any bit of testing automation 
>> really helps.
> 
> We could store a copy of the png output somewhere in the svn tree. Then,
> whenever we change something we can do a binary comparison on all the
> plots. It would avoid issues such as breakage of polar plots where the 
> author of the changes didn't consider that it would affect polar plot
> output. Similarly for ps/pdf. Differences in fonts between platforms
> might be a problem in this scheme.
We could have a special flag for font_manager.py that only loads fonts 
from mpl-data/fonts. Then the results for Agg should theoretically be 
the same across platforms. The Gdk, Cairo and wxRenderer would all have 
slightly different results across platforms, however, as the underlying 
font engines could change.
Alternatively, we could sidestep this problem by producing a set of PNG 
images for each platform which would have to be individually verified on 
a per-platform basis. It (at least) triples the verification work, but 
cuts down on work in other areas...
Cheers,
Mike

On Thu, Sep 06, 2007 at 08:46:24AM -0400, Paul Kienzle wrote:
> We could store a copy of the png output somewhere in the svn tree.
> Then,
> whenever we change something we can do a binary comparison on all the
> plots. It would avoid issues such as breakage of polar plots where the
> author of the changes didn't consider that it would affect polar plot
> output. Similarly for ps/pdf. Differences in fonts between platforms
> might be a problem in this scheme.
VTK does this for automated testing.
Gaël

On Thu, Sep 06, 2007 at 08:14:19AM -0400, Michael Droettboom wrote:
> On a broader note, I've been using backend_driver.py as my ersatz 
> "acceptance test suite." Not all of these examples are included in it, 
> of course. Is there good reason for that, or should I go ahead and add 
> these to backend_driver? As we're all well aware, matplotlib has an 
> unusually large configuration space, so any bit of testing automation 
> really helps.
We could store a copy of the png output somewhere in the svn tree. Then,
whenever we change something we can do a binary comparison on all the
plots. It would avoid issues such as breakage of polar plots where the 
author of the changes didn't consider that it would affect polar plot
output. Similarly for ps/pdf. Differences in fonts between platforms
might be a problem in this scheme.
	- Paul

Paul Kienzle wrote:
> I went through the demo list again today. Here are some problems:
> 
> $ python fonts_demo.py 
> Traceback (most recent call last):
> File "fonts_demo.py", line 31, in <module>
> font.set_name('Script MT')
> AttributeError: 'FontProperties' object has no attribute 'set_name'
Fixed in r3795.
> I'm getting segfaults for the following on wxagg for os x:
> 
> annotation_demo
> polar_*
> transoffset
> 
> The polar demos work for pdf but not agg from backend_driver.py
Fixed in r3796. (I had changed the size of the alpha buffer to 1-byte 
per pixel to match the type as specified to Agg, but apparently that 
wasn't a good idea. There's a lot to be confused about in Agg... ;)
On a broader note, I've been using backend_driver.py as my ersatz 
"acceptance test suite." Not all of these examples are included in it, 
of course. Is there good reason for that, or should I go ahead and add 
these to backend_driver? As we're all well aware, matplotlib has an 
unusually large configuration space, so any bit of testing automation 
really helps.
Cheers,
Mike

I went through the demo list again today. Here are some problems:
$ python fonts_demo.py 
Traceback (most recent call last):
 File "fonts_demo.py", line 31, in <module>
 font.set_name('Script MT')
AttributeError: 'FontProperties' object has no attribute 'set_name'
I'm getting segfaults for the following on wxagg for os x:
 annotation_demo
 polar_*
 transoffset
The polar demos work for pdf but not agg from backend_driver.py
	- Paul

Thanks. This patch looks good -- apologies for my sloppy confusion of 
Python/C++ deletes.
I just committed this patch (r3790) with one exception: as your comment 
suggests, when get_image is called and image == NULL, it throws and 
exception.
Cheers,
Mike
Paul Kienzle wrote:
> On Wed, Sep 05, 2007 at 07:13:27AM -0400, Michael Droettboom wrote:
>> Jouni K. Seppänen wrote:
>>> Paul Kienzle <pki...@ni...> writes:
>>>
>>> [segfaults]
>>>> Is there something in the last couple of weeks which might cause this?
>>> Some changes in font handling caused segfaults for me, and it turned out
>>> to be a bug in an old version of freetype:
>>>
>>> http://article.gmane.org/gmane.comp.python.matplotlib.general/10062
>>>
>>> Try running python under gdb, or using strace/truss/ktrace to see what
>>> is happening right before the segfault.
>> I'm not able to reproduce anything amiss on my Linux box.
> 
> I'm able to eliminate the problem by setting image=NULL after deleting it.
> 
> I did some mods to the refcount handling so that it consistently uses
> XINC/XDEC for images and INC/DEC for glyphs.
> 
> I added in INCREF to get_glyph(); you don't seem to call it so it didn't 
> show up as an error without.
> 
> See attached patch. Let me know if I should post it to svn.
> 
> 	- Paul
> 
> 

On Wed, Sep 05, 2007 at 07:13:27AM -0400, Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
> > Paul Kienzle <pki...@ni...> writes:
> > 
> > [segfaults]
> >> Is there something in the last couple of weeks which might cause this?
> > 
> > Some changes in font handling caused segfaults for me, and it turned out
> > to be a bug in an old version of freetype:
> > 
> > http://article.gmane.org/gmane.comp.python.matplotlib.general/10062
> > 
> > Try running python under gdb, or using strace/truss/ktrace to see what
> > is happening right before the segfault.
> 
> I'm not able to reproduce anything amiss on my Linux box.
I'm able to eliminate the problem by setting image=NULL after deleting it.
I did some mods to the refcount handling so that it consistently uses
XINC/XDEC for images and INC/DEC for glyphs.
I added in INCREF to get_glyph(); you don't seem to call it so it didn't 
show up as an error without.
See attached patch. Let me know if I should post it to svn.
	- Paul

Paul Kienzle <pki...@ni...> writes:
> Looks like a freetype bug: the following code segfaults when linked
> against libfreetype.6.3.10 but not when linked against
> libfreetype.6.3.16.
>
> I don't understand why it is referring to 6.3.16 when 2.3.5 was released
> in July 2007, unless 6.3.16 means May 16, 2006.
Oh, I was referring to the version numbers in the filenames (is it
called "soversion"?). I think libfreetype.6.3.16.dylib is a file from
Freetype 2.3.5.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Wed, Sep 05, 2007 at 01:40:02PM +0300, Jouni K. Seppänen wrote:
> Paul Kienzle <pki...@ni...> writes:
> 
> [segfaults]
> > Is there something in the last couple of weeks which might cause this?
> 
> Some changes in font handling caused segfaults for me, and it turned out
> to be a bug in an old version of freetype:
> 
> http://article.gmane.org/gmane.comp.python.matplotlib.general/10062
> 
> Try running python under gdb, or using strace/truss/ktrace to see what
> is happening right before the segfault.
Running gdb first:
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x65c4a402
 0x65c4a402 in ?? ()
 (gdb) bt
 #0 0x65c4a402 in ?? ()
 #1 0x0265c5e1 in FT_Glyph_Get_CBox (glyph=0x54463a3a, bbox_mode=1634552114, acbox=0x6567) at /Users/pkienzle/Packages/freetype-2.3.5/src/base/ftglyph.c:534
 Previous frame inner to this frame (corrupt stack?)
So the problem seems to be in freetype.
The link above says:
 Looks like a freetype bug: the following code segfaults when linked
 against libfreetype.6.3.10 but not when linked against
 libfreetype.6.3.16. Freetype has some code to read dfont files, which
 apparently had a bug in the older version, and this is triggered by the
 new code that reads in all font files.
I don't understand why it is referring to 6.3.16 when 2.3.5 was released
in July 2007, unless 6.3.16 means May 16, 2006.
	- Paul

I don't think it's related. But definitely a bug... I forgot to test 
my baseline code with text.usetex turned on.
I just submitted a fix in r3781.
Cheers,
Mike
Manuel Metz wrote:
> Don't know whether this is related, but I now get the following error:
> 
> File 
> "/py.src/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py", 
> line 669, in draw_tex
> w, h, bl = self.get_text_width_height_baseline(s, prop, ismath)
> AttributeError: RendererPS instance has no attribute 
> 'get_text_width_height_baseline'
> 
> with the the latest svn trunk ...
> 
> Manuel
> 
> Paul Kienzle wrote:
>> In checking the mathtext rotation feature I found that the graph displayed
>> fine, but python segfault'd shortly after displaying it. Most (all) examples
>> are failing for me for svn r3778, even after rebuilding and reinstalling
>> everything.
>>
>> Is there something in the last couple of weeks which might cause this?
>>
>> Running backend_drivers, the Agg plots are fine. 
>> None of the PS plots are viewable with Preview.app. 
>> I don't have an svg viewer handy.
>>
>> I'm running macpython 2.5 fat binary build on OS X 10.4 with wx 2.8.
>>
>> Anyone else having problems with it?
>>
>> 	- Paul
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Don't know whether this is related, but I now get the following error:
File 
"/py.src/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py", 
line 669, in draw_tex
 w, h, bl = self.get_text_width_height_baseline(s, prop, ismath)
AttributeError: RendererPS instance has no attribute 
'get_text_width_height_baseline'
with the the latest svn trunk ...
Manuel
Paul Kienzle wrote:
> In checking the mathtext rotation feature I found that the graph displayed
> fine, but python segfault'd shortly after displaying it. Most (all) examples
> are failing for me for svn r3778, even after rebuilding and reinstalling
> everything.
> 
> Is there something in the last couple of weeks which might cause this?
> 
> Running backend_drivers, the Agg plots are fine. 
> None of the PS plots are viewable with Preview.app. 
> I don't have an svg viewer handy.
> 
> I'm running macpython 2.5 fat binary build on OS X 10.4 with wx 2.8.
> 
> Anyone else having problems with it?
> 
> 	- Paul
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

Jouni K. Seppänen wrote:
> Paul Kienzle <pki...@ni...> writes:
> 
> [segfaults]
>> Is there something in the last couple of weeks which might cause this?
> 
> Some changes in font handling caused segfaults for me, and it turned out
> to be a bug in an old version of freetype:
> 
> http://article.gmane.org/gmane.comp.python.matplotlib.general/10062
> 
> Try running python under gdb, or using strace/truss/ktrace to see what
> is happening right before the segfault.
I'm not able to reproduce anything amiss on my Linux box.
I would try Jouni's suggestion, and if that doesn't work, please try 
going back to revision 3762, which is before I made a number of changes 
to the memory management of font buffers. If that works, but HEAD 
doesn't a traceback from gdb would be useful.
Cheers,
Mike

Paul Kienzle <pki...@ni...> writes:
[segfaults]
> Is there something in the last couple of weeks which might cause this?
Some changes in font handling caused segfaults for me, and it turned out
to be a bug in an old version of freetype:
http://article.gmane.org/gmane.comp.python.matplotlib.general/10062
Try running python under gdb, or using strace/truss/ktrace to see what
is happening right before the segfault.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

It's certainly possible my text rotation changes have caused this. I did all my testing on Linux, and didn't see any problems there.
It it the text_rotation.py example that segfaults for you or something else?
I'll have to look into this further when I get in to work.
Cheers,
Mike

In checking the mathtext rotation feature I found that the graph displayed
fine, but python segfault'd shortly after displaying it. Most (all) examples
are failing for me for svn r3778, even after rebuilding and reinstalling
everything.
Is there something in the last couple of weeks which might cause this?
Running backend_drivers, the Agg plots are fine. 
None of the PS plots are viewable with Preview.app. 
I don't have an svg viewer handy.
I'm running macpython 2.5 fat binary build on OS X 10.4 with wx 2.8.
Anyone else having problems with it?
	- Paul

Hi,
I have continued my work on supporting text.usetex for the PDF backend
by parsing dvi files. It "sort of" works now, with the following
caveats:
 - Your TeX distribution must have a kpsewhich command and a correctly
 configured pdftex.map file. This is true for modern distributions on
 Unix; I have no idea about Windows.
 - TeX "virtual fonts" are not supported yet; Computer Modern should
 work, but Times will usually not. Truetype fonts also are not yet
 supported (for usetex; they are for ordinary text).
 - Re-encoded fonts (in pdftex.map) probably do not work properly, and
 "font effects" such as slanting do not work.
 - Bounding boxes are not quite right.
 - The embedded Type 1 fonts are not subsetted, so output files are
 unnecessarily big.
 - The resulting PDF files sometimes crash Preview.app on OS X, and even
 if it doesn't crash, it doesn't show the fonts. There is probably
 some problem in the embedding, but xpdf, gv, and Adobe Reader seem to
 show the files just fine.
To enable, rename _draw_tex to draw_tex in backend_pdf.py and set
text.usetex to True.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

John Hunter wrote:
> On 8/30/07, Michael Droettboom <md...@st...> wrote:
> 
>>> ...but if we need to go into agg anyway, why not use Agg's font handling
>>> capabilities directly?
>> Perhaps historical reasons. I wonder if they're still relevant.
> 
> Yes, that's it. agg did not have font support when the agg backend
> was added. It was always easier to continue adding and extending what
> we had (ft2font) than to port over to agg's support.
I think that's probably still the case -- while we could do rendering 
with agg at this point, agg doesn't provide a very complete interface to 
the font's metrics. We'd still have to maintain *some* sort of C code 
for that anyway.
IMHO, I don't see any compelling reason to reduce the code in ft2font in 
favor of agg at this point.
Cheers,
Mike

On 8/30/07, Michael Droettboom <md...@st...> wrote:
> > ...but if we need to go into agg anyway, why not use Agg's font handling
> > capabilities directly?
>
> Perhaps historical reasons. I wonder if they're still relevant.
Yes, that's it. agg did not have font support when the agg backend
was added. It was always easier to continue adding and extending what
we had (ft2font) than to port over to agg's support.
JDH

SVN r3776 now has support for rotation of mathtext to any angle in the 
Agg backend (i.e. it's now supported in all backends).
Enjoy!
Mike
Michael Droettboom wrote:
> Paul Kienzle wrote:
>> On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote:
>>> Paul Kienzle wrote:
>>>> Hi all,
>>>> Before I look to deeply into this myself, is there anyone working on it 
>>>> already? Is there anything I need to look out for when implementing it?
>>> I've made a few excursions down that road --
>>>
>>> For bitmap font rendering, the entire math expression is first laid out 
>>> in a greyscale bitmap buffer, which is cached and then transferred to 
>>> the main plot bitmap. It was already that way when I got here, and I 
>>> assume that's an important optimization (so the text doesn't have to be 
>>> re-laid-out when the plot is zoomed/panned). I say "perhaps" because I 
>>> have no data to back it up, and don't know if that came out of profiling 
>>> or not.
>>>
>>> There are a few key low level pieces that are missing for rotation:
>>>
>>> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would 
>>> have to be added, or there may be a way to use 
>>> set_text/draw_glyphs_to_bitmap which does support rotation. However, 
>>> that would make rendering the entire expression to a single buffer much 
>>> more difficult.
>> Adding rotation to draw_glyph_to_bitmap looks like the easier option...
> >
>>> - The horizontal lines are all drawn as filled rectangles aligned to the 
>>> pixel grid, directly into the font buffers. That will probably have to 
>>> be pushed upward into the Agg layer to get good line drawing at 
>>> arbitrary angles -- but that also makes caching the bitmap a little more 
>>> difficult. So maybe it makes sense to implement our own Breshenham's 
>>> algorithm in ft2font.cpp.
>> ...but if we need to go into agg anyway, why not use Agg's font handling
>> capabilities directly?
> 
> Perhaps historical reasons. I wonder if they're still relevant.
> 
>>> All this will be affected by John's proposed refactoring of the 
>>> backends, of course, which has kind of kept me off of it in a "wait and 
>>> see" kind of mode. Right now, each backend has a custom interface to 
>>> communicate with mathtext -- whereas mathtext should simply be calling 
>>> the same low-level methods on all backends to get its job done. That, 
>>> of course, would make this buffer optimization harder (or at least it 
>>> would have to be thought about differently).
>> I haven't followed the refactoring proposal close enough to know if it
>> makes more sense to implement mathtext via freetype in agg or to use
>> freetype directly like you are currently doing. Once that decision is
>> clear, we can certainly prototype the handling of rotated text in the Agg
>> backend.
>>
>> Presumably this will have to be repeated for Cairo.
> 
> Cairo already works, as of a few weeks ago, it no longer uses bitmaps 
> for mathtext rendering. (I should have been more clear earlier -- my 
> brain has it filed in with the vector backends, though obviously it has 
> a resterizer.)
> 
>>> Let me know if you decide to implement this and let me know if you have 
>>> any questions about the code. Otherwise I'm happy to add it to my queue.
>> I can get by for now with limited text rotation, at least until the
>> backend refactoring has settled.
> 
> That may be a while (re: John's latest message). In the meantime, I'm 
> going to explore, as he suggested, how bad doing a raster rotation would 
> look, as that's the easiest path forward.
> 
> Cheers,
> Mike
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom <md...@st...> writes:
> With AFM reading in ft2font.cpp now, does that remove the need for
> afm.py?
What I added was a way to call FT_Attach_File, which is used to parse an
AFM file and add the metrics to an already existing Type 1 font object.
I don't know if there is any way to use Freetype's AFM parser without a
PFB file to attach the AFM file to.
> I know that the metrics are not exactly the same in a TTF vs and
> AFM, but is the interface through Freetype the same whether it's a TTF
> or AFM file?
Freetype tries to offer a unified interface to different font formats,
but for some stuff I think you have to query the sfnt tables (and what
have you) of a TTF font, which don't exist in Type 1.
TTF was historically developed because Type 1 was a proprietary Adobe
technology. Adobe published the spec right after that, but the font
formats are quite different as a result.
--=20
Jouni K. Sepp=E4nen
http://www.iki.fi/jks