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 <[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
