STIX fonts

This is maybe another push in the direction of using fontconfig (which claims to support otf fonts already). I'd really prefer to go in that direction rather than continue to tack on partial reimplementations of it in font_manager.py -- but it does complicate dependencies on non-X11 platforms).

There is experimental support for using fontconfig (through the commandline interface, not an API wrapper), that may work. Just set the USE_FONTCONFIG variable to True in font_manager.py. You will have to copy the MPL fonts to a system font directory (such as ~/.fonts) in order for fontconfig to find them.

(I can also look into this myself when I return to the office on Monday...)

Cheers,
Mike

This is maybe another push in the direction of using fontconfig (which
claims to support otf fonts already). I'd really prefer to go in that
direction rather than continue to tack on partial reimplementations of it
in font_manager.py -- but it does complicate dependencies on non-X11
platforms).

What are the dependency problems? I thought freetype was the only requirement.
Incidentally, GIMP uses fontconfig on windows, and they comment at
http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary to what many
seem to think, fontconfig is in no way dependent on X11, so it does make some
sense to use it on Windows."

There is experimental support for using fontconfig (through the commandline
interface, not an API wrapper), that may work. Just set the USE_FONTCONFIG
variable to True in font_manager.py. You will have to copy the MPL fonts
to a system font directory (such as ~/.fonts) in order for fontconfig to
find them.

(I can also look into this myself when I return to the office on Monday...)

Same here, I'll have a look on Monday.

···

On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:

Darren Dale wrote:

This is maybe another push in the direction of using fontconfig (which
claims to support otf fonts already). I'd really prefer to go in that
direction rather than continue to tack on partial reimplementations of it
in font_manager.py -- but it does complicate dependencies on non-X11
platforms).

What are the dependency problems? I thought freetype was the only requirement. Incidentally, GIMP uses fontconfig on windows, and they comment at http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary to what many seem to think, fontconfig is in no way dependent on X11, so it does make some sense to use it on Windows."

Fontconfig depends on freetype and either expat or libxml2 (expat being the easier/lighter dependency).

But the real dependency problem is that on Windows it generally isn't already there. So it would have to be added to the external windows dependency zip, and we would probably have to go through a few contortions to call it as a commandline tool. 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.

On the Mac, fontconfig appears to be installed as part of Apple's X11 distribution, but not without it, even though it is useful outside of X11.

So, in case you can't tell, I've long been torn by this -- fontconfig solves the font lookup problem in a much more robust way than matplotlib will probably ever have the resources to do. On the other hand, it adds complexity to the matplotlib build req's. Perhaps if there were buy-in from some regular Windows and Mac devels to help maintain this going forward I wouldn't be so hesitant.

Cheers,
Mike

···

On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Darren Dale wrote:
>> This is maybe another push in the direction of using fontconfig (which
>> claims to support otf fonts already). I'd really prefer to go in that
>> direction rather than continue to tack on partial reimplementations of
>> it in font_manager.py -- but it does complicate dependencies on non-X11
>> platforms).
>
> What are the dependency problems? I thought freetype was the only
> requirement. Incidentally, GIMP uses fontconfig on windows, and they
> comment at http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary
> to what many seem to think, fontconfig is in no way dependent on X11, so
> it does make some sense to use it on Windows."

Fontconfig depends on freetype and either expat or libxml2 (expat being
the easier/lighter dependency).

Oh, your right.

But the real dependency problem is that on Windows it generally isn't
already there. So it would have to be added to the external windows
dependency zip, and we would probably have to go through a few
contortions to call it as a commandline tool.

I wonder if that comes with additional overhead.

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.

On the Mac, fontconfig appears to be installed as part of Apple's X11
distribution, but not without it, even though it is useful outside of X11.

So, in case you can't tell, I've long been torn by this -- fontconfig
solves the font lookup problem in a much more robust way than matplotlib
will probably ever have the resources to do. On the other hand, it adds
complexity to the matplotlib build req's. Perhaps if there were buy-in
from some regular Windows and Mac devels to help maintain this going
forward I wouldn't be so hesitant.

