HDTenEightyP/NetNews huggingface dataset:
From: royd@ERE.UMontreal.CA (Roy Daniel)
Newsgroups: alt.satanism
Subject: Re: satan-ouiga_board
Date: 22 Jan 93 00:39:49 GMT
Organization: Universite de Montreal


Hey! What's happening, since last I left?

The I.Q. rating of the posters has dropped a few points, or is it that everybody
is turning 16? 

(Maybe a trick from the Angels; gosh, are they a pest...)  :)
-- 
Daniel Roy, of the "Voyageurs sans Permis"			CARPE DIEM!!

"A man's science is another man's magic; 
 for all I know, Merlin was a physicist."
Newsgroups: alt.satanism
From: drake+@cs.cmu.edu (Drake)
Subject: Re: What is a Christian?
Organization: School of Computer Science, Carnegie Mellon
Date: Mon, 25 Jan 1993 02:48:51 GMT

scoons@news.weeg.uiowa.edu (SM Coons) writes:

>Howdy all!  I am doing a bit of research for a college group I am in and 
>would like anyone and everyone to answer a few questions for me.

I wonder why you asked these questions here.  Perhaps getting, for once,
the opposing viewpoint? ;)

>1.  What is the defintion of a Christian?

Basic Protestant definition: One who has made a decision to make Jesus
Christ their personal lord and saviour.  There is debate over whether
certain groups are Christian or not (ie, Jehovah's Witnesses, LDS (Mormon),
Catholic, Unitarian, Christian Science, etc) among many Christian groups.

For my purposes, I don't give a fig about doctrinal disputes and which
church is really "Christian" and which aren't.  I think that if you actually
want to call yourself a Christian, then hey, I'll consider you a Christian.

>2.  What are some things that people do that makes one not a Christian?

My own view, again, saying that you aren't makes you not one.

>I think e-mail would be easiest for gathering responses, but if you must post
>go right ahead.

I must. ;)
-- 
Love and Laughter,             | NOTE: Private mail must go explicitly
Xeper and Remanifest,          | to drake@seismo.soar.cs.cmu.edu
                       DRAKE   | or it'll bounce back to you...
Newsgroups: alt.satanism
From: ashton@netcom.com (ashton)
Subject: Re: liberation
Reply-To: ashton@netcom.com
Organization: Dept of Medieval Metaphysics, Miskatonic U, Arkham, Mass
Date: Sat, 23 Jan 1993 07:54:05 GMT

NaChaSh@f74.n396.z1.fidonet.org (NaChaSh) writes:

>We have a large Chaos magick file area here at the Black Eidolon of 
>Yog-Sothoth.

Do Tell?
List / phone number / uploads to ftp sites ?
MORE! AShTON.
Newsgroups: alt.galactic-guide
From: il67@vaxb.acs.unt.edu
Subject: Re: Getting AmiGuide to work.
Organization: University of North Texas
Date: Wed, 27 Jan 1993 21:50:04 GMT

In reply to your problem with AmiGuide (sorry it took me a while to reply),
it should be creating a temporary file in RAM called Index1, and not
"Index 1".  I'm not real sure what could be causeing this.  I do know the
reason for the all too many disk swaps, which could only be corrected if
you put AmiGuide on a stripped down workbench disk..

Actually, I have done some more work on it, and plan to release a new
version pretty soon.  (2.0)  AmiGuide (as criticized) is currently very
slow.  The next version (AFTER 2.0) will almost definately be written in
C.  I have looked into using the AmigaGuide standard for storing the files,
(3.0) but I was not certain as to what and how the AmigaGuide standard
handled such big databases.  It would defeat the point of using the Amiga
Guide standard if it couldn't properly X-reference articles.  And I know
Hyper takes up a lot of memory (I assume because of the size of the file)
but I'll look into it.  If any Amiga programmers are out there, and think
they can beat me to a C version of an Amiga Guide reader - go for it.  I
have no idea when it will be complete (I am also co-writing a BBS, so a
lot of my time is being eaten up.)

Good luck, (expect a new version of AmiGuide up within 7 days or so,)
James Palmer
  








Newsgroups: alt.galactic-guide
From: cleggp@aix.rpi.edu (Paul Jason Clegg)
Subject: Re: MACINTOSH guide? any?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Fri, 22 Jan 1993 00:10:33 GMT

In article <1993Jan21.172314.10076@iscsvax.uni.edu> rezabek1037@iscsvax.uni.edu (Will be President for Food) writes:
>before i start writing up ENTRIES or somesuch, i want to know... are there any
>MAC browsers or platforms yet whipped up?
>
>.rez

