Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!brian
From: brian@ut-sally.UUCP (Brian H. Powell)
Newsgroups: comp.sys.mac
Subject: Re: tabs in textedit
Summary: What Apple told me...
Keywords: tabs textedit
Message-ID: <10067@ut-sally.UUCP>
Date: 13 Jan 88 02:35:59 GMT
References: <1860@orstcs.CS.ORST.EDU>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 69

In article <1860@orstcs.CS.ORST.EDU>, mjbo@mist.cs.orst.edu (Mark Borgerson) writes:
> I also saw  something on the net to the effect that
> modifying textedit  to support tabs was verboten. 
> There is nothing to this effect in the latest 
> compatibility guidelines.  Am I doomed to failure
> or what?

     I was the person who posted some information to the net about adding tabs
to TextEdit a few months ago.  At the time I was working on it, I sent mail to
Apple asking them to clarify some of the issues involved with TextEdit.  I got
a letter from Cameron Birse, which said, in part,

	It wasn't entirely clear to me what exactly you meant with your
	StdText and StdTxMeas calls, but I can say that things not only can
	change in future ROMs, but probably will.  For example, the new
	TextEdit routines allow for styled text (i.e., bold, italic, etc.),
	which obviously complicates measuring text.  The point is, the only
	things you can depend on being supported in future revisions of ROMs
	are things that are clearly documented in Inside Macintosh Volumes
	1-5.

     Let me say that first of all, the MacTutor article included some very
questionable code which I'm sure has failed on SEs and IIs.  When I wrote code
to support tabs, I made some restrictions (in particular, I don't allow
word-wrapping) that let me throw out much of the "dangerous" code from the
MacTutor article.  Also, I didn't use the "new" TextEdit; I'm using the "old"
TextEdit that only supports one typeface.
     I also had to make some assumptions.  Here is what I said in the original
article I posted:
			     ********************
     In particular, my code depends on two things:
	* That when tabTxMeas and tabText are called, they get pointers into
the actual TextEdit text.  This is so they can poke around in neighboring text
to find out where the beginning of the line is.  If TextEdit ever decides to
measure text by copying it into a buffer, then measuring it, these routines
will return funny values.
	* That TextEdit will never use the values returned by numer, denom and
info after tabTxMeas has been called to measure a line consisting only of
tabs.  Currently, TextEdit sets up its variables (such as
te_handle^^.lineHeight) during TENew by calling GetFontInfo, which calls
tabTxMeas with byteCount == textAddr == 0.  If tabTxMeas is ever called to
measure a line consisting only of tabs, it figures out the width of the text
on its own and never calls StdTxMeas.  Therefore, numer, denom and info aren't
touched.  This isn't hard to change if you feel uncomfortable with it.  I'd
suggest initially calling StdTxMeas with count == 0.  Then if tabTxMeas' input
parameter byteCount was also zero, tabTxMeas can return zero safely, else do
all the work.  (Maybe I'll change this in my program, too.)
			     ********************

     As I said at the time, it would be pretty stupid if Apple were to change
TextEdit to invalidate my above assumptions.  It would imply that they were
throwing away a lot of useful information in their TERecord and recomputing it
each time.
     If you did anything similar to what I did, then I suggest two things:
	Don't call CharWidth.  (It's obvious why not if you think about it.)
	Check to make sure that my first assumption holds on calls to the
	 bottlenecks.  That's the most likely place for something to mess up.

     I'll try my code on a Mac II tomorrow or Thursday and let you know if it
works.  If you'd like, I could send you my original posting when I worked on
it.

Brian H. Powell
		UUCP:	...!uunet!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU

		P.O. Box 5899
		Austin, TX 78763-5899
		(512) 346-0835