Why is the math output hard to read sometimes?

[squidsoft]

May I suggest improving the format of the math output in the forum.

Consider the following code:

$$\mathop\textnormal{Res}\limits_{z=-n}\left\{\frac{\pi}{x^s\sin(\pi s)}\right\}=(-x)^n,\quad n=0,-1,-2,\cdots$$

The equal sign is not well displayed under the Res symbol and the "s" in sine is broken up. I've noticed other problems like this in general. I think PF would look more polished if the math output was nicer looking.

 

[phreak]

If I recall correctly, it used to be better. I'm not sure when or why the change occurred.

 

[DrGreg]

I suspect the problem might be that the LaTeX renderer (which generates the equation images) may work on the assumption that the equations will be displayed on a white background. On a grey background, some of the pixels are too faint. Is it possible to tweak the LaTeX renderer to take account of the grey background?

 

[chroot]

Hey all,

A year ago or so, something changed in the fonts included in the normal LaTeX distributions that come with most Linux distributions. Along with it were a number of other changes that broke PF's latex system. I rewrote some of it, but never really figured out the problem with the fonts.

I will look into it more. I don't actually think it has anything to do with anti-aliasing. The images are currently anti-aliased to white, and then white is dropped out as transparent. If the strokes look correct when anti-aliased to white, it seems that changing the surrounding white pixels to transparent would not affect them. It's worth a shot, though.

- Warren

 

[DrGreg]

Hey all,

A year ago or so, something changed in the fonts included in the normal LaTeX distributions that come with most Linux distributions. Along with it were a number of other changes that broke PF's latex system. I rewrote some of it, but never really figured out the problem with the fonts.

I will look into it more. I don't actually think it has anything to do with anti-aliasing. The images are currently anti-aliased to white, and then white is dropped out as transparent. If the strokes look correct when anti-aliased to white, it seems that changing the surrounding white pixels to transparent would not affect them. It's worth a shot, though.

- Warren

For what it's worth, I took the PNG image in post #1, on its default white background, and decreased the brightness until its background matched this thread's grey background. I think the result (attached) is therefore what you'd get if anti-aliased to grey. Slightly more legible, I think, but still not great, and I guess that's down to a poor choice of font. Or something.

 

[Moonbear]

