Re: Inlined image format (Alexsander Totic)
From: (Alexsander Totic)
Message-id: <>
Subject: Re: Inlined image format
To: (Marc Salomon)
Date: Tue, 25 Jan 1994 21:29:02 -0600 (CST)
Cc:, sanders@BSDI.COM
In-reply-to: < > 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:
> (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:  \\ 
> \\ 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 --
Software Development Group      National Center for Supercomputing Applications