matplotlib-devel Mailing List for matplotlib

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

On Fri, Aug 31, 2007 at 01:22:54PM +0400, Farid Khalili wrote:
> I have just found matplotlib, and it seems to me that it is very good
> and promising product, albeit not yet as polished as octave/gnuplot
> pair.
As a long-time user of gnuplot, I find that in certain areas matplotlib
is more polished.
Gaël

On 8/31/07, Paul Kienzle <pki...@ni...> wrote:
> That's wonderful! I'm attaching a screen shot for wx 2.8 on OS/X.
>
> The rendering is kind of ugly, but I haven't looked into it.
My giess is that for some reason wx is not respecting the alpha
channel -- that will give you the rough, chunky text you are seeing.
I saw similar looking text when working with dvipng output before I
got the alpha channel right.
JDH

On 9/4/07, Manuel Metz <mm...@as...> wrote:
> Hello,
>
> I just re-created the patch against svn revision 3773 and also updated
> it on sourceforge. I also added a modified version of
> scatter_star_poly.py from the examples and its output.
>
> It would really be nice to have this patch applied
Thanks for the remionder Manuel -- I added the patch and example to svn

Just FYI -- this is what it looks like in Linux/wxGTK.
Paul Kienzle wrote:
> On Fri, Aug 31, 2007 at 03:28:49PM -0400, Michael Droettboom wrote:
>> There is now preliminary support for getting a mathtext bitmap to 
>> transfer to a GUI widget in SVN, along with a toy wxPython example in 
>> examples/mathtext_wx.py. I've only tested this on 
>> Linux/wxGTK2/wxPython-2.8. I'd appreciate help with testing (and 
>> screenshots) on any other platforms you may care about.
> 
> That's wonderful! I'm attaching a screen shot for wx 2.8 on OS/X.
> 
> The rendering is kind of ugly, but I haven't looked into it.
> 
> 	- Paul
> 
> 
> ------------------------------------------------------------------------
> 

Hello,
I just re-created the patch against svn revision 3773 and also updated 
it on sourceforge. I also added a modified version of 
scatter_star_poly.py from the examples and its output.
It would really be nice to have this patch applied
Manuel