[tug-summer-of-code] Some Idea - TeX and Texas instruments

[Zachary Hoffman]

Hi, Jonathan

Thanks for the reply.  Actually, how did you reply?

> Please would you provide some links to some open source programs for
> these calculators, that might be similar to what in mind?

Certainly.  Graph³, a grapher of two-variable surfaces and
differential equations, is an application of great utility that brings
handheld calculators closer in functionality to more complex computer
algebra systems.
Graph³: http://www.ticalc.org/archives/files/fileinfo/247/24741.html
source: http://sourceforge.net/projects/graph3/

A Scheme interpreter for the 83+ was written in GSOC 2007.  It shows
that parsing source files created on more powerful systems can and has
been done on this platform.
Summer of Code page:
http://code.google.com/soc/2007/detached/appinfo.html?csaid=9BDCF5C6DDBB195E
binary: http://group.revsoft.org/scheme.8xk
source: http://group.revsoft.org/scheme.zip


DAWG (Dictionary and Word Games) was developed by Detached Solutions,
which also made Graph³.  Although it is freeware and not open source,
it is a good example of something with a fairly large database.
DAWG: http://www.ticalc.org/archives/files/fileinfo/258/25844.html
Detached Solutions: http://detachedsolutions.com/aboutus/

> I doubt that the calculator has enough memory to run a port of TeX...

If it used a single bitmap font for the final rendering and only
supported styles for ASCII characters, then the size of glyph-related
data should be around 160 kilobytes.

The DVI file format is unoptimized for (complete) machine readability
by nature and takes away TeX-specific aspects of a document, which is
unnecessary here.  Another option for document format is some
compressed form of source manuscripts, where commands are identified
by 16-bit numbers instead of their English representations.

Many macros could that are of no use on a calculator, such as those
that stray from monochrome rendering or embed active objects, need not
be included.

Displaying TeX typesets on a 96x64 LCD means that less of a document
is displayed at once, which would allow the device to render portions
of a document in less time while consuming fewer resources.  Users
could still read the text with ease with a simple autoscrolling (along
text) function and could navigate the document in a view where the
width of the document is fitted to that of the screen.

All in all, how does this proposal sound?  Thank you for giving it
consideration.

---
Zachary