Re: Google Summer of Code - LaTeX processing

[Patrick Noffke]

On Thu, May 30, 2013 at 12:26 PM, John Swensen <address@hidden> wrote:

On Thu, May 30, 2013 at 12:34 PM, John W. Eaton <address@hidden> wrote:

On 05/30/2013 12:19 PM, Patrick Noffke wrote:

On Wed, May 29, 2013 at 11:20 AM, John Swensen <address@hidden

<mailto:address@hidden>> wrote:

    A long time ago in 2008, I had spent just a few days looking at the
    problem you will be working on for GSoC. Here is a discussion about
    what I did on the mailing list archive:
    http://thread.gmane.org/gmane.comp.gnu.octave.maintainers/11892/focus=11911

    Your solution probably will end up being a lot better (seeing that
    you have a summer to work on it), but I simply tried to use
    mimeTeX (http://www.forkosh.com/mimetex.html)
    and
    mathTeX (http://www.forkosh.com/mathtex.html)
    to generate rasterized version of small LaTeX statements.

    For the life of me, I can't find my old code, but maybe this is a
    decent starting point. mimeTeX is a pretty limited implemenation of
    a LaTeX parse and doesn't use the standard fonts. mathTeX, on the
    other hand, uses an underlying LaTeX installation to generate the
    image of the _expression_ and crop it accordingly. I had also just
    tried to do my own calls to generate a PDF page, use pdfcrop, then
    convert to a raster, but mathTeX was doing something that made it
    much, much faster (e.g 200 per second).

    Hope this helps you get started, and I am looking forward to having
    TeX support in plot text objects!

    John Swensen

    address@hidden <mailto:address@hidden>

Thanks, John, that is very helpful background info.

You might also look at what matplotlib does for handling TeX and LaTeX markup.

jwe

The relevant code in matplotlib is completely contained in the file found at

https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/texmanager.py

Also see a similar Markdown implementation at

https://github.com/justinvh/Markdown-LaTeX

I just went and looked at the source for mathTeX (which is a single .c file) and they do essentially the exact same thing as matplotlib (though it might be interesting to see how the header .tex header information differes between the two).  I know when I tried to go this route of generating a LaTeX file, running LaTeX, and converting to raster that mine was much slower than mathTeX.  Looking closer, it is probably because I was generating a full page with pdfLaTeX and then running pdfcrop.  They seem to generate a DVI and use dvipng with a 'tight' parameter to crop it.  I'm assuming that is where their speedup comes from? You could possibly even just look at the sources of dvipng to get a raster buffer directly, rather than extracting it from a png file.

I am looking forward to having this feature. I am sick of adding proper labels through Inkscape and LaTeXIt, but guess I wasn't motivated enough to finish what I timidly started years ago. I keep saying that when I don't have that next proposal or next paper due that I will contribute more, but I am starting to wonder if that will ever happen.

John

Thank you both for the excellent info.

Andrej had in fact planned to follow an approach similar to that used by matplotlib.  His public proposal can be found here:

http://wiki.octave.org/User:AndrejLojdl

Michael also suggested an initial project for Andrej to get familiar with the code.  That was to support multi-line text items.

I was also talking with Michael about LaTeX support on IRC.  I think it makes sense to follow matplotlib's approach (or something like that) for screen rendering, but for printing, I think we need to be able to convert to postscript.  Andrej, this might be outside your planned scope, but once you start digging in the code, you might find it makes sense to account for both screen and print.  I think following the current approach for text is a good plan.  Maintain the text (including LaTeX strings) until you need to render it, then call on the appropriate renderer.  You might need to create two renderers for print vs. screen, but maybe there's another way that is cleaner.  I have to spend some time reviewing all the above info.

Andrej has an exam coming up on Saturday, so please give him some time to be able to review all this himself.

Andrej, please let us know if you have any questions along the way.  And good luck on your exam!

Pat