Wiggly baselines

[GoogleCodeExporter]

What steps will reproduce the problem?

Certain examples in the test set at certain dpis have wiggly baselines. 
This has been a problem in mathtext on and off for a long time.  It seems
to be one of those bugs that comes and goes ;)  Currently it is here.  It
generally has to do with any integer rounding steps being performed on the
bounding boxes.

See, for example:

  accent2.stixsans.10pt.100dpi
  accent2.stixsans.10pt.300dpi
  mmltt17.bakoma.12pt.300dpi

SVN r81

Original issue reported on code.google.com by mdb...@gmail.com on 6 Aug 2009 at 1:40

[GoogleCodeExporter]

Tomorrow I'll check to see if it is present in the SVN version of matplotlib.
Hopefully if it comes and goes then we can nail the revision (be it mathtex or
matplotlib) that caused it and surround the offending code with warning signs.

Original comment by fred...@witherden.org on 6 Aug 2009 at 11:45

• Changed state: Accepted

[GoogleCodeExporter]

Further investigation reveals this to be not a bug in mathtex but a limitation 
of the
Image backend. FT2Font uses integer coordinates.

If one changes the tests to use the Cairo backend:
Index: tests.py
===================================================================
--- tests.py    (revision 90)
+++ tests.py    (working copy)
@@ -216,7 +216,7 @@

         if options.gen_output:
             m.save(os.path.join(os.path.dirname(__file__),
-                                "%s.%s.%dpt.%ddpi.png" % (name, font, 
fontsize, dpi)))
+                                "%s.%s.%dpt.%ddpi.png" % (name, font, fontsize,
dpi)), 'png', 'cairo')

         key = (name, fontsize, dpi, font)

The above tests render fine. This is because Cairo supports sub-pixel rendering 
for
text and graphics using floating-point coordinates.

Original comment by fred...@witherden.org on 7 Aug 2009 at 10:37

[GoogleCodeExporter]

Yes.  However, if two glyphs are given the same integer coordinate as input, 
their
baselines should be aligned, particularly if hinting is enabled.  Can you 
verify that
the integer rounding is happening correctly?

Original comment by mdb...@gmail.com on 7 Aug 2009 at 10:50

[GoogleCodeExporter]

I modified the test application to print the y-coord (m.glyphs[n][1]) of each 
glyph.
For the 10pt, 100dpi stixsans test:

freddie@fluorine ~/Programming/mathtex/tests $ python tests.py -t accent2 -T 10
Test 1 of 1 ['accent2' at (10.0, 100, stixsans)]
11.0
14.7361111111
14.7361111111
14.7361111111
10.109375
14.7361111111
14.7361111111
14.7361111111

The 11.0 and 10.1 are the accents. Everything else is the abcdef. The y-coords
actually passed to FT2Font (taking the iceberg into account) are:
freddie@fluorine ~/Programming/mathtex/tests $ python tests.py -t accent2 -T 10
Test 1 of 1 ['accent2' at (10.0, 100, stixsans)]
0.0
8.73611111111
4.73611111111
8.73611111111
1.109375
4.73611111111
8.73611111111
5.73611111111

The 4.73... are the b and the d. They sit high. More research is needed.

Original comment by fred...@witherden.org on 7 Aug 2009 at 11:31

[GoogleCodeExporter]

I have been looking into this issue today. The best I've come up with is to call
int() on ox and oy. However, this strips the sub-pixel precision from ox and oy.

So while it does fix this issue I am not convinced it is the right way to go -- 
or
that it is mathtex's fault.

I am currently poking over ft2font to see if the issue is there.

Original comment by fred...@witherden.org on 10 Aug 2009 at 5:04