[mod.mac] INFO-MAC Digest V5 #69

INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (03/27/87)

INFO-MAC Digest         Wednesday, 25 Mar 1987     Volume 5 : Issue 69

Today's Topics:
                       TextEdit length limitations
                       Strange, slow-running Mac+
                Re: suppressing LaserWriter's test page?
                        System3.2 GetFile bug fix
                           MacDraw file format
                    re: versaterm output to appletalk
                        Re:Do Loop Bug in Fortran
                  Re: keyboard repeat rate & threshold
                    Programmed I/O, another shortcut?
                   Excel References for Scholar's Aid
                            Clipper FKEY v1.5
                       An Apple harddisk question
                        re: word 3.0 and Mac IIs
                        More on Word 3.0 imports
                        Macintosh --> LeCroy 9400
                    Problems using TeXtures 0.9 (Mac)
                    Business Filevision file format?
                            Logo for the Mac?


----------------------------------------------------------------------

Date: Wed, 25 Mar 87 08:46:50 PST
Subject: TextEdit length limitations
From: David M. Gelphman         415-854-3300 x2538   DAVEG    at
From: SLACVM

For a long time the folklore regarding TextEdit was that it couldn't handle
records larger than 32K. If I look in the definition of the record I see that
the teLength field is defined to be INTEGER which implies that one could
have TextEdit records of 64K. At a recent meeting of developers, Steve Jasik
mentioned that the 32K limitation was a due to a bug in the 64K ROMS
and that he wasn't sure but he thought it was fixed in the 128K Roms.
   Since I have an application where the 32K limit just barely screws me
and the 64K limit gives me room to spare, I decided to try.  When I fed my
application a 45K file, it worked perfectly using TextEdit.  When I say
worked, I mean that scrolling, autoscrolling, and selection worked as expected.
Saves using the textedit record copy of the text were identical to
the original text. Since my application only displays the text and allows
the user to select and copy the text elsewhere, I can't comment on how
much TextEdit slows down when you try to INSERT text into a record that
large. I did find that the operations I do worked as rapidly as before, except
the initial display (after the call to TESetText) took proportionally longer
than before. When I fed a 90K file to my application, it only displayed
about 27K of the text, but it did not crash (was I lucky?) and it seemed to
work OK with that 27K of text. I wonder where the rest went!
   Personally I was glad to see that it looks like it will work for my
purposes. Have others found limitations that I haven't? If TextEdit does
indeed work with 64K textedit records, it sure would be nice if MockWrite
would allow you to use more than the 27-28K than you are currently allowed.
  I'm eager to hear what other's experiences have been regarding this issue.

David Gelphman                  BITNET address: DAVEG@SLACVM
Bin #88 SLAC                    ARPANET address:  DAVEG@SLACVM.BITNET
Stanford, Calif. 94305          UUCP address: ...psuvax1!daveg%slacvm.bitnet
415-854-3300 x2538
usual disclaimer #432 applies: my employer apologizes for the fact
that I have access to this net.

------------------------------

Date: Tue, 24 Mar 87 14:27:16 EST
From: Franklin Davis <davis%v750%wanginst.edu@RELAY.CS.NET>
Subject: Strange, slow-running Mac+

We have two Mac Plusses, Finder 5.3, Apple 20 hard disk.  One of them
seems to run slowly.  It is clearly visible with the Stars 1.6 DA.

The system on the other got trashed, and was restored from the slow
machine -- voila, they're both slow.

I just copied on a new System 4.0/Finder 5.4, but it still seems to run
slowly... Even stranger, on one machine the Stars DA flies "out," on
the other it flies "in."

Any sleuths with clues to this mystery?

  Franklin

davis@wanginst.edu              ...decvax!wanginst!davis

------------------------------

Date: Tue, 24 Mar 87 22:27:39 EST
From: matthews@tcgould.tn.cornell.edu (Dave Matthews)
Subject: Re: suppressing LaserWriter's test page?

A while back, I asked how to program the LaserWriter to not spit out
its test page every time it's powered up.  Jeff Gilliam from Berkeley kindly
supplied the PostScript code:

000000          % exitserver password
serverdict begin exitserver
statusdict begin
false setdostartpage

