Re: Xmosaic and Xv

Christopher J. McRae (Christopher.McRae@library.ucsf.edu)
Sat, 26 Jun 93 13:09:14 MDT

Marc Andreessen writes:
|
| ebina@ncsa.uiuc.edu writes:
| > Right now mosaic defaults to using xv as the viewer for many different
| > image types. I don't see why it is necessary to have it take the id
| > of another window when it can just use its own.
|
| I think Chris is referring to the idea someone had a while back on
| www-talk that xv could theoretically be used to view inlined images in
| much the same way as ghostview uses ghostscript (by controlling an X
| window ID) -- however, nope, we haven't touched it and I doubt we
| will. Among other things, we need to be able to have the internal
| image mechanisms we now have anyway (for HDF support) and that we need
| things like the image-as-anchor and image-as-anchor-and-map support.
|
| Cheers,
| Marc
|

Eric,
The justification for using xv to display inlined images is listed right
in your reply: xv displays *many* different image types. We are using
mosaic to display a database of medical journals we have; however, since
the page images are in TIFF format, I have to convert to GIF them all to
GIF.
One of the things we're interested in is services which dynamically
generate an HTML representation of the results of some search or filtering
process. There is no way of knowing, apriori, what document formats we
might encounter and we would like a client with general image display
capabilities. Xv fills this role nicely.
Further, we envision offloading as much of the processing from the client
as possible. Rather than including local format conversion capability within
the client, we expect to provide a "community of servers" with which the
client can contract to obtain the information it wants, and in a form which
it can use. By providing a particular server (such as xv) with a window id,
the client retains control of the presentation of the information while
avoiding having to know anything about the format of the data being displayed.

Marc,
Suppose someone (such as ourselves) were able to integrate tooltalk
functionality into mosaic, *and* could provide an HDF- and tooltalk-capable
version of xv (or some such image manipulation package). Would the technology
fit into your development strategy for mosaic?

Chris
--------------------------------------------------------------------------------
Christopher McRae mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management at&t: 415/476-3577
530 Parnassus Avenue, Box 0840 fax: 415/476-4653
San Francisco, California 94143