Re: Inlined image format
atotic@ncsa.uiuc.edu (Alexsander Totic)
From: atotic@ncsa.uiuc.edu (Alexsander Totic)
Message-id: <9401260329.AA13402@void.ncsa.uiuc.edu>
Subject: Re: Inlined image format
To: marc@library.ucsf.edu (Marc Salomon)
Date: Tue, 25 Jan 1994 21:29:02 -0600 (CST)
Cc: www-talk@www0.cern.ch, sanders@BSDI.COM
In-reply-to: <199401252319.AA04153@library.ucsf.edu > from "Marc Salomon" at Jan 25, 94 03:19:37 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2727
>
>
> 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 \\
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>
--
Aleksandar Totic -- lead MacMosaic programmer -- atotic@ncsa.uiuc.edu
Software Development Group National Center for Supercomputing Applications