The STIX fonts are provided as OpenType wrappers around Adobe Compact Font Format (CFF or Type 2) fonts (sometimes called OpenType CFF or 'OTTO' font, because of the header tag on these files). With the Agg backend, this isn't a problem, since freetype supports these fonts transparently. However, the Ps and Pdf backends are more-or-less hardwired for TrueType fonts and will need to have significant tricky bits of code glued on to support these fonts.
<DETAILS>
In the PDF backend, the fonts work, with the exception of subsetting. I have patched the PDF backend so that it will fall back to the non-subsetting font output when it encounters an OpenType CFF font. This is not ideal, since the STIX fonts are so large.
The Ps backend does not support these fonts at all -- I have patched it to raise an exception when you try to use an OpenType CFF font. New code would need to be written to extract the CFF section from the OpenType wrapper and embed it in the PostScript drawing. I made a first attempt at this, but couldn't get it to work. The PostScript spec provides an example of wrapping the CFF in a PostScript wrapper, but not actually embedding the CFF in a Postscript drawing... Perhaps others on this list have some thoughts.
Agg, SVG and Cairo backends are working.
Long term, I think the font subsetting code should be rewritten so that it works with freetype (which understands all kinds of input font formats) on the input end, and then we should dump ttconv. (I say that regretfully, having been the one to suggest ttconv in the first place). The SVG backend already works like this. The reason the Ps and Pdf backends didn't go that route was to avoid dealing with the intricacies of writing those more complex font formats.
</DETAILS>
All that said (and sorry for the gory details), if we just convert the OTF STIX fonts to TTF, all these problems go away. matplotlib supports .ttf fonts quite well at this point. As Darren pointed out, the STIX license allows this conversion:
"""
3. You may (a) convert the Fonts from one format to another (e.g.,
from TrueType to PostScript), in which case the normal and reasonable
distortion that occurs during such conversion shall be permitted and (b)
embed or include a subset of the Fonts in a document for the purposes of
allowing users to read text in the document that utilizes the Fonts. In
each case, you may use the STIX Fonts-TM mark to designate the resulting
Fonts or subset of the Fonts.
"""
This fontforge script seems to do the conversion quite well:
#!/usr/bin/fontforge
Open($1);
Generate($1:r+".ttf");
Quit(0);
If there are no objections, I'll go ahead and do that and commit the results.
Cheers,
Mike
Michael Droettboom wrote:
···
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 <darren.dale@...143...> 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
