Let's distinguish inlined anything from inlined IMAGES (non-interactive, non-
time-series based) of any format. The midaswww browser converts image formats
not supported by the browser into supported formats on-the-fly. It is not a
*BIG* project to allow the user to specify a set of translation programs for
non-supported image types that can be called when needed.
In a related message:
jonm@ncsa.uiuc.edu (Jon E. Mittelhauser) writes:
>
>All I was
>trying to point out is that by defining a limited set (e.g. Gifs and
>Xbms currently), an author can be guarnteed that the doc will look and
>feel exactly as intended.
Is the HTML author given that level of control over other aspects of the
HTML page, such as font families, sizes, weights, colors or a particular
external viewer? This seems to be perched on the same cliff as the markup
vs formatting debate was. IMHO, ultimately, and without C-hacking, to the
maximum extent possible, control of the decisions made in rendering of the
document should rest with the user, including the full range of source data
types of inlined images.
It seems that with a myriad of static image formats (not applicable to
time-series/interactive data types) around, and more importantly, the data
already locked up in those formats, that we would get more data to more people
faster if there were a standard, client-configurable mechanism for converting
foreign types into supported ones.
-marc
//////////////////////////////////////////////////////////////////////////////
// Marc Salomon e-mail: marc@ckm.ucsf.edu \\
\\ Software Engineer //
// Innovative Software Systems Group phone: 415.476.9541 \\
\\ UCSF Center for Knowledge Management //
// 530 Parnassus SF, CA 94134-0840 fax: 415.476.4653 \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\