Re: Inlined image format
Marc Salomon <marc@library.ucsf.edu>
Date: Tue, 25 Jan 1994 15:19:37 -0800
From: Marc Salomon <marc@library.ucsf.edu>
Message-id: <199401252319.AA04153@library.ucsf.edu >
To: www-talk@www0.cern.ch, sanders@BSDI.COM
Subject: Re: Inlined image format
Content-Length: 2461
Tony Sanders <sanders@BSDI.COM> writes:
>... lots of correct stuff deleted ...
>
> If you want to do inlined everything then work on the HTML+ project.
> Inlined everything is a *BIG* project and deserves much more thought than
> we have given it here and if we are going to do it then we need to do it
> right. You can't expect to just say "hey! let's add 100,000 lines of
> code to every browser" and have people start jumping up and down to do it.
>
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 \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\