Can the font be made bold, either in a default setting or when typed by the user (I never use LaTex, so don't know the ins and outs of this)? It just looks like the font is a bit thin and loses something, so if there's a way to make it bold, that might be enough to improve readability.

 

[DrGreg]

Can the font be made bold, either in a default setting or when typed by the user (I never use LaTex, so don't know the ins and outs of this)? It just looks like the font is a bit thin and loses something, so if there's a way to make it bold, that might be enough to improve readability.

That wouldn't be a solution as such, because some equations use both bold and plain font, e.g.

$$\mathbf{z} = a\mathbf{x} + b\mathbf{y}$$​

although personally I prefer

$$\textbf{z} = a\textbf{x} + b\textbf{y}$$​

However, if you have a greater choice of font weights than just "plain" and "bold", then some slightly heavier fonts might help.

 

[chroot]

Okay, guys... I changed some of the antialiasing behavior in Ghostscript (I turned it down!), and I think the output looks a little better now. If you could, post some troublesome LaTeX here and see if it renders better now.

- Warren

 

[chroot]

$$\mathop\textnormal{Res}\limits_{z=-n}\left\{\frac{\pi}{x^s\sin(\pi s)}\right\}=(-x)^n,\quad n=0,-1,-2,\cdots$$

 

[CRGreathouse]

$$\sum_{n=a}^bf(n)$$ has a very strong summation symbol.

 

[chroot]

This is how it looked with the old antialiasing options:

$$\sum_{n=a}^bf(n)$$

- Warren

 

[chroot]

And now the new:

$$\sum_{n=a}^bf(n)$$

It's really strange that antialiasing options could even cause this in the first place...

- Warren

 

[chroot]

And with no anti-aliasing at all:

$$\sum_{n=a}^bf(n)$$

- Warren

 

[chroot]

Fooling around some more:

$$\sum_{n=a}^bf(n)$$

 

[chroot]

Hmmm...

$$\sum_{n=a}^bf(n)$$

 

[chroot]

Try try again:

$$\sum_{n=a}^bf(n)$$

 

[chroot]

$$\mathop\textnormal{Res}\limits_{z=-n}\left\{\frac{\pi}{x^s\sin(\pi s)}\right\}=(-x)^n,\quad n=0,-1,-2,\cdots$$

 

[chroot]

I'm not really sure I've found a solution. I'll have to keep hunting.

$$\mathop\textnormal{Res}\limits_{z=-n}\left\{\frac{\pi}{x^s\sin(\pi s)}\right\}=(-x)^n,\quad n=0,-1,-2,\cdots$$

- Warren

 

[Moonbear]

Some of those versions looked better...not perfect, but certainly better.

 

[Fredrik]

$$\begin{pmatrix}1 & 0 & 0\\ 0 & \frac{u_x}{u} & \frac{u_y}{u}\\ 0 & -\frac{u_y}{u} & \frac{u_x}{u} \end{pmatrix}$$

Hm, both the parentheses and the zeroes look better than they did here. They used to look like the pixel size was bigger in the LaTeX font. I'm not a big fan of the new $$\sum$$ though, and x and y are still just barely legible. Have you tried a slightly bigger font size?

It would also be nice if the \dot code would make a slightly bigger dot: $$\dot{\vec r}$$ (but I realize of course that you can't do anything that changes only that symbol).

 

[robphy]

Could it be an issue with the number of colors in the rendered image?

It seems that many of the old LaTeX images were 8-bit images (up to 256 colors) but the new ones are 4-bit (up to 16 colors) [which have smaller file sizes]. (To save, I right-click on the image then save to my desktop.)

When counting colors in some of the new images, I get 4 colors.

 

[chroot]

I'm playing with it again, so expect a little weirdness.

robphy, the images are being generated explicitly as 8-bit. If they're somehow being down-converted, I'll have to figure out where...

- Warren

 

[tiny-tim]

Strange brackets (I'm seeing the right bracket much thicker at the top ):

$$\frac{dr}{d\tau}\ =\ \pm\sqrt{E^2\ -\ \left(1 - \frac{2M}{r}\right)\left(m^2\ +\ \frac{L^2}{r^2}\right)}$$

and don't the r and the tau look very similar?

 

[lisab]

Strange brackets (I'm seeing the right bracket much thicker at the top ):

$$\frac{dr}{d\tau}\ =\ \pm\sqrt{E^2\ -\ \left(1 - \frac{2M}{r}\right)\left(m^2\ +\ \frac{L^2}{r^2}\right)}$$

and don't the r and the tau look very similar?

Yes, the r and tau are too similar, IMO. But the brackets have a nice calligraphy look to them.

 

[chroot]

Argh I'm just making it worse!

- Warren

 

[qntty]

I don't know how they did it but mathlinks has very readable equations without cranking up the resolution higher than PF

 

[Hans de Vries]

I don't know how they did it but mathlinks has very readable equations without cranking up the resolution higher than PF

Impressive indeed:

http://alt2.mathlinks.ro/latexrender/pictures/e/6/f/e6f7873e4868755812ca60c34dd13a22e4ea785b.gif

Gif images with alpha anti-aliasing, so I presume they map to 32 bit ARGB colors...

Maybe one of these?

http://packages.debian.org/search?keywords=mimetex

Regards, Hans.

 

[CRGreathouse]

They say they're using LatexRender:
http://www.mayer.dial.pipex.com/tex.htm

 

[robphy]

Impressive indeed:

http://alt2.mathlinks.ro/latexrender/pictures/e/6/f/e6f7873e4868755812ca60c34dd13a22e4ea785b.gif

Gif images with alpha anti-aliasing, so I presume they map to 32 bit ARGB colors...

That image is 8-bit with about 27 indexed-colors...with transparency.
I suspect one can do fine with 4-bit grey images if it uses up to 16 indexed-colors.
Some of the images I found have been 4-bit with only 4 colors.

When PF first supported $$\LaTeX$$, it also was and has been impressive.
It's just recently that something seems to have changed.

 

[Hans de Vries]

It's indeed not mimetex which is like this:

http://www.sciencechatforum.com/documents/#preview

using:

\sum_{n=1}^{\infty}\frac{\chi(n) }{n^{s}}=\prod_{p\in\mathbb{P}}\left(\frac{1}{1-\frac{\chi(p)}{p^{s}}}\right)


Regards, Hans

 

[robphy]

And the current PF...
$$\sum_{n=1}^{\infty}\frac{\chi(n) }{n^{s}}=\prod_{p\in\mathbb{P}}\left(\frac{1}{1-\frac{\chi(p)}{p^{s}}}\right)$$

 

[Hans de Vries]

They say they're using LatexRender:
http://www.mayer.dial.pipex.com/tex.htm

Yes, They mention vBulletin forum here as well:
http://xyloid.org/projects/vblatex/Regards, Hans

 

[Greg Bernhardt]

The back end tools are all pretty much the same. Just takes some tweaking on chroots behalf.

 

[chroot]

Thanks for the links, guys. The LatexRender program seems to be doing exactly the same sort of stuff that I'm doing, so I'm going to look through it to find the subtle differences.

$$\sum_{n=1}^{\infty}\frac{\chi(n) }{n^{s}}=\prod_{p\in\mathbb{P}}\left(\frac{1}{1-\frac{\chi(p)}{p^{s}}}\right)$$

- Warren

 

[chroot]

Actually, it looks like LatexRender is using ImageMagick for its conversions from PostScript to png images, whereas I chose to use pstoimg many years ago. ImageMagick is a bit more resource-intensive, but I don't think it's a big concern.

I'm going to try switching to ImageMagick and see what happens... cross your fingers and toes.

- Warren