Not to my knowledge (which is pretty vast on this subject...  :)

...Paul


-- 
+                +        +    +  + + +  +    +        +                +
      Paul Clegg, cleggp@rpi.edu.   Send me your Guide Articles! 
         System One RPG designer.   Project Galactic Guide Coordinator.
+                +        +    +  + + +  +    +        +                +
From: andreas@atlas.physchem.chemie.uni-tuebingen.de (Andreas Haug)
Newsgroups: alt.galactic-guide
Subject: Re: Graphic format
Date: 27 Jan 1993 15:08:58 GMT
Organization: IPTC, University of Tuebingen, Germany
NNTP-Posting-Host: atlas.physchem.chemie.uni-tuebingen.de

pcxkrm@unicorn.nott.ac.uk (K.R.Marshall) writes:
>To be honest - I'm going to have _real_ problems dealing with any form
>of bit-mapped colour graphics on the Atari, as people will want to use
>the higher resolutions for reading, and these only provide 4 or 2
>colours! Even the lowest res allows only 16 colours on-screen, and I
>really don't want to get into complicated dithering techniques, so I
>think everyone should be aware that a graphics standard might limit
>the systems for which the guide is workable. (Mind you, if it's only
>the Atari that's the problem everyone might just turn around and say
>"so what?" - but I don't think this is a healthy attitude!)

Well, the problem exists for many other systems, too. Just think of those
wo are commited to ASCII-Terminals. However, I think we should not limit
out views to what is available to anyone right now. If we did, the concept
of a "network guide" would be obsolete, too. I've been an Atari user for
years (since 4 years ago), too. But belive me: in a few years' time, no
one will have problems displaying 256 colors (or shades of grey).

The real question - imho - is how to integrate the pictures into the
Guide without rendering it impossible for some people to use. I would
suggest some kind of "reference" which goes into the article. The
pictures could be requested/loaded on demand only. 

>Some kind of vector graphic system might be better - but this wouldn't
>allow any nice scanned images etc.

...and would need a great deal more work to implement than pixel-images.

andreas.

--
------------------------------ahaug@mailserv.zdv.uni-tuebingen.de
"It's not too late to start again; days go by and seasons change;
 nothing stays the same; life's an endless game; between strangers."
From: nerone@ccwf.cc.utexas.edu (Michael Nerone)
Newsgroups: alt.galactic-guide
Subject: Re: Getting AmiGuide to work?
Date: 27 Jan 93 06:27:19
Organization: The University of Texas at Austin
	<1k37ltINNdtu@emmental.csv.warwick.ac.uk>
	<1993Jan27.104000.3472@cs.nott.ac.uk>
NNTP-Posting-Host: sylvester.cc.utexas.edu
In-reply-to: dpg@cs.nott.ac.uk's message of 27 Jan 93 10:40:00 GMT


What needs to be kept in mind here is the fact that JPEG provides
VARIABLE compression.  If you choose BIGTIME compression, then you
will get very small, albeit very lossy files.  JPEG IS capable of
lossless compression, though, although in my experience, they only
come out 10-15% smaller than the corresponding GIF (although you DO
have it in 24 bits with JPEG).  Clearly, the right answer is allow
slight (negligible) loss with better compression.  Shoot for maybe
only 40% compression.  That should not have an alarming impact on the
image quality.  Of course, this can be tailored to the image.  Eg. in
an extreme case of a simple geometric shape, 90% can be achieved with
no noticable loss.

--
   /~~~~~~~~~~~~~~~~~~~\/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
  /    Michael Nerone   \"I shall do so with my customary lack of tact; and\
 /   Internet Address:   \since you have asked for this, you will be obliged\
/nerone@ccwf.cc.utexas.edu\to pardon it."-Sagredo, fictional char of Galileo.\
Newsgroups: alt.galactic-guide
From: cleggp@aix.rpi.edu (Paul Jason Clegg)
Subject: Re: ISO Code, bold, italic ....
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Sat, 23 Jan 1993 17:00:03 GMT

In article <1joqhjINNk7e@nz12.rz.uni-karlsruhe.de> "tobias b koehler" <UKJP@DKAUNI2.BITNET> writes:
>If we use Warren's system, these three characters can be desribed
>as \c"o\c, \c/o\c and \coe\c; that would allow to distinguish between
>them.
>The only reason that I would see for NOT using an 8-bit character
>set is that the 8th bit is stripped when sending an article by e-mail.
>In the IBM character set 437 (used by most MS-DOS systems) there is
>only the "o with two dots". The "o with slash" can be converted into
>this one, the "oe ligature" would then be converted into "oe".

>Right. So we just have to decide if we want to have (a) an 8-bit input
>format, or (b) 7-bit format with combinations described as above.

I've been thinking about this idea, while reading your message.  And, since
I wouldn't have to do any programming, I think it might be an okay idea to
perhaps sit down and start some concentrated work on the 7-bit representations
of character conversion codes.

The ONLY problem I can forsee though, is line length problems (I know, not a
big one, but you have to think); after all, if you plan the line to be
76 characters long WITH the special characters in it, but then you have to
change the special characters to to a 5 or 6 character string, you're going 
to dump over the 80 column width (not to mention the preferred 76 character
length).  Like I said, not a big deal, but a small one to think about.  If
a line is longer than the screen, and gets sent via e-mail, what happens
to it?  Does it get chopped, or does it come out okay?  When you save the
message from the mail, is there an extra cr/lf combo inserted to make the
lines okay with 80 columns?

It sounds hokey, but I usually end up using DOS 5.0's Edit program to edit
the articles I edit, because it's a half-decent text editor, though it doesn't
have line wrap.  I know, however, that I can deal with longer lines than
80 chars very easily, no problem.  But what about other people?

...Paul

PS>  Just talked to Steve, and our WORKING.NEW file is up to about 11, and
should have 14 Real Soon Now (RSN), and possibly 20 within a week (if he gets
his confirmations back...)


-- 
+                +        +    +  + + +  +    +        +                +
      Paul Clegg, cleggp@rpi.edu.   Send me your Guide Articles! 
         System One RPG designer.   Project Galactic Guide Coordinator.
+                +        +    +  + + +  +    +        +                +
From: andreas@atlas.physchem.chemie.uni-tuebingen.de (Andreas Haug)
Newsgroups: alt.galactic-guide
Subject: Re: Graphics for PGG (was Re: Getting AmiGuide to work?)
Date: 27 Jan 1993 15:21:50 GMT
Organization: IPTC, University of Tuebingen, Germany
NNTP-Posting-Host: atlas.physchem.chemie.uni-tuebingen.de

cleggp@aix.rpi.edu (Paul Jason Clegg) writes:
>I looked at JPEG compression at one point, when my local BBSs at home thought
>it was a cool idea.  The only problem with it is that you lose resolution, and
>the more space you save, the more resolution you lose.
>I don't want to throw away the idea of compression; space is at a premium for
>everyone, BUT.  But, I think quality is more important than that.  If you want
>to limit filesize of the graphic images, I think placing a resolution and pic-
>ture size limit is a better idea.  Perhaps limiting the resolution to 320x200
>x256, perhaps GIF format.

It really depends on the image, imho. For some images, GIF may be better
whereas JPEG gives more "quality per kilobyte" for others. Please remember
that the JPEG system uses some kind of "quality" parameter which is widely
adjustable. It could be a _local_ policy (local guide server) to have
the pictures "reduced". 

Nevertheless, we have to editors to decide what is usefull and what not :-)

  And, since we're going to need a specific front-
