The STIX fonts are now passing the mathtext_examples.py unit test. This
font blends much better with fonts like Times.
The rcParam "mathtext.use_cm" (which is new since the last release) has
been replaced with "mathtext.fontset" which takes either "cm", "stix" or
"custom". To use the STIX fonts, set it to "stix". While "custom"
mostly works with the STIX fonts, "stix" will turn on a little extra
code that knows how to use the dynamically sized characters (such as the
radical sign) from the correct STIX fonts.
There are far more characters in the STIX fonts than in the Bakoma
fonts, and many of them are not accessible through a "named" symbol,
such as "\foo". At present, matplotlib only understands the common math
symbols in core LaTeX, and a handful of symbols defined in commonly used
LaTeX extension packages. Ideally, now that we have much more complete
fonts, we could create mappings from all the symbols in the
"Comprehensive LaTeX symbol list" to Unicode, but that's a considerable
amount of bookkeeping work, unless someone else has already done it for
some other project. I suspect that there's a 90/10 rule here: 90% of
users use 10% of the symbols, and vice versa. (It may even be more like
99/1.)
As a way around this, you can insert Unicode characters directly into
the math string and it will correctly use that character in the STIX
font. For example, the following will produce a carriage return symbol:
ur"$\u23ce$"
This even works for the *really* rare symbols (that don't have an
official Unicode code point and have been placed in the "Private Use
Area" codepage in a separate font file)... matplotlib has a little extra
code to use the "Non-Unicode" fonts when necessary (when the codepoint
is E000 - F8FF).
Currently, there's no way to get at all of the fancy integral signs that
STIX provides.
Cheers,
Mike
Michael Droettboom wrote:
> John Hunter wrote:
>> On 11/5/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>>>>> If we go the route of
>>>>> wrapping the API (which would be better anyway, since then we could look
>>>>> for fonts in our own custom font directory), it would just be like the
>>>>> existing dependencies on freetype and libpng. Not a big deal, really,
>>>>> but it adds an additional maintenance burden on those Windows
>>>>> dependencies.
>> My inclination is to try and fix font_manager. Paul's goal was to
>> implement the W3C specification for cross-platform font finding, which
>> seems like a good starting point.
>
> IMHO, it's just a not a very good algorithm. The key section (when an
> exact font-family match can not be found) is this:
>
> "UAs that implement intelligent matching may proceed to examine other
> descriptors such as x-height, glyph widths, and panose-1 to identify a
> different tentative font family. If there are matches for *all* the
> remaining descriptors, then that is the matching font face for the given
> element." (Emphasis mine).
>
> Certainly one can do better than all-or-nothing like this. Something
> like a weighted nearest neighbor match would result in much better near
> matches.
>
>> So far, I've heard two complaints
>> about the current setup: font_manager will throw up its hands and
>> return a default if an exact match fails rather than returning the
>> closest (this doesn't seem too hard to improve upon in the existing
>> framework)
>
> Not a lot of work, but the main data structure for lookups will need to
> be completely different. Right now it is a tree with font-family name
> at the top, so if that fails it's difficult to find something close.
>
>> and we do not have support for OpenType (not sure how hard
>> this would be to add).
>
> That's easy -- freetype handles them correctly and the interface to the
> metadata ends up looking the same as a ttf file. It's only because of
> the different file extension that they are not being seen now. I'll
> have a patch shortly.
>
>> Are there other problems?
>
> .dfont support on the Mac -- it only looks at the first font in the
> file. (Though, when I checked fontconfig a few months ago, it also
> exhibited this problem.)
>
> Maintaining a separate font cache means that the user must know to
> delete the matplotlib font cache file in order to use newly installed fonts.
>
> Cheers,
> Mike
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
