HDTenEightyP/NetNews huggingface dataset:
From: tpehrson@javelin.sim.es.com (tim clinkenpeel)
Subject: anim --> gl/grasp/fli converter?
Reply-To: tpehrson@javelin.sim.es.com
Organization: Evans & Sutherland Computer Corporation
Date: Wed, 7 Oct 1992 22:58:57 GMT

i have some amiga iff anims that i'd like to convert to an ibm pc compatible
format.  it seems like grasp or fli is a good, widely accepted target.  is
there any utilities available out on anonnymous ftp to make the task quick and
painless?  is there an anim viewer for the pc?  or am i stuck with saving out
the frames as pictures, porting them to a format like PCX and assembling a
grasp from raw data?

please respond via e-mail.   i will share the results upon request.  thanks.

-- 
	       there is no religion when a man has  good curry
				       -
      tim clinkenpeel: aberrant analytical skeptical agnostic idealist.
		     -- i exclusively represent myself --
Newsgroups: alt.graphics.pixutils
From: lhclin@watcgl.uwaterloo.ca (Louis Lin)
Subject: Re: Dithering of Bitmaps
Organization: University of Waterloo
Date: Wed, 7 Oct 1992 13:05:35 GMT

In article <1992Oct6.233532.9553@megatek.com> megatek!tomw@uunet.uu.net writes:
>
>i don't have the exact citation, but there was a good article by knuth (sp?)
>in "transaction on graphics" roughly 3-4 years ago that started out with a
>nice overview on dithering gray scaled bitmaps. then it went on to describe
>good ways to output gray scaled images on laser printers (which are not
>continuous tone). the issue has a dithered mona lisa on the cover if you
>have open stacks at your library.
>
>regards,
>tom
>

The article is "Digital Halftones by Dot Diffusion", ACM Transaction of Graphics,
October 1987.  Foley, van Dam, et al also has a section on halftoning.

-- 
______________________________________  __       __
| email : lhclin@watcgl.uwaterloo.ca | /_/\__   / /_
| Louis Lin, Computer Graphics Lab,  | \ \/_/\ /___/\
| University of Waterloo, Canada.    |  \___\/ \___\/
From: kemp@uiatma.atmos.uiuc.edu (John Kemp)
Newsgroups: alt.graphics.pixutils
Subject: GIF colormap consistency
Date: 9 Oct 92 02:58:02 GMT
Organization: University of Illinois, Urbana-Champaign

We make a lot of GIFS using various methods.  The problem
is very few of the GIFS end up with the same colortable.

Is there a way either pre- or post-processing where we 
could recreate the GIFS but all using a single pixel/colormap
ordering scheme???

A pbmplus trick would be very helpful right about
now!  ;-)
JohnKemp@Uiuc.edu
Newsgroups: alt.graphics.pixutils
From: trw@spl1.spl.loral.com (Tim R Witort)
Subject: GIF on IBM PC?
Organization: Loral Software Productivity Laboratory
Date: Mon, 12 Oct 1992 20:05:29 GMT

Howdy,

  Does anyone know of an application (preferably shareware) that
displays a GIF image on an IBM PC without requiring any user
interaction? I need such a routine to display a startup screen
for an application I'm writing and I just want to display the
GIF then go ahead and run my application. I have a GIF viewer
for my PC, but it has a user interface that you have to use to
select the file to view - no option just to throw an image on 
the screen from the command line.

  Ay ideas? Please e-mail responses to trw@spl48.spl.loral.com

much thanks,

-- Tim Witort
Newsgroups: alt.graphics.pixutils
From: bobw@csg.uwaterloo.ca (Bob Wildfong)
Subject: WPG->WMF, CGM->WMF, WPG->BMP ?
Organization: Computer Systems Group, University of Waterloo
Date: Thu, 8 Oct 1992 20:58:39 GMT


I'm trying to find a way to convert Wordperfect WPG files to Windows
metafiles.  I can export the WPG from Drawperfect in CGM metafile format.
Any idea how to convert CGM to Windows WMF format?
Any better ideas?

I have a lot of pictures here (~200), so I'm really interested in something
that can do batch jobs.  I know CorelDraw could probably do the job, but is
there something else simpler (smaller) and preferably non-interactive?

I'd also be interested in any WPG -> BMP utilities, although that's less
of a problem.