That's it.  You can send it directly through Appletalk if you have the desk
accessory PS Printer that passed through mod.mac.binaries a couple of weeks
ago.  Or connect via a serial cable and type it in from your favorite
terminal program.  Thanks, Jeff!

    -- Dave Matthews
                                                  In real life: anonymous
    ARPA:  matthews@batcomputer.tn.cornell.edu
    USENET:...{cmcl2,shasta,uw-beaver,rochester}!cornell!tcgould!matthews
    BELL: 607-533-7820  DISCL: My employer ignores my opinions altogether.

------------------------------

Date: Tue 24 Mar 1987 22:16 CST
From: Nihar Gokhale <MMAR013%ECNCDC.BITNET@wiscvm.wisc.edu>
Subject: System3.2 GetFile bug fix

Larry Rosenstein suggested I copy PACK 3 from System 4.0 and paste
into System 3.2 to solve the GetFile problem.  It's been working
so far without any mishaps.

Just thought you might like to know.
Nihar

------------------------------

Date: Tue, 24 Mar 87 10:11:54 PST
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: MacDraw file format

MacDraw pictures are not stored in raster format.  Instead, each
"object" (line, rectangle, oval, polygon, text string, etc.) is
described in terms of its size, line-style, position, fill-pattern,
etc.  A good conversion program can map these MacDraw descriptions onto
the corresponding entities in another system (e.g. imPRESS or
PostScript).  This permits the device which does the drawing to display
objects at the device's full resolution (e.g. 240, 300, or more
dots-per-inch), rather than at the limited 72-dots-per-inch resolution
of the Mac screen and Imagewriter dot-matrix.

I have a copy of Alan Weber's excellent MacDraw-to-imPRESS converter
that I've been hacking to function in my site's environment (we use
Scribe, rather than TeX).  It includes a description of many of the
details of the MacDraw file format [deduced by Alan, I assume;  I don't
think this format has ever been published officially].  We're now using
this converter to include MacDraw pictures in some of our technical
documentation;  it works quite nicely (but does have some
restrictions).  MacDraw documents printed via our Imagen 8/300 really
look nice... the grey-scale fillers really look grey, rather than
spotted.

Alan Weber posted "drawimp" to Usenet about a month ago.  I've offered
to repost it once I'm finished with the TeX-to-Scribe conversion
(probably sometime in May), and Alan seems willing to have me do so.

------------------------------

Date: Tue, 24 Mar 87 08:57:58 PST
From: digiorgi@Jpl-VLSI.ARPA
Subject: re: versaterm output to appletalk

I don't believe that I've seen anything that will allow you dump
directly via a terminal to a LaserWriter.  The reason that your
program works correctly with an Imagewriter is the fact it is
RS232 only; if it were set up using the Imagewriter driver, you
don't have 'pass through' serial port access there either.

The LaserWriter wants to see PostScript.  You'd need a terminal
emulator that understood and automatically sent the correct
PostScript translation, opened the AppleTalk necessary commun-
ications, and then ran the data out to the LaserWriter in real
time.  A little tricky , I think.

However, I do this all the time:
 Set up the Imagewriter/LaserWriter driver.
 Set Versaterm to "Save Stream"
 Run program... collect outputs.
 Turn off "Save Stream"
 Using miniWriter (if outputs are less then 30K in size), edit
  out unwanted text.
 Using MockPrinter, send file off to relevant printer as ASCII
  text. (MockPrinter multitasks with your host application; it
  slows everything down a lot, but is otherwise fairly
  useful.)

Hope this helps.
Godfrey DiGiorgi
digiorgi@jpl-vlsi

------------------------------

Date: 24 Mar 87 13:53:00 EST
From: <bouldin@ceee-sed.arpa>
Subject: Re:Do Loop Bug in Fortran
Reply-to: <bouldin@ceee-sed.arpa>

The bug in fortran with overlapping do loops, that was reported here
several days ago, has been forwarded to Absoft. It will be corrected in the
2.3 version of MacFortran.

On a general note: Absoft (as opposed to Microsoft) is usually very
responsive about bug reports and other user input. I am a beta tester for
Fortran, so if there are other bugs/suggestions do not hesitate to send
them to info-mac or to me directly.

I am: BOULDIN@CEEE-SED.ARPA.

------------------------------

