Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!vax135!cornell!uw-beaver!info-mac
From: info-mac@uw-beaver (info-mac)
Newsgroups: fa.info-mac
Subject: Re: QD Text Transfer Modes
Message-ID: <2011@uw-beaver>
Date: Wed, 24-Oct-84 06:20:59 EDT
Article-I.D.: uw-beave.2011
Posted: Wed Oct 24 06:20:59 1984
Date-Received: Thu, 25-Oct-84 03:49:32 EDT
Sender: daemon@uw-beave
Organization: U of Washington Computer Science
Lines: 29

From: Mark H. Nodine <mnodine@BBNH.ARPA>
The restriction which eliminates the use of srcCopy (and other) modes for
the drawing of text is because the area which is affected by drawing a
character is much larger than the width of the character.  For example, if
you have
  1234567890
on the screen and you wish to overwrite this with "abc" starting at the 1,
you get something like
  abc     90
where about half of the 8 is also visible.  In other words, it is copying
far more than it has to.  This does not make any difference in the modes which
they claim to support.

It would be nice to be able to do a srcCopy.  One possibility would be
(if you have access to assembly language) to patch the offending routine in
RAM.  Another possibility is, if you can keep track of what character is 
already in the position, to write that character in srcXor mode and then 
write the new character.  A third possibility is to do an EraseRect over the
character first, although this is too slow.  If you are using a fixed-width
font, you can keep a blank area the size of a character somewhere and use
CopyBits to blast this over the area before doing a DrawChar.  I am not sure
how MacTerminal handles this problem.  These are only kludges to get around
something which Apple could probably fix.

Incidentally, this bug was first reported on this list in about February
from somebody who was using MS Basic to do graphics.

	--Mark