STIX fonts seem to be break with PDF or PS font subsetting. Looking into it...
Cheers, Mike Michael Droettboom wrote: > 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