Bob Wildfong                                       bobw@csg.uwaterloo.ca
Waterloo, Ontario                                  bobw@csg.waterloo.edu
#include <stddisclaimer.h>
From: hpchen@blackberry.Eng.Sun.COM (Huei-Ping Chen)
Newsgroups: alt.graphics.pixutils
Subject: why ".299 r + .587 g + .114 b" ??
Keywords: red green blue grayscale color
Date: 14 Oct 92 06:38:47 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: blackberry136

Hi, boys and girls out there,

I have just downloaded pbmplus tools, and am trying to understand it and use it.

there is a function ppmtopgm which converts color pictures to grayscale,
the man page says the quantization formula used is ".299 r + .587 g + .114 b".

my question is why this formular, is there any color theory behind it ??
can someone recommend me a paper or book that I can read to understand it.

any information would be greatly appreciated.

-- Ping
 
Newsgroups: alt.graphics.pixutils
From: sjn@sjn.kgn.ibm.com (sjn)
Subject: gif -> RGB tool?
Date: Sun, 11 Oct 92 17:20:04 GMT
Reply-To: sharad@vnet.ibm.com
Organization: IBM AWD Graphics Systems

Is there a utility out there which converts a gif format file
to a raw rgb format. The RGB values could be floating point numbers or
0-255 or Packed format (3 bytes - RGB)

Sharad Naik       IBM AWD Graphics Systems
sharad@vnet.ibm.com
Xref: sparky alt.graphics:377 comp.graphics:10511
From: hersbach@amc.uva.nl
Newsgroups: alt.graphics,comp.graphics,comp.windows.ms
Subject: targa16 driver for windows wanted
Date: 12 Oct 92 11:24:23 GMT
Organization: Central computer department

sorry Iam new on this newsnet, but i have a question about the targa 16 card
 from the year 1988. I need a targa driver for windows 3.1, my information 
from truevision in the netherlands was "don't know"
I have looked for the FAQ but i haven't found anthing
please answer by email to 
hersbach@amc.uva.nl
because i don't read this group freqenly thanks !
Newsgroups: alt.great.ass.paulina,alt.supermodels
From: earle@elroy.jpl.nasa.gov (Greg Earle - Gainfully Unemployed)
Subject: Paulina Poriskova on "Arsenio" tonight (Thursday, Oct. 15th)
Organization: Gainfully unemployed
Distribution: na
Date: Thu, 15 Oct 1992 22:15:04 GMT

If you live in the U.S. (and maybe southern Canada and/or northern Mexico),
Paulina will be on Arsenio Hall's show tonight (Thursday, Oct. 15th).

Happy viewing ...

BTW, "several hundred" people went to her Book Soup in-store signing.

Newsgroups: alt.privacy
From: tomrice@netcom.com (Tom R. Rice)
Subject: Re: packet radio encryption
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 13 Oct 1992 01:57:53 GMT

In spite of the regs, I'm willing to bet that there's a great deal
of purposeful encryption going on, with no persecution.  Remember
the commercial codes of cable telegraph days?  Bentley's was one
famous example.  You can't tell me that commercial interests have
stopped coding or enciphering their stuff just because some fed
type doesn't want them to, especially when so much of our comm
takes place via satellites and thus is interceptible over wide areas.

Pretty hard to claim "lack of intent" in such cases!

trr

-- 
"Start off every day with a smile and get it over with."  --W.C.Fields
Tom R. Rice   WB6BYH                   Holler Observatory - 
tomrice@netcom.com                     Longitude:  121 d  30 m  20 s W 
CIS: 71160,1122                        Latitude:    37 d  25 m  10 s N 
Newsgroups: alt.privacy
From: oxenreid@chaos.cs.umn.edu ()
Subject: Re: packet radio encryption
Organization: University of Minnesota
Date: Tue, 13 Oct 1992 22:30:50 GMT

In <1992Oct13.015753.12121@netcom.com> tomrice@netcom.com (Tom R. Rice) writes:
<stuff deleted>
>famous example.  You can't tell me that commercial interests have
>stopped coding or enciphering their stuff just because some fed

