texvc: antialiasing makes superscript z look bad
Closed, ResolvedPublic

Assigned To
None
Priority
Low
Author
bzimport
Subscribers
Pkra, fredw, wikibugs-l
Projects
Reference
bz15777
Description

Author: cbm.wikipedia

Description:
texvc image demonstrating the problem

In images produced by texvc, the vertical stroke on a superscript z isn't visible, making the z look more like the \approx symbol. Example image attached was taken from http://upload.wikimedia.org/math/9/b/e/9becb59e2f42cc312ced208fc5e4fe18.png


Version: unspecified
Severity: enhancement

Attached:

bzimport added a project: Math.Via ConduitNov 21 2014, 10:18 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz15777.
bzimport created this task.Via LegacySep 30 2008, 1:33 PM
brion added a comment.Via ConduitOct 2 2008, 8:28 PM

Presumably that's all a TeX rasterization issue... not sure what we could adjust?

bzimport added a comment.Via ConduitOct 2 2008, 11:23 PM

cbm.wikipedia wrote:

math image made on test wiki with dvipng

attachment zed3.local.dvipng.png ignored as obsolete

bzimport added a comment.Via ConduitOct 2 2008, 11:27 PM

cbm.wikipedia wrote:

math image made on test wiki with dvipng (correct version)

Attached:

bzimport added a comment.Via ConduitOct 2 2008, 11:31 PM

cbm.wikipedia wrote:

math image made on test wiki with dvips/convert

It seems the issue is with dvipng. I installed a test wiki from svn and texlive 2007 via the debian packages, and made two math images (attached).

One image uses dvipng 1.11. You can see I have the same problem as the wikimedia servers.

The other image uses dvips/convert to make the image. It does not have the antialiasing problem.

Software versions:
ImageMagick 6.3.7 05/02/08 Q16 http://www.imagemagick.org
dvips(k) 5.96.1 Copyright 2007 Radical Eye Software (www.radicaleye.com)

Attached:

bzimport added a comment.Via ConduitOct 2 2008, 11:59 PM

cbm.wikipedia wrote:

Testing suggests that disabling freetype (adding the --freetype0 option) may fix the problem with dvipng. The cost of this is that rasterized bitmap fonts will be stored on the servers.

bzimport added a comment.Via ConduitNov 25 2008, 2:15 PM

vgaburici wrote:

This looks like a problem with a newer version of dvipng and/or freetype. Using (on Fedora 9):

TeX, Version 3.141592 (Web2C 7.5.6) [TeXLive 2007]
dvipng 1.9
freetype-2.3.8-0.1.20080729cvs.fc9.i386

and a test document containing just "$e^{8z}$", I get a fairly well rendered z. I'll upload a picture.
I haven't tried it through the MediaWiki, but I doubt it would matter.

You can run dvipng in max debug mode (-d -1), and you get an ascii art version for each letter, as rendered by freetype.
This is how mine looks like (pretty visible :

OPEN FT FONT:	'/usr/share/texmf/fonts/type1/bluesky/cm/cmmi7.pfb'

@182 DRAW CMD: SETC_122

FT CHAR:	'z' 122 at (40,9) tfmw 250390
LOAD FT CHAR	122 (250390) (6x4)

DRAW GLYPH 122

0  68 170 119 153   0 |
0   0  34 153  17   0 |
0  68 136   0  34   0 |

34 153 119 170 68 0 |

CBM, what version of freetype are you using? Do you get the bug without involving MediaWiki?

bzimport added a comment.Via ConduitNov 25 2008, 2:33 PM

vgaburici wrote:

Hmm, I've tried TeXLive 2008, dvipng 1.11 statically linked to freetype 2.3.7 (binary from TL 2008), and I get the exact same grayscale image as above:

OPEN FT FONT:	'/tl/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi7.pfb'

@182 DRAW CMD: SETC_122

FT CHAR:	'z' 122 at (40,9) tfmw 250390
LOAD FT CHAR	122 (250390) (6x4)

DRAW GLYPH 122

0  68 170 119 153   0 |
0   0  34 153  17   0 |
0  68 136   0  34   0 |

34 153 119 170 68 0 |

So, the problem doesn't seems to be caused by dvipng 1.11 alone.

bzimport added a comment.Via ConduitOct 22 2013, 7:37 PM

physik wrote:

see http://math-test2.instance-proxy.wmflabs.org/wiki/15777
rendered with Math 2.0 which needs to get a review
https://gerrit.wikimedia.org/r/#/c/85801/

bzimport added a comment.Via ConduitOct 19 2014, 10:41 PM

physik wrote:

The changes of Math 2.0 got merged. So I expect that this bug is fixed.

Add Comment