info-mac@uw-beaver (05/16/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Thursday, 16 May 1985 Volume 2 : Issue 46
Today's Topics:
REdit, Localizer and other new *.hqx files
MacWrite file rescuer
MacAdvantage Bug
MacTerminal Document with Del/BS remapped (switched)
New DA/Font Mover
New DA/FONT mover from Apple
Trouble with new Font/DA Mover
Braille on the Mac ?
----------------------------------------------------------------------
Date: Wed 15 May 85 15:54:43-PDT
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: REdit, Localizer and other new *.hqx files
Readers:
Mike Tchao received two "resource editor" like programs at the AUC
conference, from Bud Colligan (?), which he asked me to upload.
(Thanks to Bill Croft and Seagate, this was much easier than using
macget over an ether -tip login) They are:
LOCALIZER.HQX 21133(7)
A very friendly way to change international resources
and textstrings, to translate a program into another
language.
REDIT.HQX 96307(7)
Friendly resource editor, with editors for icons, etc.,
and a resource dis- compiler. Lots of things you can
tweek with resedit are unfortunately not touchable
by REdit.
These files were slighlty damaged, and have been repaired by David
Liu:
DAM.HQX 26429(7)
DA-MOCKPRINT.HQX 3597(7)
DA-MOCKPTERMINAL.HQX 10706(7)
DA-MOCKTERMINAL.HQX 10566(7)
DA-MOCKWRITE.HQX 10988(7)
These
files were announced last week by werner@ u. texas, and are now here,
thanks to Doug Brutlag:
RAMSTART.DATA.1 0(8)
.HQX.2 23457(7)
.INFO.1 128(8)
.RSRC.1 17455(8)
(A previous file called RAMSTART.HQX is now RAMSTART2.HQX)
As most files are, the new files are documented in <info-mac>00dir
Enjoy ! -jma
------------------------------
Date: Sat, 11 May 85 21:47:45 EDT
From: winkler@harvard.ARPA (Dan Winkler)
Subject: MacWrite file rescuer
First two random notes: 1) VI mode for Word is done and will be sent
out to the few people who asked for it in a few days and 2) the reason
Word opens and closes the print driver for every page is so that it
can be printing one page while computing the next.
Here's a primitive Unix utility to rescue damaged MacWrite files. It
works on the encoded files used by version 3.0 and later.
[ This source is stored in UNIX-MWRESCUE.C on info-mac. -jma ]
/*
* mwrescue.c -- rescue a damaged MacWrite file (version 3.0 and later)
*
* Versions of MacWrite after 3.0 and before 4.0 have been unreliable.
* This program decodes damaged MacWrite files and recovers the text in
* them (once you've uploaded them to Unix). Someone should get it
* running on the native Mac.
*
* It is currently very simple since it treats the entire file as compacted
* text. However, MacWrite files can also contain some uncompacted text
* and some formatting information. The uncompacted text can be retrieved
* with the Unix strings command. The formatting information is output by
* this program as nonsense text.
*
* The text retrieved by this program emerges in the order it is stored in
* the file by MacWrite, which is not necessarily the order in which it is
* supposed to appear in the document.
*
* As primitive as this program is, I'm releasing it because:
* 1) I hope someone will improve it.
* 2) I've found that panicked students are more than glad to get
* their papers back even if the paragraphs are in random
* order with garbage text in between.
*
* History:
*
* 5/11/85 Winkler Created
*
*/
#include <stdio.h> #include <ctype.h>
#define TRUE 1 #define FALSE 0
/* Compressed characters for English. MacWrite stores this string
* in the resource fork of the document. A future improvement would
* be to find the string there (presumably in file.rsrc on Unix) rather
* than assume this one.
*/ char compchars[] = {' ', 'e', 't', 'n', 'r', 'o', 'a', 'i', 's',
'd', 'l', 'h', 'c', 'f', 'p', '\n' } ;
main() /* read encoded file from stdin and write text to stdout */ {
int c ;
do
{
c = getnibble() ;
if ( c != 0x0000000f ) macputchar( compchars[c] ) ;
else
{
int c2 ;
c = getnibble() ; c2 = getnibble() ;
/* need variables because C doesn't guarantee
* the order of evaluation of arguments. So if
* c and c2 below were replaced by getnibble()'s
* there would be no way of knowing which of the
* next two nibbles on stdin would be shifted
*/
macputchar( (c << 4) + c2 ) ;
}
}
while ( TRUE ) ; /* infinite loop. getnibble() exits on EOF */
}
macputchar( c ) /* translate returns to newlines and suppress
nonprinting characters */
int c; {
if ( isprint(c) )
{
if ( c != '\r' ) putchar(c) ;
else putchar('\n');
} }
getnibble() /* return the next nibble from stdin. exits on EOF. */ {
static int got = FALSE ;
static int c ;
if ( ! got )
{
if ( (c = getchar()) == EOF ) exit(1) ;
got = TRUE ;
return ( ( c >> 4 ) & 0x0000000f) ;
}
else
{
got = FALSE ;
return (c & 0x0000000f) ;
} }
------------------------------
Date: 11 May 1985 0820-PST
From: Contr04 <CONTR04 at NOSC-TECR>
Subject: MacAdvantage Bug
Reply-to: CONTR04 at NOSC-TECR
I believe I've discovered a bug in the runtime library, or at least in
my copy. I've been modifying Steve Maker's Skel.pas for the
peculiarities of MacAdv, and began getting curious crashes....
The following situations may or may not be related...
1) When compiling, and producing a listing, the compile goes OK, but
the
listing fails 3/4 of the way thru, giving me a message that I
have a
string overflow.....serious but not fatal..
2) When I ran the program, I get a system crash with ID=03 (unknown 68000
instruction). It looks like this occured when the program loads a
string (any string) from the resource file into a dialog box. very fatal.
3) Attempting to print from the Finder, same crash, same ID...which leads
me to believe that items 1 & 2 are related, and that the bug is not
always fatal.
What makes this all interesting, and seems to pinpioint the problem,
is that I then attempted to debug my program (thinking this was all my
fault). I used SetOptions to set the runtime file to Debug Runtime,
and made the appropriate settings to begin debugging. Much to my
suprise, SKEL ran like a champ....no errors, period. I switched back
to the library, Pascal Runtime, and.....CRASH!!! I then made a new
backup, and found the situation remained the same.
Has anyone else run into similar circumstances ? Please mail me your
experiences. If there is enough of these, I'll post a summary. I
purchased my copy back in November, and perhaps Softech has fixed this
since then. If they did, they sure didn't tell me. I certainly will
talk to them on Monday.
Steve Hyland (CONTR04 at NOSC-TECR)
------------------------------
Date: Tue 14 May 85 16:48:27-PDT
From: Jerold Wallis <WALLIS@SUMEX-AIM.ARPA>
Subject: New DA/Font Mover
I have read that D.A.M. version 1.4+ will automatically renumber desk
accessories in case of conflicting numbers when installing the DA.
Does anyone know if the new DA/Font mover provided by apple renumbers
them as well? (If not, it would be safer to use D.A.M.)
------------------------------
Date: Tue, 14 May 85 20:22:51 EDT
From: Joel Malman <malman@BBNH.ARPA>
Subject: New DA/FONT mover from Apple
Warning: Font sizes greater than 18 pitch cause the new DA/FONT mover
(from Apple) to crash on 128k Macs.
joel
------------------------------
Subject: Trouble with new Font/DA Mover
Date: 14 May 85 16:35:06 EST (Tue)
From: Steven B. Munson <sbm@Purdue.ARPA>
As long as people are complaining, I wanted to expand on the
complaint about the new font mover. It's great for moving DA's, but I
have noticed that there are not many fonts it will move without
complaining (every error is the same -- 4,-1, whatever that means).
Among the fonts it will not move are New York 24-point, Los Angeles
24- point, Camelot, and Florence. It will move the rest of the New
York fonts, but not 24-point. I have had to give up on it and go back
to using the old font mover. Is everyone having the same trouble?
Steve Munson
sbm@purdue.ARPA
sbm@purdue.CSNET
------------------------------
Date: 20 Apr 85 15:11:28 EST
From: Daniel.Zigmond@CMU-CS-SPICE
Subject: Braille on the Mac ?
A friend of mine is interested in writing some software dealing with
braille (word processors, etc.). To do this, he needs a keyboard that
has six keys that can be pressed down simultaneously (that is how
braille is usually typed, I guess). The order that the keys actually
arrive at the program is not important. The Macintosh seems to be
capable of having two keys pressed at the same time, but it if you
press more only two seem to get to the program.
Does anyone know a way around this? He is now thinking os making a
new keyboard but isn't sure how to interface it to the Mac. Is there
anyway of simply adding six push buttons to the Macintosh (through the
serial or keyboard interfaces for example)? This would be ideal if
the standard keyboard cannot do the job at all. Something similar to
the way the Apple ][ reads the paddle buttons would be fine. This
needn't be anything fancy. It just has to work.
Dan Zigmond
------------------------------
End of INFO-MAC Digest
**********************