In the case of Amateur Radio, 
     \(sc 97.113 Prohibited transmissions.
     (d) No station shall transmit: music; radiocommunications or
messages for any purpose, or in connection with any activity,
that is contrary to federal, state, or local law; messages in
code or ciphers where the intent is to obscure the meaning
(except where specifically excepted elsewhere in this Part);
obscene, indecent, or profane words, language, or meaning; and/or
false or deceptive messages or signals.

However, Part **90** of the CFR which related to "Private Land Mobile Radio
Services".  

90.212 Provisions Relating to the use of scrambling devices and digital voice
modulation

(a) Analog scrambling techniques may be employed at any station authorized the 
use of A3E, F3E, or G3E emission, subject to the provision of paragraph (d)
of this section.

(d) Station identification shall be transmitted in the unscrambled analog 
mode (clear voice) or Morse Code in accordance wiht provisions of 90.425.
All digital encoding and digital modulation shall be disabled during station
identification.

My bet is that you can do just about anything on a cable you own, or lease.
How ever, since  Amateur Radio is a "public service" and scrambling would 
be _inconsistant with_ the nature of the service it is therefore prohibited.

I don't remember any part of the CFR prohibiting the use of codes or ciphers
so you and a friend coud put one on a phone and have a nice conversation, or
use radio on a 800Mhz Trunk system with a _Transcrypt_ (TM) 
modual in your HT.  

Nuff quoted.

From: kingsley@hpwrce.mayfield.hp.com (Kingsley Morse)
Date: Wed, 7 Oct 1992 23:46:15 GMT
Subject: Please Help
Organization: HP Western Response Center
Newsgroups: alt.privacy

              Please answer these 9 questions and return.

1.) Do you think equal rights for men and women is generally a good idea?
Yes                  [ ]
Sometimes            [ ]
No                   [ ]
Haven't heard enough [ ]
Other                [ ]

2.) Are you pro choice?
Yes                  [ ]
Sometimes            [ ]
No                   [ ]
Haven't heard enough [ ]
Other                [ ]

3.) Are you in favor of adoption?
Yes                  [ ]
Sometimes            [ ]
No                   [ ]
Haven't heard enough [ ]
Other                [ ]

4.) Do you think men should be allowed to legally terminate their parental
rights and responsibilities before fetal viability?
Yes                  [ ]
Sometimes            [ ]
No                   [ ]
Haven't heard enough [ ]
Other                [ ]

5.) What sex are you?
Male               [ ]
Female             [ ]

6.) How old are you?
Under 18           [ ]
19 to 65           [ ]
Over 65            [ ]

7.) What religion are you?
Protestant         [ ]
Catholic           [ ]
Jewish             [ ]
Other              [ ]

8.) What political party are you affiliated with?
Democratic         [ ]
Republican         [ ]
Other              [ ]

9.) How many years of education have you completed?
Grade School       [ ]
High School        [ ]
College            [ ]
More               [ ]
From: grady@public.BTR.COM ( )
Newsgroups: alt.privacy
Subject: Re: evading phone taps
Date: 7 Oct 92 01:54:42 GMT
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM

Mr. Romano asks:

"Why does posting an RSA key preclude the FBI, NSA, etc.
from discovering the contents of communications?"


We don't know for sure, since the NSA doesn't give
press releases, but to "break" RSA is thought to
be equivalent to knowing how to efficiently factor
extremely large numbers.

Since the world's most brilliant mathematicians
have tried to figure out a way to doing so for
several hundred years, we have pretty good
anecdotal evidence that is is indeed secure.
After all, the NSA must follow physical law as
much as anyone must -- so regardless of what they
would like for you to believe, they have their
limits.

The DES (Data Encryption Standard) on the other hand
was designed by IBM with modifications from the NSA
whose criteria is still classified.

Given the above facts, independently discovered RSA
seems to be a better choice for true privacy.

Grady

-- 
Grady Ward  grady@btr.com  Moby Lexicons
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: alt.privacy
Subject: Re: evading phone taps
Date: 12 Oct 92 21:07:47 GMT
Reply-To: 70465.203@compuserve.com
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

grady@public.BTR.COM ( ) writes:

>Dave Feustel N9MYI <feustel@netcom.com>   writes, in part:

>"Transmission of encrypted material on amateur bands is against FCC
>regulations. ..."

>--------


>(1)  The burden of proof is on the FCC to show that it is encrypted,
>not compressed, just data with low entropy, or random noise.
>Unlike the AX.25 link protocol specified by FCC rules, the higher
>level protocols are not required to be plain-text;

No, but you are *required* to have filed any encryption used with the
FCC unless it is something common enough that you can just say "I'm
using XYZ code".