Thanks for explaining. What a headache. I wonder what other cross-platform
applications and libraries use to deal with fonts, like Qt and OpenOffice.
Are there native alternatives to fontconfig that are universally installed on
mac and windows? Or do all these projects have to roll their own solution
like we do?

···

On Monday 05 November 2007 8:07:04 am you wrote:

> On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:

(That was a rhetorical question. I know we have gone around these circles a
couple times before now.)

···

On Monday 05 November 2007 8:49:01 am Darren Dale wrote:

On Monday 05 November 2007 8:07:04 am you wrote:
> Darren Dale wrote:
> > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:
> >> This is maybe another push in the direction of using fontconfig (which
> >> claims to support otf fonts already). I'd really prefer to go in that
> >> direction rather than continue to tack on partial reimplementations of
> >> it in font_manager.py -- but it does complicate dependencies on
> >> non-X11 platforms).
> >
> > What are the dependency problems? I thought freetype was the only
> > requirement. Incidentally, GIMP uses fontconfig on windows, and they
> > comment at http://www.gimp.org/~tml/gimp/win32/downloads.html:
> > "Contrary to what many seem to think, fontconfig is in no way dependent
> > on X11, so it does make some sense to use it on Windows."
>
> Fontconfig depends on freetype and either expat or libxml2 (expat being
> the easier/lighter dependency).

Oh, your right.

> But the real dependency problem is that on Windows it generally isn't
> already there. So it would have to be added to the external windows
> dependency zip, and we would probably have to go through a few
> contortions to call it as a commandline tool.

I wonder if that comes with additional overhead.

> 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.
>
> On the Mac, fontconfig appears to be installed as part of Apple's X11
> distribution, but not without it, even though it is useful outside of
> X11.
>
> So, in case you can't tell, I've long been torn by this -- fontconfig
> solves the font lookup problem in a much more robust way than matplotlib
> will probably ever have the resources to do. On the other hand, it adds
> complexity to the matplotlib build req's. Perhaps if there were buy-in
> from some regular Windows and Mac devels to help maintain this going
> forward I wouldn't be so hesitant.

Thanks for explaining. What a headache. I wonder what other cross-platform
applications and libraries use to deal with fonts, like Qt and OpenOffice.
Are there native alternatives to fontconfig that are universally installed
on mac and windows? Or do all these projects have to roll their own
solution like we do?

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. 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) and we do not have support for OpenType (not sure how hard
this would be to add). Are there other problems?

While I am sympathetic to the desire to depend on standard,
maintained-by-someone-else, packages, I am also sympathetic to the
problems of users on a variety of platforms who are currently finding
mpl hard to build and install ( I had my own troubles on a new box
this weekend). If everyone were on ubuntu, life would be great, but
in the current environment adding a dependency (fontconfig) which
also has a dependency (xml parser) is a lot to take on.

I am definitely -1 on calling out to the command line. So if the
consensus is that we really need fontconfig, I would be inclined to
wrap the API and bring it in as an optional build dependency. Nadia
looked at this at one point: having a repository of dependencies which
the mpl could grab, unpack and build if needed. A general solution
for zlib, png, freetype and possibly fontconfig and friends would be a
welcome addition for OS X and win32 users.

JDH

···

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.

John Hunter 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

···

On 11/5/07, Darren Dale <darren.dale@...143...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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

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

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

This certainly seems to be the path of least resistance. Would there
be much savings in terms of file size if we just extracted the fonts
we need, eg the parts we need for latex expressions. If a significant
portion of the fonts are relatively inaccessible unicode, maybe we
should just distribute the subset we need.

JDH

···

On Nov 6, 2007 1:05 PM, Michael Droettboom <mdroe@...31...> wrote:

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.

John Hunter wrote:

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.

