# [pdftex] TeX output as Java graphic

Todd O'Bryan toddobryan at mac.com
Sat Dec 6 00:01:51 CET 2003

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.

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?

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.

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?

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.

Todd

On Dec 5, 2003, at 11:33 AM, Jeffrey McArthur wrote:

> On Thu, 4 Dec 2003 21:33:44 -0500, you wrote:
>
>> How hard would it be to pull out the code from TeX that typesets small
>> snippets of text (the primitives, I guess it would be) so that I could
>> pass a string like "$x^2+y^2=25$" (or its MathML equivalent) and a
>> starting point and have that small image be typeset correctly at that
>> point. Is anyone aware of anybody doing something like this or leaning
>> in that direction?
>
> Why pull out the code, just use TeX. Try this:
>
> \shipout\hbox{$x^2+y^2=25$}\bye
>
> That will leave the 1in offsets on the page.  This is a bit longer:
>
> \hoffset=-1in
> \voffset=-1in
> \shipout\hbox{$x^2+y^2=25$}
> \bye
>
> That will shipout into the DVI file the equation in an hbox. The page
> size
> will be just the size of the equation.
>
>> I've looked at MathML and I must say I'm rather disappointed in the
>> lack of open source tools, and the relatively low quality of the
>> renderers that currently exist. Maybe I've missed something. If so,
>> please correct me. If not, would someone be willing to answer
>> questions
>> about how everything hangs together in TeX so my student and I could
>> get a handle on what data structure we'd need to set up and which
>> primitives we'd have to implement so that we could do small snippets
>> of
>> arbitrary math fairly easily.
>
> MathML is XML which implies Unicode. That sort of assumes you would be
> working in UTF-8. If you are working in another encoding, you are on
> you
> own. Typesetting UTF-8 Unicode with TeX can be done. I wrote the code
> to
> typeset the Library of Congress Subject Heading books in TeX:
>
> http://www.atlis.com/new/announcements/loc.html
>
> The hardest part about Unicode is finding the glyphs and/or fonts you
> need.
> The Unicode 4.0 standard still does not have many of the glyphs needed
> for
> the Library of Congress Subject Heading book. Since the glyphs are not
> part
> of the standard they are not in in Unicode font.  You have to draw
> and/or
> build them yourself.  When I did the Library of Congress Subject