John Hunter wrote:
Michael, I'm finally getting around to running the new mathtext
examples in mathtext_examples.py. Wow.
As before, I noticed a few things that don't look quite right -- as
usual, some of this may be bakoma font problems, and some may be
correct but just look funny to me, but I'll mention them briefly
- r'\\Delta\_i^j' : the j looks too far to the right
You're right. That's a bug that crept in. The other difference (that I just noticed now), is that the \Delta is slanted, where it isn't in TeX. The rules as to when a Greek character is italicized are a little unclear to me. (Only when lowercase?)
- \frac and \sqrt overbar: the horizontal line appears too thick,
can we make this thinner? THe look pretty good in PS, but too thick
in Agg.
With Agg (and by extension Cairo) the lines are drawn as filled rectangles rounded to the nearest integral pixel coordinates in FT2Font, rather than by using the line drawing functionality of Agg. The planned backend refactorings will make that easier, but there's probably ways to make it work now, I just haven't gotten around to it.
On a related note, the Agg backend suffers a little bit from the lack of subpixel character placement. The spacing of symbols can look slightly incorrect because of that (since their placement is rounded to the nearest integer), particularly at the smaller sizes. I haven't gotten around to experimenting with rounding vs. truncating to see if that alone makes it look any better.
The recursive frac examples are very cool!
- r"\\sqrt\[3\]\{\\frac\{X\_2\}\{Y\}\}=5", I would think the Y should be
under the X, but it is centered under the whole of X_2. Is this how
TeX does it?
Yes, that's how TeX does it. If you're curious, you can run "mathtext_examples.py --latex", which will produce a LaTeX file of all the examples and run it through pdflatex. That's what I've been using as a point of comparison as I go. Things don't match up perfectly -- tweaking is still ongoing. In general, with tons of due respect to TeX/LaTeX, while it's a good goal to emulate it as close as possible, if there are some things that we can improve on (within the much narrower context of matplotlib), I don't think we should shy away. Personally, I'm more concerned with getting the *semantics* as equivalent as possible, rather than the actual results. That goes along with my general weariness of exposing too many low-level commands, as that's where the real differences in the implementations lie. (But I may be totally off-base on those assumptions... I'd like to hear from heavy mathtext users about that).
- Hinting: you mentioned that the fonts looked so bad because they
lacked hinting. Is this something entirely missing from the fonts or
are we just not making use of it? With hinting, we would have a very
serviceable set of fonts, at least until the STIX fonts come out in
2018
That's something I haven't looked into very deeply, and it was just conjecture based on the fact that the fonts look much more "even" at higher resolutions. I don't know if the disabled hinting bytecodes in freetype are the cause. It definitely warrants further investigation.
- Kerning -- I may have mentioned this before. I have thought about
implementing autokerning by using the ink extent of the renderered
glyph in the freetype pixel buffer. This would enable us to properly
kern sin(2\pi) for example, if the ) char is in a different font file
than \pi. Over the vertical extent of the \pi, you could locate the
left most pixel ink of the ')' and kern it to the left a bit. Do you
think this is something worth doing, or do you have an alternative?
The cop-out answer is that TeX doesn't seem to do any kerning in math mode. Try the following: "AVA AVA", "({\it f}) \(f\)", for example. But that's not a reason to not do it.
That said, IMHO, we might get more mileage out of looking into ways to improve the low-level glyph rendering. The fonts look much better in acroread, for instance, than in ghostscript, with the same PDF file. Which leads me to believe it's not so much the quality of the font, but the rendering engine (or the way it's being used). I am not running the latest-and-greatest freetype2 library -- I don't know if that will make a difference.
The other thing that bothers me (but maybe not anyone else), is the font sizing. In TeX, when the font shrinks into a subscript, the characters get shorter, and the line widths stay relatively constant, rather than being uniformly scaled. The Bakoma fonts are actually available in a variety of sizes:
http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bakoma/ttf/
so it is doable -- it's just a matter of writing the machinery that selects fonts based on the level of logical font size. It would mean distributing a lot more fonts with matplotlib, but with the font subsetting stuff working, it shouldn't have a significant impact on resulting file sizes.
In the worst case scenario, one could use the spacing operators to fix
stuff up manually for publication, I suppose.
True.
Cheers,
Mike