info-mac@uw-beaver (info-mac) (10/24/84)
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
info-mac@uw-beaver (info-mac) (10/24/84)
From: winkler@harvard.ARPA (Dan Winkler)
We went through this a few months ago. Here's a reprint:
From PATTERMANN@SUMEX-AIM.ARPA Mon Jul 16 21:56:45 1984
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Sun 15 Jul 84 21:32:36-PDT
Date: Sun, 15 Jul 84 21:36:43 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: quickdraw glitch when drawing text in srcCopy mode
Resent-Date: Mon 16 Jul 84 09:30:44-PDT
Resent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
Resent-To: ;@info-mac
Status: R
Date: Sat, 14 Jul 84 17:52:08 edt
From: winkler@harvard.ARPA (Dan Winkler)
The DrawChar and DrawString procedures draw several extra spaces after
the char or string they're supposed to draw when the TextMode is
something other than srcOr, like srcCopy, and the background is
something other than white, like gray. Here is a short program that
demonstrates the problem:
#include "mac/quickdraw.h"
struct QDVar QDVar ;
main()
{
int delay ;
QD = & QDVar ; InitGraf( & thePort ) ; InitFonts() ; InitWindows() ;
FillRect(&thePort->portBits.bounds, &(QD->gray)); TextMode ( srcCopy ) ;
MoveTo ( 50, 50 ) ; DrawChar ('A') ;
MoveTo ( 50, 70 ) ; DrawString ("Test") ;
for ( delay = 0 ; delay < 100000 ; delay ++ ) ; ExitToShell() ;
}
From: winkler@harvard.ARPA (Dan Winkler)
Subject: the answer
I took this question directly to the man who should know. "Sorry about
that" said Bill Atkinson. I told him it was ok.
SrcCopy is not a fully supported mode for text, he explained, because
of problems that arise with kerning and italics. For example, in the
string "Jeff", the tail of the first f could curve under and clobber
the corner of the e. So if you want to draw text in copy mode, you
should erase the rectangle that bounds it and then draw it using or
mode. But text drawing using or mode is so highly optimized in
QuickDraw, he said, that this is still about as fast as a fully
supported copy mode could ever be. The amount of white space you see
after a character when drawing in srcCopy mode is, by the way, just the
amount you need to account for the worst possible slant of an italic
character.
Dan.info-mac@uw-beaver (info-mac) (10/26/84)
From: Reed.SoftArts@MIT-MULTICS.ARPA
Local: Mark H. Nodine <mnodine at BBNH>,Thomas.Newton at
CMU-CS-SPICE,info-mac at SUMEX-AIM,mnodine at BBNH
Original-Date: 24 OCT 1984 07:16:32
Resent-Date: Thu 25 Oct 84 16:53:45-PDT
Resent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
Resent-To: ;@info-mac
If you read the Inside Mac doc carefully, srcCopy for text is
not documented to work. ANd erase rect is very fast (why
should it be slow?) THe proposal to copy a blank rectangle on
to the screen instead of the erase rectangle call is presumably
slower than erase rectangel followed by or'ing the char in.
In any case, srcOr is almost always the rigth thing except for
people who grew up thinking like vt100's--if you are putting
text on a screen, what if there are overstrikes or other
effects that seem natural in a pen and ink environment? Even
typewriters require an erase before retyping.info-mac@uw-beaver (info-mac) (10/26/84)
From: Reed.SoftArts@MIT-MULTICS.ARPA Local: Thomas.Newton at CMU-CS-SPICE,info-mac at SUMEX-AIM Original-Date: 24 OCT 1984 17:03:52 Resent-Date: Thu 25 Oct 84 16:53:47-PDT Resent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> Resent-To: ;@info-mac Not to quibble, but what would srcCopy mode mean in Text calls? How much of the bounding box would be blanked? If there is intercharacter spacing that is not present in the font (presumably compressed out, a la the Xerox Strike format) would that not be obliterated? I agree that graphics packages should be general, but that doesn't mean a mode that doesn't make sense should be implemented? If I were to define srcCopy, I might want it to blank only the interior of letters (who says that characters are in bounding RECTANGLES anyway) or just within the tightest convex polygon, or in a rectangle that just barely enclosed the black bits of each character. As I said in previous mail, the idea that monospacing crts without overstrikes are sacred cows shows the tendency of many programmers (not all, thank god) to be obsessive compulsive neurotics.
info-mac@uw-beaver (info-mac) (10/28/84)
From: Thomas.Newton@cmu-cs-spice.arpa
After looking at the Technical Appendix to the MacPascal Reference Manual,
I am more than a little disturbed. It claims that the only modes which are
supported for text drawing are srcOr, srcXOr, and srcBic.
I realize that these three modes are the ones that can be implemented most
efficiently (you can do ByteBlt or WordBlt instead of BitBlt by padding the
bit pattern with zeros, which won't have any effect on the screen). I also
remember some quote in Byte to the effect that "OR mode is used 90 percent
of the time, so it is about twice as fast as the other text modes".
On the other hand, a good graphics package should be *general*. If I want
to draw text in one of the other modes (I'm especially thinking of srcCopy),
I should be able to do so with no penalty other than a loss of speed because
transfers now must be done at a BitBlt level.
Does anyone know whether the {srcOr, scrXOr, srcBic} restriction is just a
recommendation based on efficiency, or a real limitation of Quickdraw?