This certainly seems to be the path of least resistance. Would there
be much savings in terms of file size if we just extracted the fonts
we need, eg the parts we need for latex expressions. If a significant
portion of the fonts are relatively inaccessible unicode, maybe we
should just distribute the subset we need.

Now that subsetting works, I'd be more inclined to just include everything and let the backends sort it out. The total filesize of all the STIX fonts converted to .ttf is 1,334,524 bytes. Removing the font files that matplotlib can't currently access at all, the total is 1,167,920 bytes.

I don't consider that to be a large amount of space anymore. (Sourceforge provides the hosting and bandwidth anyway, right? :wink:

There is, of course, some time and memory overhead to loading larger fonts, but it may not be significant.

The other issue with subsetting the fonts before distributing them is just a matter of person-time: someone has to write the scripts to do it, and then re-run them when the STIX fonts are updated.

In the meantime, I'll commit the .ttf versions of the STIX fonts, and remove the .otf versions, which doesn't preclude subsetting the fonts further down the road.

Cheers,
Mike

···

On Nov 6, 2007 1:05 PM, Michael Droettboom <mdroe@...31...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sounds good to me -- if there were a big savings in file size I
thought it might be worth looking into, but he who writes the code
gets the most votes :slight_smile:

I think we should make stix the default for mathtext.fontset once you
get these changes incorporated, presuming PDF and PS work as expected
-- is there any reason not to?

JDH

···

On Nov 6, 2007 1:36 PM, Michael Droettboom <mdroe@...31...> wrote:

There is, of course, some time and memory overhead to loading larger
fonts, but it may not be significant.

The other issue with subsetting the fonts before distributing them is
just a matter of person-time: someone has to write the scripts to do it,
and then re-run them when the STIX fonts are updated.

John Hunter wrote:

There is, of course, some time and memory overhead to loading larger
fonts, but it may not be significant.

The other issue with subsetting the fonts before distributing them is
just a matter of person-time: someone has to write the scripts to do it,
and then re-run them when the STIX fonts are updated.

Sounds good to me -- if there were a big savings in file size I
thought it might be worth looking into, but he who writes the code
gets the most votes :slight_smile:

Not sure -- Maybe we were talking about different things... I was talking about actually removing individual glyphs from the files -- that may result in much larger savings percentage-wise, but would be labor-intensive. Removing whole font files is quite easy (and I actually did remove the files that mathtext can't currently access).

I think we should make stix the default for mathtext.fontset once you
get these changes incorporated, presuming PDF and PS work as expected
-- is there any reason not to?

No reason, other than the usual "hasn't been tested as much", and how that may affect the upcoming release. I anticipate more mis-mapped glyphs (I found some already, but I'm sure not all of them). But it won't get tested much unless people are nudged into using it :wink: I'd encourage people on this list to kick it around a bit before we widen the audience. But don't let that hold back the release -- it's always hard to know when to press that big red button... :wink:

Cheers,
Mike

···

On Nov 6, 2007 1:36 PM, Michael Droettboom <mdroe@...31...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Release early, release often. We can always roll out a bug fix
release, if Charlie is willing....

Charlie, what say you to an MPL 0.92.0 release for Monday or Tuesday
next week? I will work on the release notes and updates to the web
page in the meantime...

JDH

···

On Nov 6, 2007 2:09 PM, Michael Droettboom <mdroe@...31...> wrote:

No reason, other than the usual "hasn't been tested as much", and how
that may affect the upcoming release. I anticipate more mis-mapped
glyphs (I found some already, but I'm sure not all of them). But it
won't get tested much unless people are nudged into using it :wink: I'd

I have done some preliminary testing with the new changes to mathtext. The STIX fonts and Arev Sans fonts (still my favorite) both work well and produce pdf files that are readable by standard readers (e.g., Preview) and Illustrator. I am using Mac OS X, with the TkAgg backend.

Nice work,

-Rob

···

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331