questions regarding mathtext

Hi,

I have a question regarding the pure python latex rendering engine. If
I look here:

http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts

was this generated using it? If so, it seems to me it doesn't look
exactly as TeX output, for example in the sqrt(2), the upper line is
slightly over the edge of the \/ line in the sqrt.

Or in the s(t) = Asin(wt)

the "A" and "sin" is too much close to each other. Or if you scroll to
the very bottom of the page, the Sum and x_i are also too much close
to each other.

Is it a font problem? If yes, how could this be fixed? If not, would
it be difficult to find the problem in the algorithm and fix it? I
haven't studied the TeX algorithm deeply,
so I cannot judge if it's a trivial fix, or something very difficult.

Otherwise it looks good. We were thinking with Stefan that when we get
to Austin together on around August 8, we'll polish it and get it to
sphinx by default, so that any other project, like numpy or sympy
could use it as well easily.

Thanks a lot,
Ondrej

Ondrej Certik wrote:

Hi,

I have a question regarding the pure python latex rendering engine. If
I look here:

http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts

was this generated using it? If so, it seems to me it doesn't look
exactly as TeX output, for example in the sqrt(2), the upper line is
slightly over the edge of the \/ line in the sqrt.
  

The fudge factor to get this in the right place (since the position of the tick isn't exactly as the metrics would lead us to believe), was dpi dependent. This has been fixed.

Or in the s(t) = Asin(wt)

the "A" and "sin" is too much close to each other. Or if you scroll to
the very bottom of the page, the Sum and x_i are also too much close
to each other.
  

This is a harder problem. Unfortunately, unlike TeX, we don't have any tables of cross-font kerning information. This could perhaps be remedied by making everything a little looser, but I don't see a way out outside of writing kerning tables or doing autokerning (haven't looked deep enough to know how hard that might be). We could hard code some hacks for the common cases (especially the summation symbol), which would at least create a framework for custom kerning tables, even if we only fill in some of the combinations. And of course, since we support three different font sets (cm, stix and stixsans), these hacks will have to be customized for each.

Is it a font problem? If yes, how could this be fixed? If not, would
it be difficult to find the problem in the algorithm and fix it? I
haven't studied the TeX algorithm deeply,
so I cannot judge if it's a trivial fix, or something very difficult.

Otherwise it looks good. We were thinking with Stefan that when we get
to Austin together on around August 8, we'll polish it and get it to
sphinx by default, so that any other project, like numpy or sympy
could use it as well easily.
  

Look at mathpng.py in the matplotlib/doc/sphinxext directory. That (plus an installation of matplotlib) should be all you need. It probably needs to be generalized to put the image files in the right place. (Currently in puts them in _static/ -- maybe that should be somewhere under build/).

Or course, matplotlib is using this approach for its docs as a matter of "dogfooding". It may be that the more appropriate choice for Sphinx in general is something that uses latex/dvipng, since latex is already a requirement for Sphinx in general.

Cheers,
Mike

···

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

I agree.

···

On Wednesday 09 July 2008 09:41:08 am Michael Droettboom wrote:

Ondrej Certik wrote:
> Hi,
>
> I have a question regarding the pure python latex rendering engine. If
> I look here:
>
> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts
>
> was this generated using it? If so, it seems to me it doesn't look
> exactly as TeX output, for example in the sqrt(2), the upper line is
> slightly over the edge of the \/ line in the sqrt.

The fudge factor to get this in the right place (since the position of
the tick isn't exactly as the metrics would lead us to believe), was dpi
dependent. This has been fixed.

> Or in the s(t) = Asin(wt)
>
> the "A" and "sin" is too much close to each other. Or if you scroll to
> the very bottom of the page, the Sum and x_i are also too much close
> to each other.

This is a harder problem. Unfortunately, unlike TeX, we don't have any
tables of cross-font kerning information. This could perhaps be
remedied by making everything a little looser, but I don't see a way out
outside of writing kerning tables or doing autokerning (haven't looked
deep enough to know how hard that might be). We could hard code some
hacks for the common cases (especially the summation symbol), which
would at least create a framework for custom kerning tables, even if we
only fill in some of the combinations. And of course, since we support
three different font sets (cm, stix and stixsans), these hacks will have
to be customized for each.

> Is it a font problem? If yes, how could this be fixed? If not, would
> it be difficult to find the problem in the algorithm and fix it? I
> haven't studied the TeX algorithm deeply,
> so I cannot judge if it's a trivial fix, or something very difficult.
>
> Otherwise it looks good. We were thinking with Stefan that when we get
> to Austin together on around August 8, we'll polish it and get it to
> sphinx by default, so that any other project, like numpy or sympy
> could use it as well easily.

Look at mathpng.py in the matplotlib/doc/sphinxext directory. That
(plus an installation of matplotlib) should be all you need. It
probably needs to be generalized to put the image files in the right
place. (Currently in puts them in _static/ -- maybe that should be
somewhere under build/).

Or course, matplotlib is using this approach for its docs as a matter of
"dogfooding". It may be that the more appropriate choice for Sphinx in
general is something that uses latex/dvipng, since latex is already a
requirement for Sphinx in general.