[pdftex] TeX output as Java graphic

[Jeffrey McArthur]

On Fri, 5 Dec 2003 18:01:51 -0500, you wrote:

>I was unclear. The math can't just be a stock image, it has to be a 
>manipulable graphic that we can modify, say to change the color of a 
>term, move (as in, physically move through animation) something from 
>one side of an equation to the other, or otherwise fiddle with.

You were not unclear, I understood what you wanted.

About a year ago, I nearly implemented the system you want.  I was playing
around with Java for project we were working on. If our client had not gone
out of business I might have had a demo you could have seen that did about
what you want.

>I suppose displaying a teeny DVI as a Java graphics object is an idea, 
>but don't you have to re-run TeX every time you want to change the 
>DVI's resolution or want to create a new image?

Yes you would have to rerun TeX.  But if you are just using Plain TeX and
not LaTeX, and just running small files, then TeX is very fast. If you would
like to see an example of using PDFTeX to quickly compose pages, try out
this:

http://custompub.atlis.com/

>Also, the kludginess of having to completely download TeX in all its 
>glory just to get the code that correctly handles boxes and glue seems 
>like overkill and the thought of how to package a Java application  
>that includes all of TeX so that it's easily installable is a little 
>forbidding.

First, you need to separate the concept of TeX and LaTeX.  TeX is TINY! I
have created an entire TeX implementation that fit on a 1.44 Meg 3.5" floppy
without compression.  You only need the executable for TeX, the format
files, and a few font files.  You do not need or want the entire LaTeX
distribution (which is huge).

We do this all the time.  We create turn-key typesetting systems using TeX.
Our "full" installation of TeX is about 20 files total.

I am one of those people who think that the TeX Directory Structure is a
mistake.  I agree with its goals, I just strongly disagree with its
implementation.  We tend to ignore the TDS completely.  It is too complex
and much too large for what we want to do.

Based on what you said you wanted to do you do not need the following:
    .sty files: there is no need for style files you are not running books
    .tfm files: if you are doing equations, Plain.fmt has all you need.
    tools like bibtex, dvips, metafont, metapost, or omega

You will need tex.exe, tex.pool, and plain.fmt.  Depending on your platform,
setting up a truely minimal configuration may be a bit of a challenge.  That
is not very well documented. For example setting up PDFTeX requires setting
up the .map, .cfg, and several other files.  You would also need the .pfb
files for any fonts.

If your directory structure does not have all the bloat normally associated
with a TeX implementation then TeX runs much faster because it has fewer
places to look and fewer files to check.

We recently created a demo disk for one potential client.  The demo disk had
no install program.  The data and our TeX files were all on the CDROM.  You
dropped the CD in the drive and it ran.  You could specify several options
and then press the compose button and it would generate the finished PDF.
This demo took a while to run, but it was generating something like 10,000
pages. You want to generate only one page.

If you are running on PC's, then try and find one of the older versions of
TeX that did not support massive amounts of memory.  The older EmTeX
installations used to have a version of TeX for the 8086 that ran in less
than 640K of RAM. That is tiny by today's standards.  It also very fast,
about 3 to 4 times faster than the larger memory versions of TeX.

>I hope it was clear that I wanted the ability to dynamically generate 
>new math in the program. I'm imagining in your system that my Java 
>program would call tex, find the DVI file it creates, grab the DVI 
>file, translate it to Java graphics, and then display it, modify it 
>slightly, then do the same thing again. You can't mean that, can you? 
>Maybe you thought I just wanted to create a few pretty formulas and 
>re-use them over and over again?

Actually that is close to what we do in our custom publishing systems.
Normally the process is a bit more complicated.  We export XML from a
database system, run PDFTeX to create a PDF file and display that.  If you
want to change the output, you change the database, re-export the XML,
recompose via TeX, and redisplay the PDF.

In your Java program, you would output a TeX file, then run Plain TeX (not
LaTeX), and display the DVI via Java. Check out idvi to display the dvi
files in Java.

TeX is small and fast.  I do mean rerun and rerun and rerun.

What we do is only a little different.  We are not coding in Java.  We are
coding in Delphi which means Windows. We also require the user to have a
full copy of Acrobat.  Using Delphi we automate both TeX and Acrobat.  We
output the XML file, compose it with PDFTeX, then display it in a window
which is actually Acrobat. With PDFTeX you have full access to colors
control and even Javascript in the PDF.  The downside to this is Acrobat is
very slow!

>MathML is XML, but it's also an encoding for the visual presentation 
>and semantics of math. Thus, you could take the object described by a 
>MathML expression and display it however you like; you're not just 
>limited to Unicode. I'm imagining we'd just have to use one of the 
>Computer Modern fonts to get all the glyphs we need.