[comp.text] Fallback and alternate presentations in multimedia/text mail systems

craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/16/90)

Has anyone ever heard of a multimedia mail or document system which supports
explicit fallback or upgrade to support varying terminal/user capabilities ?

I have seen the 'Andrew image was here but can't be shown...' sort of thing.
I am wondering if anyone has built a system with explicit fallbacks.  For
instance, even if the image can't be shown, why can't a brief caption that
describes it, or even a character-based alternate, be shown ?  This would
be useful for machine text searching, trademarks and signatures, and
captioning for the sight-impaired, among other things.  One could always let
the author decide *not* to include these things or allow some conversions,
and let the receiver override these at some communicative risk.

This would also be useful for multiple language representations, where the
'preferred' presentation would be in the author's native language, but some
translations might be available (provided by the author, added by services,
etc.) as alternates.  Things like hypertext anchors would be defined in each
version, but the link itself would be constant across all representations,
and would point to an action (program) to take or another segment to show.

So a sample (silly) message might be structured something like this:

	scenario
		list of link types:	replace
		list of media types:	formatted text, PSfigure
		list of controls:	button
	script 
		A. formatted text: ["Hello World"]
		B. PSfigure: [PostScript figure of hungry polar bear]
			text: "A hungry polar bear"
		C. formatted text: ["Goodbye World"]
		D. button: ["Meet your fate"]
		E. PSfigure replace A: [Postscript figure of fatter polar bear]
			text: "A somewhat fatter polar bear, licking chops"

Some conversions would be always available (e.g. formatted text to raw text,
buttons to keys or page flipping instructions).  The entire document would be
represented via an SGML DTD or something, with a compiler for each
supported platform to turn it into something comprehensible that could run/
be displayed on each.  For a fax machine, the formatted text and PSfigures
are rendered into a fax bitmap, at the bottom of the page is printed "turn the
page to meet your fate", and perhaps on the second page is the version with 
the fat/happy bear.  This would be the equivalent of the adventure flip books
that tell you to go to page N after you make a choice about doing something.
Of course, such an extraordinarily stupid terminal, with no mail receiver
to speak of, requires an intermediary to perform the translation.

However, this could also be compiled into a HyperCard for viewing on a Mac,
where the full interactive effect would be felt.

It could also be mailed to an ASCII terminal, where the text representations
would be printed as "PSfigure of a hungry polar bear" and "PSfigure of a 
somewhat fatter polar bear, licking chops".  The printed document would have
the rendered bear, of course... if a PostScript interpreter was available.

Users interested in news about bears could use automatic text searches to
find this article, even though the preferred representation says absolutely
nothing about bears...

A blind user's micro could read the entire text to him or her, mentioning
the pictures (reading the captions), and waiting for a key to be pushed before
explaining the last picture.  As a visual joke, it might not be too funny. :(
In this case the user's "preferences" would weigh more in the final 
representation than the capabilities of the terminal equipment.

There are many meaningful 'degradations' of media types one can think of:

	drawn figures to bitmap format files, including fax bitmaps
	video to series of still 'key' frames
	pictures and figures of all sorts to captions
	speech to text
	formatted text to raw text
	music to a score (traditional or MIDI, say)

At mail *creation* time, whatever models were used to create the item are
still around, so that is the time to include them...

Has anyone tried to build a system that would support a wide diversity of
terminals, users, and media types, down to the lowest common denominator
without compromising the richest level of representation ?  Remember that
all of this is invisible to the person who can read/view the 'piece' as it
was meant to be seen...

Since many systems leave so many interpreters/editors for different media
types in easy reach, defining a few environment variables to tell the system
where to find the PostScript interpreter or speech synthesizer isn't too bad...
I guess this is sort of a 'tools approach' to mail...

  Craig Hubley                     kid after Live Aid: "Is that it?"
  Craig Hubley & Associates        ---------------------------------
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
-- 
  Craig Hubley                     kid after Live Aid: "Is that it?"
  Craig Hubley & Associates        ---------------------------------
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig