[pdftex] TeX output as Java graphic

[Todd O'Bryan]

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 
> Headings I
> used virtual fonts to create the needed glyphs which I built from 
> several
> other fonts and used scaling and placement.  That was a lot of work.
>
> For the simple stuff you are describing, why not just use TeX and the 
> DVI
> previewer written in Java?
>
>