Subject: Re: keyboard repeat rate & threshold
Date: Wed, 25 Mar 87 13:55:37 -0800
From: julian@riacs.edu

> From: MikeDixon.pa@Xerox.COM
>
> i've seen the following behavior on two different machines (a 512e and a
> +) , so i suspect it's universal, but it seems like a glaring (and
> annoying) bug:
>   a) bring up the control panel
>   b) set key repeat threshold to "off", rate to "slow"
>   c) close the control panel
>   d) shutdown the mac
>   e) turn it on, and try holding down a key while typing
>   f) hey, it repeats
>   g) bring up the control panel -- it *says* the repeat is off
>   h) click on off and close the control panel
>   i) it no longer repeats
>
> the values do seem to be saved, but somehow reinitialization isn't using
> them...  this is a real pain, since i don't want key repeat and seem to
> have to specify that everytime i turn my machine on.  does anyone know
> what's going on here, and how to fix it?
>  .mike.
>
> p.s.  both machines are running the most recent (well, pre-appleshare)
> system and finder (i forget the numbers)

This bug was discussed last summer in the Mac newsgroup. The problem is
worsed than described here. Besides the mishandling of the parameter,
if the control is left off, then the next time the system is brought
up, if the control is not reset manually, then scroll bars will
sometimes go into an infinite loop. I originally thought this was a bug
in More, since that's where I first saw it, but after going through the
problem with one of Living Videotext's people, we determined it was an
Apple problem. This problem is not particular to the first issue of
the 128K ROMs. The only workaround I know of to date is to just leave
the control on the longest delay setting; this causes no problems.

------------------------------

Date: 24 MAR 87 16:19-PST
From: WARREN%UWAPHAST.BITNET@wiscvm.wisc.edu
Subject: Programmed I/O, another shortcut?

This is my first posting to info-mac, although I have been an avid follower
of it for the past year or so. It is basically a request for a
clarification of certain aspects of the hardware description of the mac II
that appeared in the April Byte magazine.

I have always been somewhat disappointed in the large number of hardware
shortcuts which were made on the original Mac, mainly involving the use of
the 68000 for virtually everything from video operations to disk data
transfer.  It seemed particularly anomalous that a machine which used a
68000 in a sophisticated graphics environment would transfer data to and
from a hard disk using programmed I/O; i.e. using the 68000 to perform the
transfer.  I therefore eagerly awaited the successor to the Mac which I
expected would be a "no-compromise" machine and would be a solid hardware
base for the best of the high end personal computers for the next 5 years.
Preliminary hardware descriptions seemed to confirm my hopes that the
processor would be freed from such mundane tasks as video operations (in
principle, at least) or sound generation.

It was a shock, therefore, to learn that the Mac II still seems to use
programmed I/O for its hard disk. The Byte article called this "handshake
DMA"; but reading between the lines (and with the help of a friend who
is fairly knowledgable about SCSI jargon such as "pseudo- DMA") it seemed
clear that the processor is still almost totally absorbed by the data
transfer process. I know that the fine-grained interleaving of bus requests
between the processor and hard disk on true DMA machines will often allow
the processor to run at nearly full speed while the hard disk is transfering
data.

My questions are these: is my above reading of the Byte article correct?
If so, does anyone have any idea of how much a performance degradation
will result when the Mac II does demanding, multitasking operations
(either with A/UX or the future multitasking operating system)? I would
think that the strongly graphic orientation of Mac operations would make
such a degradation more noticable than would be the case on a more
conventional computer (retrieving bitmaps from the hard disk). Finally, would
a separate hard disk controller board (DMA) on the nubus solve the problem
(without incuring additional delays due to bus transfer handshaking)?

Thanks in advance for any information/feedback (sorry for the length of
the post).

Warren Nagourney
University of Washington
Dept. of Physics

------------------------------

Date: Tue, 24 Mar 87 13:57:14 EST
From: Mark Nodine <mnodine@labs-b.bbn.com>
Subject: Excel References for Scholar's Aid

Enclosed is an Excel database to supply references for the demo of Scholar's
Aid.  To use excel instead of MS-File with Scholar's Aid, do everything as you
normally would except that when it comes time to open MS-File do the following:

        1.  Create a new document in MS-Word and paste in the search text which
