To fix this one should get the kerning information from the
>> font, and do the kerning manually. Have a look at dvips output
>> to get inspiration.
Now that we understand the problem, we have two options.
* We can manually do the kerning in draw_text for the truetype
fonts. This won't be hard because we can just follow the example
of draw_unicode with minor modifications. This will be a little
slower and make ps files a little bigger, but will look the best.
* we can add a kwarg to font.get_width_height() to ignore kerning
information, and backend ps can call
font.get_width_height(kerning=False).
> I also had a look at the dvips output, and get the general
> idea of how it handles layout. So let me ask, why does
> mathtext break with afm fonts? Is it inherent, or could
> mathtext.py (or backend_ps.py) be changed to cooperate
> with afm? From looking at the dvips output, a naive
> individual like myself might think it is pretty straight
> forward to render something like r'My test string
> A=A\_0e^\(i\\theta\)'. (I'm not saying it would be easy to
> implement.)
> Dvips embeds four fonts to render my example string:
> CMMI7, CMR7, CMMI10, CMR10. Here is the output, I clipped
> the start of the file up to the end of the font defs:
I started working with AFM fonts in my initial implementation of
mathtext, but before I got too far Paul took on the task of porting
mathtext to PS and decided to embed the truetype fonts. This has the
advantage of having your postscript figure and screen figure look
nearly identical and also just gives us a single point of maintenance
in the mathtext module. But there are problems as well, as you've
noticed
* the bakoma fonts suck in my opinion, some glyphs render poorly.
Paul and I were never able to figure out how the vertical offsets
in cmex worked, they have licensing problems
* the use of bakoma fonts for mathtext and other fonts for the rest
of the figure looks bad, and may be unacceptable for publication.
One solution is to use cmr as your default font (set the rc param)
but then see the problem above.
We could go the route of embedding type1 fonts and using afm files for
layout -- this wouldn't be too hard. But our energy might be best
served by converting the mathtext data tables to map text characters
to unicode and then using a set of unicode fonts, using freefont for
now (GPLd I think)
http://sourceforge.net/mailarchive/forum.php?thread_id=7090823&forum_id=36187
and STIX fonts when they are done http://www.stixfonts.org (which
should be just a few months according to their web site, but then
again their FAQ says "The STIX Fonts will not be completed until some
time in 2003" so we should be cautious....)
See also
http://www.mozilla.org/projects/mathml/fonts/
I realize you have a thesis to print, so hopefully we can figure out a
smooth path to success soon! When do you need to turn that thing in?
JDH