By *definition* if they can't read it, they have the right to *demand*
the plaintext. And if you can't supply it, you are in violation. If you
can't provide not just an explantion, but actual output, they can at the
very least nail you for improperly operating the equipment. That takes
care of the "it's on the fritz" argument. And you are going to be hard
pressed to justify any of the "legitimate" explanations you offered.


-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
From: grady@public.BTR.COM ( )
Newsgroups: alt.privacy
Subject: Re: evading phone taps
Date: 7 Oct 92 02:56:06 GMT
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM

David Feustel correctly points out that it is
illegal to transmit codes intended to obscure
the meaning of the communication within the
amateur frequencies (exception made for certain
remotely controlled equipment).

However two points make this fact moot:

(1) Well encrpyted data is theoretically
indistinguishable from _random_ data.
The burden of proof is upon the FBI to show that
the data stream _was_ encrypted rather than
just a TNC on the fritz, a highly-compressed file,
a pseudo-random stream, etc.

(2) That would probably be the _least_ of the crimes
that the packet radio user would be charged with if
caught using the radio to commit espionage, fraud,
criminal consiracy, etc.

73 de KD6ETH/AA Grady

-- 
Grady Ward  grady@btr.com  Moby Lexicons
Newsgroups: alt.privacy
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: evading phone taps
Organization: AT&T Bell LaBORatories, Hunchbacks Division
Date: Sun, 11 Oct 1992 05:23:11 GMT
	<8086@public.BTR.COM> <1992Oct7.234627.24073@netcom.com>
	<8098@public.BTR.COM>

In article <8098@public.BTR.COM> grady@public.BTR.COM ( ) writes:
   (1)  The burden of proof is on the FCC to show that it is encrypted,
   not compressed, just data with low entropy, or random noise.
Peter Wayner's mimic functions can be useful here, if your objective
is to avoid being noticed ....

   Unlike the AX.25 link protocol specified by FCC rules, the higher
   level protocols are not required to be plain-text;
Do you have a reference for this?  And does this apply to the contents,
the protocols, or both?  (E.g. can you use a crypto-based presentation
layer protocol and plain-text payload, or vice versa?)
--
				Pray for peace;      Bill
#Bill Stewart 908-949-0705 wcs@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Trickle-Down Economics: Giving money to government bureaucrats 
#	and hoping some will trickle down to the people who need help.
Newsgroups: alt.privacy
From: oppedahl@panix.com (Carl Oppedahl)
Subject: Re: evading phone taps
Date: Wed, 7 Oct 1992 07:32:22 GMT
Organization: PANIX Public Access Unix, NYC

In <1992Oct6.234442.26181@netcom.com> feustel@netcom.com (David Feustel) writes:

>It is illegal to transmit encrypted data on amateur frequencies.

He's right about that.  It is indeed illegal.  
Carl Oppedahl AA2KW
From: grady@public.BTR.COM ( )
Newsgroups: alt.privacy
Subject: Re: evading phone taps
Date: 8 Oct 92 13:07:15 GMT
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM

Dave Feustel N9MYI <feustel@netcom.com>   writes, in part:

"Transmission of encrypted material on amateur bands is against FCC
regulations. ..."

--------


(1)  The burden of proof is on the FCC to show that it is encrypted,
not compressed, just data with low entropy, or random noise.
Unlike the AX.25 link protocol specified by FCC rules, the higher
level protocols are not required to be plain-text;

(2) Breaking the rules of Part 15 for a person engaged in espionage,
criminal conspiracy, or fraud is the least of their concerns;

(3) I am unaware of any criminal prosecutions for illegal transmitting
based upon satellite evidence rather than evidence gathered by the FCCs
"little white van".

Grady Ward KD6ETH/AA

-- 
Grady Ward  grady@btr.com  Moby Lexicons
From: kingsley@hpwrce.mayfield.hp.com (Kingsley Morse)
Date: Fri, 9 Oct 1992 15:40:54 GMT
Subject: Re: Please Help
Organization: HP Western Response Center
Newsgroups: alt.privacy

Oops! My apologies for posting my previous "Please Help" survey to this
group. It was an honest mistake and won't happen again.

Kingsley
From: grady@public.BTR.COM ( )
Newsgroups: alt.privacy
Subject: packet radio encryption
Date: 11 Oct 92 19:41:12 GMT
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM

Bill Stewart (wcs@anchor.ho.att.com) writes, in part:
         
   [...Unlike the AX.25 link protocol specified by FCC rules, the higher
   level protocols are not required to be plain-text...]