Scholar's Aid has put in the clipboard.
        2.  Remove the equal sign (=).
        3.  Do a Change... to change comma (,) to new paragraph (^p).
        4.  Select everything (command-click in selection bar).
        5.  Copy to clipboard.
        6.  Open the Excel references database.
        7.  Select the cell under Codeword in the Criteria area and Paste.
N.B. Before pasting, make sure there is enough space so that the extraction
area will not be overwritten.
        8.  Extend the selection to include the titles in the Criteria and do a
Set Criteria.  This is necessary because the Criteria might not be set for the
right number of lines.
        9.  Select the titles in the extraction area and do an Extract
(command-E).
        10. If you wish to sort according to authors or years, do so here.
Restore the selection when done.
        11. Copy what is selected to the clipboard.
        12. Create a new worksheet.
        13. Paste.
        14. Save the new worksheet as "Ref Table" in Text format.  This file
must be put in the same directory as the Scholar's Aid application.

It would be possible to automate most of the above process with an Excel
macro.  Any takers?

        --Mark

The example database follows.  It can be used as a template for creating your
own databases.

[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>SCHOLARS-AID-971-EXCEL-EXAMPLE.HQX

DoD
]

------------------------------

Date: Tue, 24 Mar 87 16:46:03 PST
From: digiorgi@Jpl-VLSI.ARPA
Subject: Clipper FKEY v1.5

This is Lofty Becker's Clipper FKEY, version 1.5.  I am posting
it as the last version I downloaded from the Sumex archives
was missing the documentation and the ability to 'unclip' text
in the clipboard, which is a worthwhile enhancement.  This
version works fine on both an old ROM 512 machine with HyperDrive
and on an upgraded 128 ROM machine with 2 Meg memory.  It is
in Binhex 4.0/PackIt format (uncompressed).

