Info-Atari16 Digest Fri, 27 Sep 91 Volume 91 : Issue 508 Today's Topics: CPX Information Empire - where to get? (Interstel adr. wanted) Hebrew Fonts lharc 2.01e vs zoo 2.1: some tests ST Magazines (was More Lies From Atari?) ST Magazines (was Re: More Lies From Atari?) TeX, which do I get? (Now that I kno Trip-A-Tron (Colourspace) Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 26 Sep 91 06:31:17 GMT From: mcsun!news.funet.fi!funic!nic.funet.fi!lahtinen@uunet.uu.net (Kimmo Lahtinen) Subject: CPX Information To: Info-Atari16@naucse.cse.nau.edu In ST-Computer Magazine there has been several articles about CPX, but of course in German. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Kimmo Lahtinen E-Mail : lahtinen@gideon.fmi.fi or Finnish Meteorological Institute kimmo@field.fi '' Phone : +358 0 758 1322 Possessed by a Spirit G3 Fax : +358 0 758 1396 ------------------------------ Date: Fri, 27 Sep 91 14:08:24 MEZ From: Wolfgang Ley Subject: Empire - where to get? (Interstel adr. wanted) To: Atari ST users forum Hi ppl, I would like to have the Atari-ST Version of Empire (Wargame of the century - NOT "The empire strikes back"). I can't find a distributor of this game... all i know is that the programm is from INTERSTEL. Is there anyone out who knows the adress of Interstel?? Is there an other way to get Empire?? Thanks, Wolfgang. --------------------------------------------------------------------------- Wolfgang Ley e-mail: Teichstrasse 9 from BITNET : BWWL@DCZTU1.BITNET 3392 Clausthal-Zellerfeld from Internet: BWWL@ibm.rz.tu-clausthal.de Tel. 05323/82132 (voice) or BWWL@sun.rz.tu-clausthal.de --------------------------------------------------------------------------- ------------------------------ Date: 26 Sep 91 15:10:07 GMT From: europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!travis!jgj@uunet.u u.net (Jeff Jackson) Subject: Hebrew Fonts To: Info-Atari16@naucse.cse.nau.edu I wish to thank the numerous people who responded to my posting looking for a Hebrew Font. I found two sets of freely available ones: > Date: Thu, 05 Sep 91 13:52:16 IST > From: YOEL%BGUVM@TAUNIVM.TAU.AC.IL > Organization: Ben-Gurion University, Beer-Sheva, Israel > Subject: Re: Hebrew Font Wanted > To: jgj@travis.csd.harris.com > > Hello. You can put Mac hebrew fonts from my FTP anonymous 132.72.20.2 > HEBFONT.HQX fonts > HEBSYS.HQX Hebrew system 6.03 > RAVKTAV.HQX Hebrew editor > Michael and > Date: Thu, 5 Sep 91 19:35:42 -0400 > From: brecher@husc.harvard.edu (Jonathan Brecher) > To: jgj@travis.csd.harris.com (Jeff Jackson) > In-Reply-To: jgj@ssd.csd.harris.com's message of 4 Sep 91 20:04:06 GMT > Subject: Hebrew Font Wanted > > >Is there anywhere I can get a postscript Hebrew Font? PD would be nice > >but $$$ are not out of the question. Thankx in advance > > Oh boy, time to toot my own horn! > You can get my ShareWare Hebrew fonts from mac.archive.umich.edu in > /mac/system.extensions/fonts/type.one.fonts. > > Look for the files ShalomOldStyle.hqx, ShalomStick.hqx and ShalomScript.hqx > (or something similar). If you have any problems, drop me a line and I'll > upload you some fresh copies. > jonathan brecher The first one didn't quite fit my needs because I needed full pointing. The second I found after being better than half way through designing my own. It has full pointing, though it does it with zero sized characters with negative offsets (I think). My screen display software doesn't something about it. I decided I would only be satisfied if I did my own, so I am completing it. Those of you who wanted one too, can get one of the above, or wait till I am finished with mine and I'll email it to you. It will consist of 12, 18, 24 and 36 pt screen fonts (For Monochrome Atari ST PageStream), the FM (font metrics) and DMF (dot-matrix font) files as well as a Type-3 postscript file and the PSF file for interfacing it to PageStream. My big goal is for it to look good at 12pt on a puny 300dpi printer. I suspect the other two would look much better at 1200dpi. The way I am handling the overstriking is kerning pairs. There are two character widths for the consonants. All the vowel points (except holem, which is special because it goes in the corner instead of the center), are the same size as the small consanants. "We" would be a waw with a seghol under it. For the large consonants, a pad character must be added after the vowel to make up for its smaller size, hence "Be=". For holem, there is both a small (o) and a large (O) one. It must be put after the character to its left (BOY) would put a Holem between Beth and Yodh. Holem-waw is "w". I have the basic set done, but I am still not happy with Aleph and a couple others, plus I still discover an occassional bug in my kerning (lots of pairs). -- ============================================================================ Jeffrey Glen Jackson _|_Satan jeered, "You're dead meat Jesus, I'm gonna jgj@ssd.csd.harris.com | bust you up tonight." x5120 | Jesus said, "Go ahead, make my day." ------------------------------ Date: 26 Sep 91 06:45:25 GMT From: convex!rosenkra@uunet.uu.net (William Rosenkranz) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu friends- to help understand the claim that lharc is the best thing since sliced bread, and so much better than zoo 2.1, i ran some tests. this is a rather long post. if you think i am crazy, hit 'n' now. or put me in your kill file :-). if you have an open mind, read on for enlightenment... summary: zoo 2.1 is just about as fast as lharc 2.01e and makes files about the same size. rumors dispelled: using assembly language offers huge speed advantages over C in the problem domain of file archivers. rumors confirmed: C programs compiled with GNU C offer significant advantages (read on...). C programs compiled with GNU C tend to be rather large executables. tests: 1 archive of archives 2 archive of programs and their docs 3 test wildcard expansion and long command lines 4 handle ~C interrupt i felt these sorts of tests were important to me. they may or may not be your cup of tea. in that case do your own tests (and report them to the rest of us). missing is a test of predominantly text files. also missing are tests of directory trees and very large files. i've spent far too much time on this already, just to prove a point. test platform is mega4 (4 MB) 8 Mhz, TOS 1.2, using gulam CLI. environment included TMP=ramdisk and TEMP=ramdisk (i confirmed there was no use of hard disk by observing that no disk access lights went on). all tests were done with files (executable, data files, and archives) in a 1.5MB ramdisk. this tends to eliminate the effect of partitions which are not empty, differences in drive seek rates, etc. knowing that zoo is sensitive to i/o, i wanted to factor out i/o from the test as much as i could. i did not want to clear an entire partition for this. versions of each program were as follows: lharc 2.01e (questor, Assemblerversion vom 14.07.1991) zoo 2.1 (1991/07/14 22:39:26) i would call this "equal" technology since the versions were realized on the same dates! zoo was compiled with GNU c (gcc) though i do not know which version. i confirmed this by both "printstk zoo.ttp" which did not fail, listing a reasonable stacksize (16k) and by "strings -10 zoo.ttp" which listed ascii strings that would appear if gcc was the compiler. it also looks like zoo 2.1 was compiled with MiNT so that it could be "backgrounded" in a multiprocessing environment. i could be way off base here, however. i just spotted the string "MiNT" in the .ttp. i saw no evidence that lharc was equally endowed. it also looks like zoo may support UNIXMODE tho i don't use it myself. UNIXMODE allows configuration so that forward slashes "/" can be used in file paths as well as backslash "\". lharc does not appear to support this either. note that if needed, the zoo program's stack could be increased with the fixstk utility offered with GNU C. i do not know how lharc does its memory management nor whether it would ever need stacksize adjustments. my guess is that memory is either statically allocated with fixed size arrays or with GEMDOS Malloc. i would know for sure if source was available. i am unable to ascertain how much memory lharc Mallocs if it does do so. this can be important in a multiprocessing environment like MiNT. if it Mallocs all memory, then no other program could be started until lharc finishes. commands used: add files: lharc a lll zoo ah zzz extract files: lharc x lll zoo -extract zzz list archive: lharc v lll zoo -list zzz gulam's time command was used to get the times which are all in seconds unless otherwise noted. ---------------------------------------------------------------------------- test 1: used these files for data (chosen at random): -rw------- 1 u 39071 Sep 22 21:10 f1.zoo -rw------- 1 u 69918 Jul 23 00:46 f2.zoo -rw------- 1 u 2303 Sep 4 03:16 f3.h -rw------- 1 u 74183 Sep 22 21:15 f4.zoo lharc: add files: this took 82 seconds to complete, resulting in a file of size 181588 bytes. lharc: extract files: this took 27 seconds. HOWEVER, the dates and times of the extracted files were NOT correct. they were the current date and time NOT the times in the archive: -rw------- 1 u 39071 Sep 25 21:56 f1.zoo -rw------- 1 u 69918 Sep 25 21:56 f2.zoo -rw------- 1 u 2303 Sep 25 21:56 f3.h -rw------- 1 u 74183 Sep 25 21:56 f4.zoo lharc: list files: LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991) Listing of archive : 'LLL.LZH' Name Original Packed Ratio Date Time Attr Type CRC -------------- -------- -------- ------ -------- -------- ---- ----- ---- F1.ZOO 39071 37952 97.1% 91-09-22 21:10:22 ---w -lh5- 3386 F2.ZOO 69918 68195 97.5% 91-07-23 0:46:32 ---w -lh5- E91B F3.H 2303 1127 48.9% 91-09-04 3:16:56 ---w -lh5- 0526 F4.ZOO 74183 74183 100.0% 91-09-22 21:15:04 ---w -lh0- FA5E -------------- -------- -------- ------ -------- -------- 4 files 185475 181457 97.8% 91-09-25 21:15:48 zoo21: add files: this took 93 seconds to complete, resulting in a file of size 181865 bytes. zoo21: extract files: this took 25 seconds. the times and dates of extracted files were exactly correct (same dates and times as files in the archive). zoo21: list files Archive zzz.zoo: Length CF Size Now Date Time -------- --- -------- --------- -------- 39071 3% 37954 22 Sep 91 21:10:22+64 3386 f1.zoo 69918 3% 68197 23 Jul 91 00:46:32+64 e91b f2.zoo 2303 51% 1129 4 Sep 91 03:16:56+64 0526 f3.h 74183 0% 74183 22 Sep 91 21:15:04+64 fa5e f4.zoo -------- --- -------- --------- -------- 185475 2% 181463 4 files ---------------------------------------------------------------------------- test 2: used these files (from mint 0.8 distribution, this was in file f4.zoo in the test above, by the way, a "zoo ah" archive): -rw------- 1 u 25636 Apr 17 23:40 bgacc.acc -rw------- 1 u 2168 Apr 18 00:29 bgacc.doc -rw------- 1 u 1189 Dec 9 23:05 gem.prg* -rw------- 1 u 9871 Mar 16 18:12 init.doc -rw------- 1 u 23586 Apr 5 23:18 init.prg* -rw------- 1 u 651 Dec 15 00:15 init.rc -rw------- 1 u 74125 Apr 18 00:19 mint.prg* lharc: add files: this took 63 seconds to complete, resulting in a file of size 73820 bytes. lharc: extract files: this took 23 seconds. again, dates were wrong: -rw------- 1 u 25636 Sep 25 22:02 bgacc.acc -rw------- 1 u 2168 Sep 25 22:02 bgacc.doc -rw------- 1 u 1189 Sep 25 22:02 gem.prg* -rw------- 1 u 9871 Sep 25 22:02 init.doc -rw------- 1 u 23586 Sep 25 22:02 init.prg* -rw------- 1 u 651 Sep 25 22:02 init.rc -rw------- 1 u 73820 Sep 25 22:01 lll.lzh -rw------- 1 u 74125 Sep 25 22:02 mint.prg* lharc: list files: LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991) Listing of archive : 'LLL.LZH' Name Original Packed Ratio Date Time Attr Type CRC -------------- -------- -------- ------ -------- -------- ---- ----- ---- BGACC.ACC 25636 13854 54.0% 91-04-20 15:40:26 ---w -lh5- EAF8 BGACC.DOC 2168 1065 49.1% 91-04-20 16:29:00 ---w -lh5- BD8E GEM.PRG 1189 866 72.8% 90-12-12 14:05:20 ---w -lh5- C714 INIT.DOC 9871 3961 40.1% 91-03-19 9:12:10 ---w -lh5- D569 INIT.PRG 23586 13558 57.5% 91-04-08 14:18:34 ---w -lh5- B325 INIT.RC 651 353 54.2% 90-12-17 15:15:46 ---w -lh5- 21B5 MINT.PRG 74125 39917 53.9% 91-04-20 16:19:22 ---w -lh5- 496E -------------- -------- -------- ------ -------- -------- 7 files 137226 73574 53.6% 91-09-25 22:23:24 zoo21: add files: this took 74 seconds to complete, resulting in a file of size 74183 bytes. zoo21: extract files: this took 23 seconds. dates ok. -rw------- 1 u 25636 Apr 20 15:40 bgacc.acc -rw------- 1 u 2168 Apr 20 16:29 bgacc.doc -rw------- 1 u 1189 Dec 12 14:05 gem.prg* -rw------- 1 u 9871 Mar 19 09:12 init.doc -rw------- 1 u 23586 Apr 8 14:18 init.prg* -rw------- 1 u 651 Dec 17 15:15 init.rc -rw------- 1 u 74125 Apr 20 16:19 mint.prg* -rw------- 1 u 74183 Apr 18 00:29 zzz.zoo zoo21: list files: Archive zzz.zoo: Length CF Size Now Date Time -------- --- -------- --------- -------- 25636 46% 13856 17 Apr 91 23:40:26+64 eaf8 bgacc.acc 2168 51% 1067 18 Apr 91 00:29:00+64 bd8e bgacc.doc 1189 27% 868 9 Dec 90 23:05:20+64 c714 gem.prg 9871 60% 3963 16 Mar 91 18:12:10+64 d569 init.doc 23586 43% 13560 5 Apr 91 22:18:34+64 b325 init.prg 651 45% 355 15 Dec 90 00:15:46+64 21b5 init.rc 74125 47% 39919 18 Apr 91 00:19:22+64 496e mint.prg -------- --- -------- --------- -------- 137226 47% 73588 7 files ---------------------------------------------------------------------------- test 3: i made a dummy directory with enough files so that the command line length would be longer than 125 chars (which is what Pexec normally can handle). GNU C programs can exploit ARGV extended argument passing (which is sanctioned by atari). gulam can handle this as well with "setenv env_style mw" which i set. files were: xxxxxxxx.001 xxxxxxxx.004xxxxxxxx.007 xxxxxxxx.010 xxxxxxxx.013 xxxxxxxx.002 xxxxxxxx.005xxxxxxxx.008 xxxxxxxx.011 xxxxxxxx.014 xxxxxxxx.003 xxxxxxxx.006xxxxxxxx.009 xxxxxxxx.012 xxxxxxxx.015 with zoo i did: zoo a zzz * and zoo a zzz '*' both worked. that means zoo can handle long lists of file names and wildcards itself. i tried: lharc a lll * and my system crashed! lharc does NOT handle extended args. and what's more it crashed my system! i did not want to reboot again so i did not test to see if it handles wildcards itself. this is TOTALLY unacceptable. ---------------------------------------------------------------------------- test 4: i tested each program's ability to be interrupted. during archive creation, i issued a control-C to both. both stopped. however, lharc left a file behind "lharc.)2(" so it does not really handle signals. zoo does since it was compiled with GNU C library (another reason why it is better to use a compiler with a decent library). zoo cleaned up after itself. ---------------------------------------------------------------------------- recap: create archive extract files comments time size time test 1 lharc 82 181588 27 extracted file dates wrong zoo 93 181865 25 zoo/lharc ratio 1.13 1.0015 0.926 test 2 lharc 63 73820 23 extracted file dates wrong zoo 74 74183 23 zoo/lharc ratio 1.17 1.0049 1.000 conclusions: tho hardly an exhaustive test, nevertheless i suspect most tests will show similar results. i am also sure that someone can find an anomoly where either one kicks the pants of the other. i draw these conclusions: - lharc is no more "blindingly fast" than zoo 2.1. in fact for extraction it can be SLOWER. extraction is probably used more often by casual users. assembly language lharc is no more than 15% faster on average on compression and at best the same or slower on extraction as the "hands off" C of zoo. in fact given this problem domain (construct a system to compress and store files) it appears that C is an excellent choice over assembler. if lharc was 2 or 3 times faster i would alter this view. but 15% or less is just not enough to warrant the added inflexibility of assembler. - lharc is not especially better at compressing files. i would hardly call less than 0.5% difference significant. in fact since you don't store bytes on disk, rather clusters, there may be no savings at all on average. - zoo archives appear to be larger because of the headers are most likely larger for each file. if you examine the sizes of the compressed files, you will note that lharc is 2 bytes smaller than zoo, appearently independent of file size when lh5 compression is used. - the size of the executables is significantly different. about 2x (lharc being the smaller). however, after packing with pfxpak, zoo is about 53k and lharc is about 28k. the difference is not that significant in a 16 MB partition. what i do find fascinating is that the executable for lharc is itself an archive! this is a really super hack. incidently pfxpak was written by the very same thomas questor who provides the lharc under scrutiny. (and thomas, i DID disassemble it, tho the crash in test 3 wiped it out since i had the source on the ramdisk. maybe you could mail me the source now...:-). still, i generally dislike self extracting archives though this is a twist on that concept. - lharc's not getting the dates and times of extracted files correct is unacceptable. PERIOD. if it can't get this correct, it is of no use to me. i need the timestamps preserved because i use tools which depend on the relative difference in timestamps between files (e.g. make and RCS). if this is a case of RTFM, then i will first say "yes, but..." and mention that getting the timestamp right should be the default behavior. - lharc cannot handle long lists of files. and when you do give it such a list, it crashes the system. this is also nasty, unacceptable behavior. in contrast, zoo can handle extended args and wildcards with ease. - the version of zoo sources i have can easily be ported to any system with POSIX library and an ANSI C compiler. this includes scores of systems from the PC and ST to supercomputers. lharc cannot (even if i did have the source) since it is written in assembler. note that all assemblers are different on the ST as well so that it might take significant effort to compile it with another assembler, even on the ST. - tho cute and even helpful, the lharc "thermometer" that tracks progress with *'s messes up redirected output: lharc a lll file >log it should be disabled if !isatty(1). zoo has no problem at all with stdout redirection to files. - nitpicking: zoo lists files one per line. it is easier to grep things out for more specialized uses (like making lists of all .c files with their statistics). - there is one version of zoo 2.1 (that i know of) for ST, unix, and PC. i stopped counting the versions of lharc for the ST alone at about 6 or 8. there is only one author of zoo. - zoo 2.1 can extract files from ANY zoo archive of equal or lesser version. older versions of zoo can list any zoo archive even if made with a newer version. if a newer version is needed to extract files, the older zoo tells you what version you need. zoo 2.1 will also (by default) make archives which older versions of zoo will extract. you have to ask for the high compression algorithm specifically with the "h" command modifier. - i can take the zoo 2.1 archive up to a unix (or VMS) system and extract the archive with no effort. i do not have to track down a version which will extract it. the original version posted to the net (source code) works fine. i have tried unlzhing an lh5 archive on unix with LHarc for unix v1.02 with no luck. it complains that it cannot extract this method. in this case someone is going to berate me saying "well, you should get this_and_such version and quit moaning". i would (naturally) respond with "so how often do i have to update lharc on unix to remain current? i already have 2 versions. how many more do i need? i only need one version of zoo 2.1!". if it is any consolation, at least 1.02 does not core dump when it finds this out (0.03 does, at least my port on a convex does). - neither program has a particularly consistent set of commandline switches. after years of use, however, i am at least used to zoo. and neither program as-is offers any particular advantage over the other from the desktop from what i can see. i never use the desktop so don't take my word for this. zoo does expand wildcards in file lists. i did not test lharc, fearing another system crash. - comp.binaries.ibm.pc has used and continues to use zoo as its primary archiver for posted programs. it also uses zip and the occasional lharc file as well, however. now that zoo 2.1 is out, i see the use of lharc waning there. zip is still used. i would compliment thomas on a fairly good program, at least a good improvement over early lharcs on the ST. he has done significant work to try and eliminate the inconsistencies between lharc versions. however, i just don't see a huge advantage in using lharc now that zoo 2.1 is available. and not getting the timestamp correct on extraction is very bad indeed. is there a bug fix for this or am i missing somthing here? and not handling long lists of files and crashing when presented with such a list is beyond unacceptable. note that if he had used C instead of assembler, especially GNU c, some of these problems would have been taken care of by the library. as it stands, he has to do this himself. consider this "user feedback" when you plan the next upgrade, thomas. i confess that i did not read the docs for lharc. as far as i know the questor version docs have always been in german up until 2.01e which i just got within the past 2 weeks. but then again i did not read the docs for zoo 2.1 either. the only change in zoo 2.1 has been the "h" modifier for high compression and the "a//" addition for recursive directory searches so there was no need to read anything. both of these new features were mentioned in the README file. the rest functions as it always did. nothing new to learn. i already knew how to use zoo since i have used it for at least 2+ years. i claim no authority in the use of lharc. i just ran it as i would zoo or arc or lharc on unix (the version i have, at least) like the dumb user i am. if these results can be bettered, please let me know how. also, i know of some optimizations for zoo which may not have been applied in the version i have (posted to comp.binaries.atari.st by steve grimm). i know the unix version with larger i/o buffers is significantly faster (at least 20% on a convex C210 with VME disks). if that is also true on the ST, then the small speed advantage lharc has (only on compression, that is) over zoo goes away. and zoo 2.1 may be even faster than lharc on extraction in that case. i note that the speed difference in both test cases is 11 seconds during archive creation. it might be possible that this is a constant. if so, then doubling the amount of work will lower the net speed advantage to under 10%. also note that this version of zoo appeared within days of being posted to alt.sources. i am sure it has not been tuned in the slightest. and i hope it stays that way, so we don't end up with 50 versions of zoo. it would also be nice to look at each program's i/o efficiency by controlled tests in cluttered hard disk partitions or on virgin-formatted floppies. i have not done that nor do i think it is worth the effort at this point. also each program's handling of directory trees should be tested. zoo 2.1 (on the ST only!) now has an improved method for doing recursive hierarchies (a//). the unix version still uses the "find . -print | zoo aI archive" method as far as i know. this is not possible with the ST without CLIs that support pipes. gulam (and the desktop) do not support pipes. believe it or not i have tried to be impartial. and the benchmarking process is not alien to me, tho i would not consider this a very thorough test. that would require a better set of "calibrated" test files (these do exist). i did not look at a set of files that were predominantly text, eventhough this is one of my heaviest uses (source archives). however, the files i chose were probably more indicative of the casual user's needs (programs with docs, and other archives). i try to look past speed and size alone. these are not highest on my priority list for archivers, though they are important. i remember the very early versions of lharc which took EXTREMELY long times to compress. maybe 3-5 times longer than arc or zoo. this lharc is among the best, if not the best version of lharc, but it is far from being the best archiver overall, In My Humble Opinion.... comments??? rebuffs??? name calling??? -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 26 Sep 91 05:06:48 GMT From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv!seitz@arizona.edu (Matthew Seitz) Subject: ST Magazines (was More Lies From Atari?) To: Info-Atari16@naucse.cse.nau.edu In article steve@thelake.mn.org (Steve Yelvington) writes: > >There's nothing wrong with the DTP software used to produce these >magazines. The limiting factors are: > > -- The output devices. Typesetting a magazine on a 300dpi laser > printer isn't going to yield professional-quality output > regardless of the software used to place the text on the page. > Some ST magazines (and ``fanzines'' is probably a good description) > can't afford any better, sad to say. Can't even afford to take the Postscript files down to the local printshop for 600 dpi or 1200 dpi output before photocopying? I can't believe the Atari magazines are hurting that badly. -- Matthew Seitz seitz@netcom.com ------------------------------ Date: 26 Sep 91 05:04:35 GMT From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv!seitz@arizona.edu (Matthew Seitz) Subject: ST Magazines (was Re: More Lies From Atari?) To: Info-Atari16@naucse.cse.nau.edu In article <9469@cactus.org> covert@cactus.org (Richard Covert) writes: > >The rags you mentioned are the standard examples give by all >Atari Apologists (AA) (TM by Covert)!! And while they are all >good mags, they are NOT glossy nationally distributed mags which >show up in the big bookstores. they are rags which you have to >hunt to find. SO, novice Atarians wouldn't even know about them. > 1) If they are "good mags", why do you call them "rags"? To me, "rag" implies a poor magazine. 2) Personally, I'll take "good mags" over "glossy, nationally distributed mags" any day of the week. As you point out later, many times the "glossy, nationally distributed mags" are often little more than cheerleaders. 3) Well, if you were able to hunt enough to buy an Atari ST, I'd think finding the magazines would be easy. Look on the shelves of the store where you bought the computer. Honestly, while I understand the desire for more widespread support for the ST, I don't see it as a requirement. The ST works and works well, even if its not advertised. There continues to be new, good software written for it, even if its not by big name companies. And there continue to be good magazines, even if they aren't full color glossies, and you can't find them at Walden Books. Yes, the ST is a hobby computer, with a small cult following by DOS standards. But that's a far cry from saying the ST is dead or dying. How many people out there have ever heard of UseNet? How many slick magazines cover RN? But no one suggests UseNet is dying. In fact, I'd say its booming. I think there's still room for the ST to continue to live alongside the big two (DOS and Mac) and alongside it's cousin the Amiga. You may have to look a little harder to find support, but it's there. -- Matthew Seitz seitz@netcom.com ------------------------------ Date: 22 Sep 91 06:34:46 GMT From: mcsun!unido!mcshh!malihh!pfunk!blackbox@uunet.uu.net (Michael Kistenmacher) Subject: TeX, which do I get? (Now that I kno To: Info-Atari16@naucse.cse.nau.edu In <91262.123150ONM07@DMSWWU1A.BITNET>, ONM07@DMSWWU1A.BITNET writes: >Hu? As far as I know, Lutz Birkhahn has just finished the new version (and >the newest version of Metafont is 2.7x, isn't it?) > Yes, you're right. Sorry, but I got confused of the version-numbers. 2.9 was the release-number of the old Metafont 1.7. I don't know the new version from Luth Birkhahn, so forgive me that I didn't mention. Bye....Michael -- /------------------------------------\ | Michael Kistenmacher / blackbox | | 2000 Hamburg 61 / Schippelsweg 64 | | West Germany / ++ 49 40 552 37 66 | \------------------------------------/ ------------------------------ Date: 27 Sep 91 13:22 UT From: /PN=COLIN.W.HUNT/O=SPRINTINTL/ADMD=TMAILUK/C=GB/@sprint.com Subject: Trip-A-Tron (Colourspace) To: info-atari16@naucse.cse.nau.edu Sometime ago someone posted a message asking for a copy of Trip-A-Tron, the Light Synth for the ST by Jeff Minter. Well, I can't offer my copy of Trip-A-Tron but thought that everyone may be interested in the news that Jeff has made the ST version of Colourspace shareware, and it therefore should soon be available on PD libraries everywhere. There are also rumours that Trip-A-Tron _may_ be made PD, but I don't believe this (but you never know!) Colin ------------------------------ End of Info-Atari16 Digest ******************************