Path: utzoo!attcan!uunet!husc6!rice!sun-spots-request
From: tale@pawl.rpi.edu
Newsgroups: comp.sys.sun
Subject: Re: Rasterfile Format questions
Message-ID: <8812220327.AA01996@pawlsub.rpi.edu>
Date: 3 Jan 89 20:22:45 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
Original-Date: Wed, 21 Dec 88 22:27:42 EST
X-Sun-Spots-Digest: Volume 7, Issue 85, message 10 of 14
X-Issue-Reference: v7n69

In Digest 7.69, mephdbo%prism@gatech.edu (d. majumder) wrote:
>1) There are some pub domain rasterfiles with their filename extension
>being ---.im1 or ---.im8. The file command indicates that these are in
>RT_BYTE_ENCODED format. now the screenload command fails to read them most
>of the time. Is there some routine to convert the BYTE_ENCODED rasters to
>STANDARD form or am I doing something wrong.

RT_BYTE_ENCODED (run-time byte encoded) is a format used when someone
wants to save space and still have the rasterfile readyily available.
This effectively rules out compression utilities, as various programmes
like suntools-e, touch-up, screenload et al can't do the decompression
themselves.  Suntools, suntools-e, screenload and screenloadc are all able
to handle RT_BYTE_ENCODING; images will appear as advertised.  I don't
know if touch-up can cope with it; I haven't checked and can't until I'm
near a sun.  I suspect it might not be able to since an option to save it
RT_BYTE_ENCODED does not exist in that programme.

>2)  Does anyone know if there exists any utility to convert the CompuServe
>GIF format to SUN rasterfile format (color/mono).

There is one in development here and I suspect that when it is completed
it will be announced in Sun-Spots and made available via anonymous ftp.
If one already exists out there, our developers would be happy to hear
about it.

Dave
-- 
      tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu