That's great news. I'm very curious how they look with mathtext. I'll be away from the office for the rest of the week. If any of you want to try it in the meantime, it's theoretically possible it already works (assuming there's no strange metrics issues in the font.) ---> Set mathtext.use_cm to False, and then set mathtext.it, .rm etc. to use the STIX fonts. 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). 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
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." > 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.
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). 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
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?
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? (That was a rhetorical question. I know we have gone around these circles a couple times before now.)
On 11/5/07, Darren Dale <dar...@co...> 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. 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
John Hunter wrote: > On 11/5/07, Darren Dale <dar...@co...> 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 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 <dar...@co...> 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 <dar...@co...> 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 <dar...@co...> 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
On Nov 6, 2007 1:05 PM, Michael Droettboom <md...@st...> 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. JDH
John Hunter wrote: > On Nov 6, 2007 1:05 PM, Michael Droettboom <md...@st...> 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? ;) 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Nov 6, 2007 1:36 PM, Michael Droettboom <md...@st...> 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 :-) 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
John Hunter wrote: > On Nov 6, 2007 1:36 PM, Michael Droettboom <md...@st...> 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 :-) 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 ;) 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... ;) Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Nov 6, 2007 2:09 PM, Michael Droettboom <md...@st...> 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 ;) I'd 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
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
I should also add -- it would be really nice to have STIX fonts working in the upcoming stable release if possible. Hopefully tomorrow morning I can assess how much work that will be and maybe delay tagging the release slightly so this can be worked through. It would be nice to remove the Computer Modern fonts (in mathtext only), but they still serve a niche in that they match the LaTeX fonts for users who can't/won't use usetex. So we're probably stuck with them for the long term even if STIX becomes a nicer/cleaner option. Cheers, Mike
On Sunday 04 November 2007 9:04:15 am Michael Droettboom wrote: > I should also add -- it would be really nice to have STIX fonts working in > the upcoming stable release if possible. Hopefully tomorrow morning I can > assess how much work that will be and maybe delay tagging the release > slightly so this can be worked through. It would be nice to remove the > Computer Modern fonts (in mathtext only), but they still serve a niche in > that they match the LaTeX fonts for users who can't/won't use usetex. So > we're probably stuck with them for the long term even if STIX becomes a > nicer/cleaner option. I haven't found sans-serif or monospaced fonts in their distribution. Maybe I don't know where to look. I sent an email to the STIX website asking about them, but havent heard back from them. I tried opening the fonts in fontforge, and there are a lot of missing glyphs. This is a beta release for the STIX fonts, and given how long it took to release and the number of self imposed deadlines that came and went, I wouldnt be surprised if there were some major issues that will need to be worked out. There is supposed to be a package for using STIX with latex, which they claim will be out by the end of the year, as will the final font release. Maybe we should start a pool!
Darren Dale wrote: > On Sunday 04 November 2007 9:04:15 am Michael Droettboom wrote: >> I should also add -- it would be really nice to have STIX fonts working in >> the upcoming stable release if possible. Hopefully tomorrow morning I can >> assess how much work that will be and maybe delay tagging the release >> slightly so this can be worked through. It would be nice to remove the >> Computer Modern fonts (in mathtext only), but they still serve a niche in >> that they match the LaTeX fonts for users who can't/won't use usetex. So >> we're probably stuck with them for the long term even if STIX becomes a >> nicer/cleaner option. > > I haven't found sans-serif or monospaced fonts in their distribution. Maybe I > don't know where to look. I sent an email to the STIX website asking about > them, but havent heard back from them. I tried opening the fonts in > fontforge, and there are a lot of missing glyphs. Unicode includes a "Mathematical Alphanumeric Symbols" range 1D400-1D7FF. The STIXGeneral font includes some (not all) sans-serif and monospaced Greek and Latin glyphs in that range. Mathtext won't actually use them yet, but doing so should be reasonably straightforward. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Thursday 01 November 2007 08:16:01 am Michael Droettboom wrote: > That's great news. I'm very curious how they look with mathtext. > > I'll be away from the office for the rest of the week. If any of you want > to try it in the meantime, it's theoretically possible it already works > (assuming there's no strange metrics issues in the font.) ---> Set > mathtext.use_cm to False, and then set mathtext.it, .rm etc. to use the > STIX fonts. It looks like findfont is not designed to identify OpenType fonts. The STIX license allows fonts to be converted, so I could probably generate ttf's, but maybe it would be better to modify font_manager to support otfs? Darren