Do you have a reference for this?  And does this apply to the contents,
the protocols, or both?  (E.g. can you use a crypto-based presentation
layer protocol and plain-text payload, or vice versa?)

----

The definitive reference is Part 97 of the FCC rules
(available from the US Government Printing Office,
Washington, D.C.  20402.  Phone orders: 202 783 3238.
Ask for "Code of Federal Regulations" 47 CFR 80 to End.)

To summarize the rules, except for certain remote control
operation as space or repeater machines, nothing can be 
transmitted with the intent that the meaning be obscured.

Conversely, text compression, for example, is legal because,
although the plaintext is certainly obscured, it wasn't the _intent_
of the LZ or Huffman or whatever coding to conceal the
meaning.

Likewise with UUencoding and a host of other compression/
error detection and correction schemes that incidentally
involutes the plaintext to some more efficient transmitted form.

Spread spectrum is treated somewhat more restrictively
since for that mode you may be required to produced the
logs and the content of the messages.  But not so for narrow-
band FM packet.

To sum up, using cryptography in general is prohibited.
(However, digital signatures are OK, even though based
on MD5 or SHA as long as the intent is not to _obscure the
meaning_ of part of the transmitted message.)

Clearly, though, the burden of proof is upon the FCC to show
that a particular message _was_ encrypted, since there
is _no_ theoretical, a priori way that an encrypted data
stream can be distinguished from one merely well compressed
or, just for that matter, random.

Of course you should verify this with an attorney if you are
troubled with fears of prosecution.

Grady Ward    KD6ETH/AA

-- 
Grady Ward  grady@btr.com  Moby Lexicons
Newsgroups: alt.privacy
From: feustel@netcom.com (David Feustel)
Subject: Re: evading phone taps
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Wed, 7 Oct 1992 23:46:27 GMT

Transmission of encrypted material on amateur bands is against FCC
regulations. Nothing would bring them down on you faster than such a
signal which could probably be picked up rather easily by low level
satellites. The latest FCC fines against errant amateurs I've read
about have been in the $8000-$10000 range
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
[.sig on vacation]
From: olson@dstl86.gsfc.nasa.gov (Paul Olson)
Newsgroups: alt.privacy
Subject: Re: Please Help
Date: 10 Oct 92 00:52:00 GMT
Organization: Mission Operations and Data Systems
News-Software: VAX/VMS VNEWS 1.41

In article <20970001@hpwrce.mayfield.hp.com>, kingsley@hpwrce.mayfield.hp.com (Kingsley Morse) writes...
> 
>              Please answer these 9 questions and return.
> 
>1.) Do you think equal rights for men and women is generally a good idea?
>2.) Are you pro choice?
>3.) Are you in favor of adoption?
>4.) Do you think men should be allowed to legally terminate their parental
>    rights and responsibilities before fetal viability?
>5.) What sex are you?
>6.) How old are you?
>7.) What religion are you?
>8.) What political party are you affiliated with?
>9.) How many years of education have you completed?

Gee, alt.privacy is an awfully strange place to try to build a database with
Internet mailing addresses this kind of information.  I think anyone who
seriously answers these questions really shouldn't be wasting their time in
alt.privacy and deserves any harrasment they receive from religious pro-life
groups they get.

Ever wonder why they put screens around voting booths?

Just my opinion.  Sorry, I know my answer isn't in the list.

+--------+-------------------------------------------------------------+
|      __| Paul J. Olson - VAX Systems Manager & Resident Amiga Addict |
| C=  ///| Voice -     301/286-4246, 301725-5501                       |
|__  /// | DECnet-    DSTL86::OLSON                                    |
|\\\///  | Internet - olson@dstl86.gsfc.nasa.gov                       |
| \XX/   | Disclaimer: Statements in my messages are wholely my own.   |
| AMIGA  | "[the universe originated] as a quantum fluctuation         |
| RULES! |  of absolutely nothing." - Guth & Steinhardt                |    
+--------+-------------------------------------------------------------+
From: PANDERSON@OAVAX.CSUCHICO.EDU (Peter Anderson)
Newsgroups: alt.privacy
Subject: Re: Please Help
Date: 13 Oct 92 16:52:45 GMT
Organization: Cal State Univ Chico
NNTP-Posting-Host: mlib13-mac13.csuchico.edu

I think persons asking others to respond to a survey should tell who the 
information is for and how it's going to be used.


panderson@oavax.csuchico.edu(PeterAnderson)