matplotlib-devel Mailing List for matplotlib

On Wednesday 11 July 2007 05:50:19 pm Eric Firing wrote:
> Mike, John,
>
> I sent an inquiry to stixfonts based on
> http://www.stixfonts.org/swdev_geninfo.html#; I will let you know if
> they come back with anything. It does look like a genuine release is in
> sight. But are these fonts all based on Roman style, with serifs,
> correct? That seems unfortunate; I think that for most plotting
> purposes, sans-serif works better.
I thought they were going to include both serifs and sans-serifs, but I might 
be wrong. I'm on the list to receive the beta package when it is available, 
which could be any day now.
Darren

Mike, John,
I sent an inquiry to stixfonts based on 
http://www.stixfonts.org/swdev_geninfo.html#; I will let you know if 
they come back with anything. It does look like a genuine release is in 
sight. But are these fonts all based on Roman style, with serifs, 
correct? That seems unfortunate; I think that for most plotting 
purposes, sans-serif works better.
Eric

Mike,
The attached file masked_interior.py illustrates masking failure in a 
very simple case; you can see masking working in the plot on the left, 
where a contour intersects the masked region, but when that contour 
level is removed the masked region is getting filled in.
The file contourf_demo.py is slightly modified from the one in the mpl 
examples directory, and shows a failure of masking in a more complicated 
setting. The masked region at the lower-left corner is correct, but the 
masked region in the middle of the plot is getting filled with gray 
instead of being left blank.
In cntr.c there is a function, print_Csite, that may be helpful for 
debugging the simplest case, where the array size is not too large.
Note that the code path for filled contours is quite different, and more 
complicated, than for line contours--and in fact, even neglecting branch 
cuts, the two code paths don't always yield the same contours.
cntr.c is somewhat unusual among contour algorithms in that it works 
with rectangles without subdividing them into triangles.
Eric

Michael Droettboom <md...@st...> writes:
> This approach is reported to work on "Macintosh, Unix, and Windows",
> but I've only tested on Linux and OS-X. Please let me know if it
> solves your issue.
It solves my problem on OS X. Thanks!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
> 
>> "John Hunter" <jd...@gm...> writes:
>>
>> 
>> 
>>> On 7/10/07, Michael Droettboom <md...@st...> wrote:
>>> 
>>> 
>> I'm seeing a bug on OS X, whose file system is by default
>> case-preserving but not case-sensitive:
>>
>> 458 -> fontdictObject = self.embedTTF(
>> 459 filename, self.used_characters[filename])
>>
>> Here self.used_characters has a key starting with '/Users/jks/...' but
>> filename is '/users/jks/...'. I'm not sure how to fix this cleanly. 
>> I though os.path.normcase would help, but it doesn't:
>>
>> 
>> 
> Thanks for that. The Ps backend has the same problem. I'll do a little 
> research and see what a common solution to this might be.
>
> 
I changed the code to use the file's (st_ino, st_dev) pair as a key, 
rather than the path. This is cached to prevent lots of little stat 
calls. This approach is reported to work on "Macintosh, Unix, and 
Windows", but I've only tested on Linux and OS-X. Please let me know if 
it solves your issue.
Along the way, I found an interesting discussion about why normcase does 
what it does on OS-X. (Summary: because file names are case sensitive 
on OS-X, but not the default HFS+ filesystem that Macs ship with as 
their System volume.)
http://mail.python.org/pipermail/python-list/2006-January/360098.html
Cheers,
Mike

I've tested this approach with Firefox 2.0 and rsvg 2.16. The text 
alignment is actually much better since the text layout is fully under 
the control of matplotlib. This has been checked into SVN, and can be 
used by setting the rcparam "svg.embed_char_paths" to True.
The following are my usual "size benchmarks" (that I used for PS and PDF 
as well):
without character paths -> with character paths
fonts_demo_kw.py: 10314 -> 69256
mathtext_demo.py: 10606 -> 37896
unicode_demo.py: 7677 -> 43473
over all demos in backend_driver.py: 17,722,815 -> 18,789,999
Cheers,
Mike
Michael Droettboom wrote:
> Actually, it just occurred to me that you could use 'defs' and 'use' to 
> define characters as paths and reuse them. And that's something that 
> works today in virtually any SVG renderer.
>
> It totally blitzes the logical representation of the text (i.e. 
> searching and copying as text etc.), but if it was only done for math 
> text, then that's probably not a big deal. IMHO, math text is where 
> matching the exact font is most important, where a reasonable substitute 
> is often not installed, and where searching doesn't make a lot of 
> sense. In any case, editing the SVG in something like Inkscape will be 
> harder, since the text has become raw paths.
>
> Thanks to ft2font, it was fairly easy to get outlines of math characters 
> embedded in the SVG file. I've put up an example mathtext_demo.py SVG here:
>
> ftp://ftp.stsci.edu/tmp/mdroe/mathtext_demo.svg
>
> I'll commit this code once it's cleaned up and better tested etc. if 
> it's agreed this is something we want to do. I think in any case this 
> should be optional -- it gives the file some portability at the expense 
> of editability.
>
> Cheers,
> Mike
>
> Carl Worth wrote:
> 
>> On 2007年7月10日 13:43:49 -0400, Michael Droettboom wrote:
>> 
>> 
>>> "major SVG renderers" support seems to be the issue at first glance.
>>> None of the big open source options -- Firefox, inkscape, rsvg -- seem
>>> to support it.
>>> 
>>> 
>> That's my understanding as well.
>>
>> 
>> 
>>> Until there's something readily available to test with, there's probably
>>> not much point.
>>> 
>>> 
>> It's a classic chicken-and-egg. I know the cairo-svg maintainer is
>> hoping to add SVGFont stuff to cairo's SVG output to try to boostrap
>> past this problem.
>> 
>> 
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>