Comment by syockit | Hacker News Reader

Comment by syockit | Hacker News Reader

TeXmacs is one of those apps that I reinstall from time to time when I want to scribble some math notes and find the split screen setup of most LaTeX editors or Markdown with preview too distracting. It is hands down the most pleasant to use for that purpose.

But I still get distracted by this one issue that bugged me since I first tried it 15 years ago: the anti-aliasing quality. The font doesn't look as crisp as what you'd see in other ClearType-enabled applications.

Earlier this year, I checkout out the SVN repository to see what's going with the renderer. The default Roman font is not TTF and cannot be rendered by FreeType, so TeXmacs has its own bitmap renderer for TFM fonts.

Basically, a glyph is rendered monochrome at a large size and then scaled down to the needed size with 8 color grayscale, IIRC. The bitmap is cached so wherever the glyph of the same style and size is needed, the same thing is drawn. Due to this, the font can sometimes look like it has weird kerning.

I tried to at least try subpixel rendering of the glyph bitmap to see if it makes things look better. The subpixel thing worked, but it didn't look any better. In the end, I gave up working on the issue.

I think that this issue was very interesting twenty years ago. With modern high resolution screens, I have to admit that we no longer bother too much...

In the future, we might only use Opentype fonts and use a font like TeX Gyre Pagella as our default font. I am afraid that we need to keep the old (tfm+pfb) Computer Modern as a legacy font so that people can reliably continue to use their old TeXmacs documents (remind that minor microtypographic changes may completely change lines and pages are broken).

I would be interested in improving (or at least experimenting) in this direction. Do you have any hint on what to do, or what was the problem when you tried? As with PDF we are not bound with a specific rendering pathway in the code, there could be the possibility to improve the Qt rendered for, at least, those fonts which are supported via Freetype.

I went back to see what changes I made to my local checkout. It seems I never made as far as to implementing subpixel rendering. I think I experimented with subpixel stuff on some other medium (maybe used GIMP to do the shifting manually, I forgot). So there may still be some hope.

On the other hand, regarding the kerning problem, there's not much you can do with the current one bitmap per glyph approach. One idea is to create multiple subpixel offset versions of the glyph. It'll cost more memory though. And the offset version of the bitmap may need to have its leftmost or rightmost column overlap the neighbouring glyph, and I'm not sure if the renderer supports gray level addition or if it would just overwrite the existing column from the previous neighbour.

As for Freetype supported fonts, there is an API for enabling subpixel rendering which you can call right before rendering the glyph. I've never experimented with it.

By the way, there is already a bug report created for this: https://savannah.gnu.org/bugs/?45629

Do you have some hints on where to look to see a good implementation of a text rendering engine implementing those features? (Browsers? which?)

There is another far lest costly thing that we can (should) do and that was long on my wish list (less and less high with the higher resolution screens :)

The idea would be to see words that are "broken" into characters and use a global hyphenation algorithm for optimizing the "breaking".

I've looked a bit around and in particular in the poppler library code to see how it works, they use QRawFont in the Qt backend to exploit subpixel antialiasing and native font technologies for each platform. We could do the same, essentially replace our glyph rendering code with something similar to their code. In this way we will make TeXmacs rendering similar to that of Okular, for example.

Reply on news.ycombinator.com