For those who are unfamiliar with the Clipper FKEY, it is a tool
specifically designed for those who work over with terminal
emulators a lot.  It allows you to utilize the good DA editors
(miniWriter, MockWrite, MiniEdit, etc), which perform word wrap
while in a telecommunications session for your editing. You
then copy the text you want to upload to the clipboard, elicit
the FKEY, and paste. The text will be truncated on word boundaries
at 70 characters and a return inserted, compatible with most
host computer editors.  Version 1.5 includes the additional feature
of being able to 'unclip' text copied to the clipboard from the
terminal emulator so that word wrap is properly dealt with
in your DA editor or MacWrite, Word, etc.  Instructions and
the address to send your contributions to are included in the
'clipper.info' file with the package.  (I honestly can't remember
if it is ShareWare or Public Domain, but I bet Lofty Becker
wouldn't mind a thank you note or a fin if you sent it...)

Godfrey DiGiorgi
digiorgi@jpl-vlsi
March 24, 1987

[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>FKEY-CLIPPER-15.HQX

DoD
]

------------------------------

Date: 24 Mar 87 15:19 EST
Subject: An Apple harddisk question
From: Jeff (hallett@ge-crd.arpa)

Hi all!  (Hey Apple, gotcher ears on??)

Are the newer Apple SCSI drives still as noisy as they used to be?  Here
where I work we got one about 3 months ago and it is incredibly noisy (it
is actually louder than the IBM on my officemate's desk!).  I heard that
Apple had rigged a deal to get quieter fans.  Have they?  (Read as:  If
I order one now, will it be quiet or loud?)

Also,  when we order one with cables, do we get a choice of cable length?
The 1 foot one I have in my office is too short; I want a 2 foot one with
the next drive I order, if possible.

See ya on the flip side!

Disclaimer:  My boss thinks I'm doing something else with my computer!  Don't
let him know!

------------------------------

Date: Tue, 24 Mar 87 07:59 EST
From: CTRMAC%IRISHMVS.BITNET@wiscvm.wisc.edu
Subject: re: word 3.0 and Mac IIs

Shortly after the announcement of the Mac II, when compatability
was being complained about by people who dont know the mac very
well, Word 3.0 was pointed to as being one of the culprits.
Microsoft quickly found the bug, which apparently was pretty
small, but they saw no need to release yet ANOTHER version
for a machine that wasnt out yet.  This goes in the To Be Fixed
file I guess.  From what I hear it was just something they
werent supposed to be doing anyways, but they could get away
with on other machines.

In case anyone is wondering, ID 25 is "Out of Memory"...
sure it is.

------------------------------

Date: Tue, 24 Mar 87 09:24 EDT
From: BELSLEY%BCVAX3.BITNET (DAVID A. BELSLEY)
Subject: More on Word 3.0 imports

An earlier posting noted the problem Word 3.0 has with importing some 1.05
documents - line spacing on the screen and that in the printed output are
not always the same.  Extra vertical space is occasionally added.  This can
be seen in the page preview mode, but not in the screen-edit mode.  Further-
more, editing that seems to get rid of it proves ineffective upon openning
the document again.

I have found one fairly effective fix:  select the paragraphs surrounding
the offending paragraph mark, and force the line spacing by inserting a
minus sign before the vertical spacing in the paragraph command box.  In
particular, get rid of any automatic spacing that may be in effect.  If,
then, the document is double spaced, and you find the spacing to be "auto",
make it -24 points.  Some other adjustments may also be needed to
recover the original look of the paragraph.

I have found this problem to be particularly troublesome when any
special types of short paragraphs, such as equations, occur between normal
text paragraphs.

I wonder what is going on at MicroSoft these days?  Is it just wishful
thinking to picture numerous groups frantically producing solutions to these
many problems so that a good and reliable product can be distributed in
fairly short order?  Or is it possible there are numerous groups collected
in circles and emitting sinister cackles?  In any event, we certainly have
Word 3.0Bn at the momement.

david a. belsley
boston college          belsley@bcvax3.bitnet

------------------------------

Date: Wed, 25 Mar 87 12:10:16 est
From: rs4u#@andrew.cmu.edu (Richard Siegel)
Subject: Macintosh --> LeCroy 9400

     I have been trying, without much success, to interface a Macintosh
to a LeCroy 9400 digital ocilloscope. I've interfaced other instruments
before, but the documentation and the LeCroy's behavior
are so inconsistent that this box is ruining my day.

If anyone's had any successful work with this box ( preferably in Pascal),
either through the serial ports, and IEEE/Serialo coupler, or the National
Instruments SCSI/IEEE coupler, I would very much appreciate some help.

  Rich

Richard M. Siegel
Mail Stop 231
NASA/Langley Research Center
Hampton, Va. 23665
(804) 865-3036

------------------------------

Subject: Problems using TeXtures 0.9 (Mac)
Date: Wed, 25 Mar 87 16:54:23 -0800
From: mbb@portia.Stanford.EDU


I've encountered two major problems using TeXtures, and was wondering
if anyone has run into them and/or has devised a way to work around
them.

1.  On certain pages, TeXtures places a very large squarish block
of black near the bottom of the page.  The block can be as large as
one-quarter of the total page area.  I've not been able to determine
a pattern, and hence am not sure as to the cause.  Apparently the
folks at Addison-W are well aware of this, although I haven't
heard back from them as yet.

2.  My group recently switched to the new versions of the LaserPrep
and LaserWriter files (version 3.3).   Now, on pages that contain
bit maps (such as MacPaint pictures), I'm getting PostScript error
message "dictfull; Offending Command: def", which leads one to wonder
if TeXtures is attempting to add something to Apple's PostScript
dictionary.

If anyone can offer any insights, I'd be quite grateful.

thanks
Malcolm Brown
mbb@portia.stanford.edu

------------------------------

Date: Tue, 24 Mar 1987 14:36 PST
From: OZ <OZ001%UWACDC.BITNET@wiscvm.wisc.edu>
Subject: Business Filevision file format?

Does anyone know the Business Filevision file format or know of a product
that allows read only access to Filevision databases?

------------------------------

Date: Wed, 25 Mar 87 16:56:33 CST
From: keith@cs-gw.D.UMN.EDU (Keith Pierce)
Subject: Logo for the Mac?

I am interested in any information available comparing the several
versions of Logo now available for the Mac.  Both positive and negative
experiences are appreciated.

Keith Pierce                           keith@cs-gw.d.umn.edu
Department of Computer Science         ...!ihnp4!rosevax!umnd-cs!keith
University of Minnesota, Duluth
Duluth, MN 55812-2496

------------------------------

End of INFO-MAC Digest
**********************