# text bbox, postscript formatting problem

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)

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

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

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

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)

and STIX fonts when they are done

Let me make sure I understand this. If we map mathtext characters to unicode,
and use freefont for now, will that help prepare MPL for STIX fonts? If there
is an option available now that moves MPL in the direction of a permanent
solution, then it seems like the decision is already made. Can we come up
with some kind of a plan or design document for what steps we need to take? I
will pick at it after work, if I understand what needs to be done.

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?

Now that the new formatter is complete, I have to find new ways to
procrastinate. I will defend in August.

···

On Wednesday 04 May 2005 3:45 pm, John Hunter wrote: