libtex.so
Olaf Weber
> I am currently investigating the possibility of repackaging the TeX
> interpreter into a program library. What I'd like, in the end, is to have a
> C header file and a shared library object which would allow programs to
> perform the .tex->.dvi conversion without the overhead of executing the tex
> interpreter externally. (Think "interactive typesetting" here)
Ambitious...
> Your Web2C implementation is the logical place to start working, naturally.
> I was wondering if someone of your experience could offer any advice to
> someone setting out on such a task...
Take a look at the IPC hooks, which may be doing part of what you
need: I think you can get with them to the point where you start TeX
once, then cycle between sending the data for a page and getting a
typeset page back.
Of course TeX wasn't designed for this kind of thing, which means you
have to be very careful with the macros being used.
> I've been looking through some of the relevant sources, particularly those
> that make up lib.a; checking the dependencies of the tex binary, etc. etc.
> So far, I foresee the following steps in making "LibTeX" come about:
> * Streamlining lib.a (that is, removing the modules not used by TeX--
> almost half of them can be eliminated);
Linking should remove them already.
> * Rerouting TeX's "interactive terminal" functionality, so that error
> messages become error codes to the client program;
> * Intercepting file I/O calls, some to allow control by the client program,
> some to allow I/O into memory buffers, etc.;
> * Defining a name-mangling header so that exported symbols internal to the
> library don't collide with client program code.
Potentially a painful thing to do: you have to deal with libkpathsea
as well, which isn't completely clean in that respect, as well as the
internal symbols of TeX itself.
> (I haven't really jumped into all this yet; right now I'm mostly trying to
> get an idea of what modifications will be necessary, how to go about
> implementing them, how the resulting work will be distributed, and so on)
> The issue of distribution is one I'm particularly concerned about.
> Eventually, I'd hope that LibTeX would be deemed acceptable for inclusion
> into the web2c package, so that it may become widely available. But it
> seems quite likely that it will need a customized lib.a, as a lot of the
> library calls need to be handled differently. Would there be a way of
> handling this that would be acceptable to you? (Perhaps a libtex/
> directory, containing the stripped-down, heavily-modified contents of
> lib/? I don't think anyone would want to add more #ifdef's to that code...)
First get it to work. Asuming its doesn't do things like doubling the
size of the distribution, inclusion can be discussed at that point.
> Any words to the wise appreciated,
Web2c is a moving target, make sure you keep in touch.
--
Olaf Weber
Part of being competent is knowing that you might be wrong ... even if
you were correct yesterday with the same answer. -- Barry Kearns