>end program to display the graphics anyway, perhaps we should do something a
>little non-standard, perhaps use Bitmaps compressed with, perhaps, ZIP comp=
>ression...

please! Just say no! There are several packages available - in source - to
decode gif/jpeg/whatever. If we use our own coding, we have to do it all out-
selves. I think we could use GIF _and_ JPEG. One of those is suitable for
almost any picture.

andreas.

--
------------------------------ahaug@mailserv.zdv.uni-tuebingen.de
"It's not too late to start again; days go by and seasons change;
 nothing stays the same; life's an endless game; between strangers."
Newsgroups: alt.galactic-guide
From: dpg@cs.nott.ac.uk (Dave `geek' Gymer)
Subject: Re: TUG! 2 --> (The Net Guide)
Keywords: TUG admin network gopher irc tcp-ip
Organization: Nottingham University
Date: Tue, 26 Jan 93 12:28:19 GMT

In article <gavin.727924747@sorokin> gavin@sorokin.anu.edu.au (Gavin Longmuir) writes:
>But should there be a 'root' node?
>TNG shouldn't be tied down to any one node or group of admin.

Well, it is at the moment, and nobody seems to object.

Anyhow, my scheme still works without a root node; it then behaves
much like USENET news, with new and changed articles filtering thru
the system.

-- Dave
-- 
`Grave' Dave Gymer, 42 St Mary's Park, Louth, Lincolnshire, LN11 0EF, England
 dpg@cs.nott.ac.uk  (but I'm not always in, and I have no answering machine)
These opinions are mine. I doubt that they have ever belonged to anyone else,
but if you think you might have lost them, please get in touch. With a shrink.
Newsgroups: alt.galactic-guide
From: cleggp@aix.rpi.edu (Paul Jason Clegg)
Subject: Robert Schone, where are you?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Thu, 21 Jan 1993 23:08:38 GMT

Robert Schone, I've edited the article you sent me, on the board game
Diplomacy, but the mail I sent you to confirm the article was returned
as being "user unknown".  Please get in touch with me soon so I can
get your article added to the archives...

...Paul


-- 
+                +        +    +  + + +  +    +        +                +
      Paul Clegg, cleggp@rpi.edu.   Send me your Guide Articles! 
         System One RPG designer.   Project Galactic Guide Coordinator.
+                +        +    +  + + +  +    +        +                +
Newsgroups: alt.galactic-guide
From: y88kenek@odalix.ida.liu.se (Kenneth Ekman)
Subject: Re: Graphics for PGG (was Re: Getting AmiGuide to work?)
Organization: CIS Dept, Univ of Linkoping, Sweden
Date: Thu, 28 Jan 1993 19:13:41 GMT

dpg@cs.nott.ac.uk (Dave `geek' Gymer) writes:

>In article <kzp30am@rpi.edu> cleggp@aix.rpi.edu (Paul Jason Clegg) writes:
>>I looked at JPEG compression at one point, when my local BBSs at home thought
>>it was a cool idea.  The only problem with it is that you lose resolution, and
>>the more space you save, the more resolution you lose.

>Well, yeah, but the `loss' is designed to be invisible to the human
>eye.

>The real problem with JPEGs, as pointed out by another poster, is the
>time it takes to decompress and display them.

>Perhaps compressed portable bitmaps or GIFs are the way to go after
>all.

In my mind, there are two separate cases that should be handled.

1: If one would like small pictures in the document, these would
  have to be uncompressed bitmaps, since waiting for a single
  page to show is unacceptable. These would be contained within
  the document for maximum speed in my view.

2: Larger pictures with more colors would be better off in
  an external picture file, and handled by an external 
  viewing program. For example one could have a system
  variable called GIF_VIWER and another called JPEG_VIEWER
  containing the path for the preferred viewing program
  on each system. Then it's up to each user to set these
  to their program of choice.


This has several advantages.

- Since no graphics compression standard is completely 
  flawless each picture could use the optimum standard.

- You can always use the fastest decompression program
  for the standard.

- The documents won't grow so large.

- Only bitmaps will have to be decoded by the guide-
  program itself.

- If new and better compression standards evolve, 
  we won't be in a corner.

So, there. Now I got that off my mind...


>-- Dave
>-- 
>`Grave' Dave Gymer, 42 St Mary's Park, Louth, Lincolnshire, LN11 0EF, England
> dpg@cs.nott.ac.uk  (but I'm not always in, and I have no answering machine)
>These opinions are mine. I doubt that they have ever belonged to anyone else,
>but if you think you might have lost them, please get in touch. With a shrink.

Just my $0.02 worth...

  ___/ Kenneth
Newsgroups: alt.galactic-guide
From: pcxkrm@unicorn.nott.ac.uk (K.R.Marshall)
Subject: Re: Getting AmiGuide to work?
Organization: Cripps Computing Centre, University of Nottingham
Date: Mon, 25 Jan 93 16:55:52 GMT

In article <11440@baird.cs.strath.ac.uk> aforrest@cs.strath.ac.uk (Andrew R Forrest CS92) writes:
>So as not to waste bandwidth, here is a suggestion I also wish to post: The problem
>of line lengths when the lines contain control characters has been discussed. May I
>suggest that reader programs only recognise paragraphs and re-wrap the words
>depending on font-size, etc. This would allow proportional fonts, as many
>control-characters as you could wish for, graphics inserted in text... Also, some
>form of Hypertext linking would be nice. It might be good to define control-character
>"brackets" to put round text which would be a link to another article. (All we need
>now is a conversion program to translate Guide articles to Amigaguide documents...).
>Might I also suggest a graphics standard to be adopted. Just a thought. (Obviously,
>being an Amiga-user, I would suggest IFF |-)
>


I tried doing this for my version (the Atari guide), but most of the
articles are formatted to some extent to use 80 column text, and they
don't look right if you try to ignore the ends-of-lines. If we were
going to do this we would need much stricter rules on text formatting,
especially for lists.

As for a graphics format, I guess GIF is slightly more appropriate,
but I'm really not looking forward to dealing with them! - maybe we
should just forget about graphics for the moment. (Not that I don't
want to have to deal with them or anything!)

Keith.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Mummy was an asteroid, Daddy was             | Keith Marshall
a small, non-stick kitchen utensil..."        | pcxkrm@unicorn.nott.ac.uk
From: phudl@csv.warwick.ac.uk (Mr S J Liddicott)
Newsgroups: alt.galactic-guide
Subject: Re: Graphic format
Date: 26 Jan 1993 15:22:11 -0000
Organization: Computing Services, University of Warwick, UK
NNTP-Posting-Host: emmental.csv.warwick.ac.uk

In article <1993Jan26.132748.7630@cs.nott.ac.uk> pcxkrm@unicorn.nott.ac.uk (K.R.Marshall) writes:
 >To be honest - I'm going to have _real_ problems dealing with any form
 >of bit-mapped colour graphics on the Atari, as people will want to use
 >the higher resolutions for reading, and these only provide 4 or 2
 >colours! Even the lowest res allows only 16 colours on-screen, and I
 >really don't want to get into complicated dithering techniques, so I
 >think everyone should be aware that a graphics standard might limit
 >the systems for which the guide is workable. (Mind you, if it's only
 >the Atari that's the problem everyone might just turn around and say
 >"so what?" - but I don't think this is a healthy attitude!)
 >
 >Some kind of vector graphic system might be better - but this wouldn't
 >allow any nice scanned images etc.

Well howabout different versions. I.E. a colour JPEG and a black & white
GIFF, and your guide will request the correct one.


-- 
*----------*-------------------------------------------------------------*
| Sam   Jam|"Never underestimate the importance of a cheap laugh"-       |
| Liddicott| phudl@csv.warwick.ac.uk                     Plucky Duck TTA |
*------------------------------------------------------------------------*
From: S_KOEHLER@iravcl.ira.uka.de (|S| Tobias Koehler)
Newsgroups: alt.galactic-guide
Subject: ISO Code, bold, italic ....
Date: 21 Jan 1993 13:13:55 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

In <1993Jan19.162234.4195@cs.nott.ac.uk> pcxkrm@unicorn.nott.ac.uk writes:

> In article <1jgip4INNqq1@nz12.rz.uni-karlsruhe.de> UKJP@DKAUNI2.BITNET (tobias b koehler) writes:

> >In my opinion 7 bit is NOT enough, as the aforementioned examples show.

> OK - we have the problem here that most micros will only deal with a 256
> piece character set - any standard above this will create huge problems in 
> translation - it's not only UNIX systems we're talking about here! The fonts
> I deal with quite often don't have the whole standard 256, let alone any more!

Yes, but all of today's micros should handle a 256 charset like ISO 8859/1. If
the computer has a different character set (IBM PCs and clones use the codepage
437 in DOS and the codepage 850 in OS/2 and still another character set in
Windows, while the Amiga does use the ISO charset), the articles must be con-
verted by the reader programs. If someone really writes a reader for a 7-bit
machine, these characters must be converted into ae, ue or whatever.
(Does anybody know if there is a standard characterset for UNIX systems?)

I think that in the future the reader program should do the line breaking.
Not all of today's systems have 80 column screens. If a reader is used on
OS/2, Xwindows or Windows, the user should be able to decide freely how wide
he wants his window to be, and the reader program should break the lines so
that the article fits into the window. (Is this feature going to be included
into TGW?)
 
> I still think that we should have a simple system for bold and italic, in the
> same way we do underlining. This could be a "toggle" character, as with the
> underline, or a slightly more complex internal command system, perhaps
> starting with "\", as this seems to be a fairly standard control
> character (TeX, C etc.)

Until now we only had _underlining_. And I don't know if any Guide reader took
care of this. Taking a single character as toggle character is a good idea.
If we take \, it can be interpreted together with the next letter as a toggle
signal. For example \bHoopy\b would give you the word Hoopy in bold print.
\b switches to bold, and back to nonbold again. Similarly we can use \i for
italic, \u for underlining, \e for superscript, \s for subscript. If one wants
to have a backslash in the text, it can be generated with \\. This system
allows to have a pretty screen image (on systems with graphics mode) and,
for example together with LaTeX, a nice output. One could even write a LaTeX
style that inputs an article directly. (It should take care of the extended
character set, as described above).
 
So long
 
-=- tobi -=-
Newsgroups: alt.galactic-guide