Download TEX and/or

extending extex
147
been a great benefit. While the TEX program itself has proved hard to extend, the
macro language has provided programmers/users with ample opportunity to write
extensions.
The interprogram communication sketched above bypasses the macro language completely. As a consequence none of the extensions created in the 80s and 90s are available. When one looks at jadetex, one sees that it makes a good effort to pull in all
major packages written for latex2*. So, when we are not able to use those, we have
a big problem. It is even worse: we have even bypassed plain TEX; indeed, we do
not even have plain TEX’s output routine, because that is specified through control
sequences as well.
Karel Skoupy, the author of ExTEX, tells me that we do not even have a typesetting
engine; we have no more than a library. It is the macro language that glues it all
together into a typesetting engine. So my idea comes down to doing away with that
glue!
That is where my plans have stalled. I will need some bright ideas to find a way
forward.
Serving the files to ExTEX
When I had the ExTEX program, and took part in some discussions between its
author and its users, it soon became clear that there was a problem in the way ExTEX
finds the required files in the TEX distribution. Java, being a platform-independent
language, has problems communicating with the environment. The chosen solution
was to launch kpsewhich as a separate process to find the files for ExTEX.
While the kpathsea library has become a de facto standard, I am not ready to
accept it as the only way to locate files in a TEX distribution, now and in the future.
And therefore I do not think it a good idea to hard-code the use of kpsewhich into
ExTEX. I prefer a separation between the typesetting engine and the TEX distribution,
even though TEX has built-in file locating capabilities. I want a file locator architecture
that is configurable by the distribution. The setup of Java’s security mechanism, which
is extremely configurable, with the possibility to plug in third party implementations
of one or more functions, showed me how this could be achieved.
I constructed what I call the pluggable file locator architecture. ExTEX creates a
File Locator object which defines the required file location functionality and its API.
One or more implementations of that functionality may then be written, and added to
ExTEX as modules. Start-up options determine which of the available implementations
is actually used.
Basically, it works as follows. On the command line one has to tell ExTEX which file
locator implementation one wishes to use. This can be done using the java property
nts.filelocatorclass. Or it can be done in a configuration file, whose name should
be communicated to the application using the java property nts.filelocatorconfig.
An added bonus of a configuration file is that its path is communicated to the implementation, a feature which I use below in the kpathsea implementation. Extra
arguments can be passed to the implementation. For more information, see the doc-