>Version 1.0 is available for SunOS 4.1.3 - it does not do searching, it has
>printing problems, and is not being further developed.
It does run under Solaris (I use it regularly). I cannot vouch for this
other information which comes from the Adobe www page, under system
requirements for Acrobat:
Sun(TM) SPARCstation(R) workstation
SunOS(TM) version 4.1.3 or later, Solaris(R) 2.3 or 2.4
OpenWindows(TM) (3.0 or later) or the Motif(TM) window manager
(version 1.2.3 or later) for Acrobat
Reader or Acrobat Exchange
8 MB of disk space for Acrobat Reader; 20 MB of disk space for
Acrobat Exchange; 12 MB of disk space for
Acrobat Distiller
32 MB machine
HP Series 9000 workstation, model 700 or higher
HP-UX 9.0.3 or later
HPVUE desktop environment
6 MB of disk space for Acrobat Reader; 14 MB of disk space for
Acrobat Exchange
32 MB machine
>Cite them, please. I believe they do not exist.
See above. The only one I have personally seen with my own eyes is Acrobat
reader 1 for SunOS and Solaris; if you say the Adobe page is fibbing about
having an HP-UX version, I'll have to take your word for it.
But whether or not acrobat is or becomes an available solution, I think we
agree that it is not the preferred solution for encapsulating mathematics.
>Phill Hallam-Baker of W3C spoke to me last year about math support in HTML 3
>and the intention at that time was *not* to replicate TeX/LaTeX, which merely
>describe pictures of equations. He wanted to describe the equation; so there
>was enough info there to drop in intio say a symbolic algebra package or a
>graphing program.
This sounds right.
> That does not seem to have happened.
Too bad ... and I hope it isn't too late.
>OK, so I hear you saying that it must be possible to link into equations
>using fragment identifiers on URLs, and link out of equations (into HTML
>documents, and other things).
Yes. I wouldn't insist that fragment URL's be the linking syntax, but I do
not want equations to be blobs ("binary large objects", i.e., opaque stuff
whose internal structure is not accessible to browsers and other web
tools.)
>
>If you could do that using a media type other than HTML, but which could be
>embedded inline into an HTML document, would that satisfy your requirements?
Another media type *might* be ok, but the question is how its structure is
made comprehensible to web tools. Embedding it inline isn't enough --
again, that could be addressed by the "blob" solution. If inline embedding
is the approach to be taken, then the issue of internal structure is the
same as for other embedded objects: Are they only leaves of the document,
opaque to tools that understand html, or do they have structure that html
processing tools can access and manipulate?
I'll try to make this a little more concrete with an example. There are
tools that read a set of web pages and produce indexes. Those tools cannot
know specifics of every possible plug-in or applet. Can they include
portions (terms, variables, expressions) of equations in indexes?
Trying still to use concrete examples, here are two documents I imagine
writing:
1) Commuting diagrams are often the heart of a piece of theory of
supporting particular kinds of analysis of computer programs; a whole paper
can be written essentially to justify a commuting diagram. I would want to
link from arrows in the commuting diagram to the functions they represent,
and vice versa.
2) Computer programs are typically treated as text, but they are full of
expressions that are better considered as formulas, and typeset as such.
Such a typeset program should have lots of internal cross-referencing, and
external cross referencing both to other fragments of program (e.g., from a
variable reference to its declaration elsewhere) and to various kinds of
documentation.
My immediate concern is more with (2) --- I distribute a rather
simple-minded html pretty-printer for programs now, and I want to see it
evolve something that provides real, high-quality hyper-document
presentations of programs including but not limited to source code.
One could design a plug-in solution that permits this, but it would require
careful consideration of an architecture in which every plug-in is
responsible not only for producing displays of embedded objects, but also
for providing structural information --- internal link names at a minimum,
preferably hierarchical structure as well (e.g., I want an index of a
document containing program fragments to include elements from those
program fragments). Web indexing tools would need to know the protocol,
but wouldn't need to know other details of the internal structure of inline
objects supported by plug-ins.
Maybe this is being addressed already in the design of plug-in protocols. I
hope so, but I'm skeptical because embedded elements seem typically to be
thought of only as unstructured leaves of a document tree. Imagemaps are an
example of what happens when representation of internal structure is added
as an after-thought.
--Michal Young, Purdue http://www.cs.purdue.edu/people/young