Volume Number: 13 (1997)
Issue Number: 4
Column Tag: Programming Techniques

Transmuting Text

By Martin Frické, Tucson, Arizona

Seemlessly exchanging text labels and editable text objects

One common problem with diagrams and intricate dialogs is that there are often many separate editable text items that have a small storage overhead relative to their own data content. For example, the user may want to label the four corners of a square; each label editable and most labels, but perhaps not all, consist of only a few characters in one style. A problem arises in that the data-structures to support style and styled-editing are reasonably substantial.

For example, the Mac TERec is 96 bytes large compared with one byte to represent the single character that is actually on one of the corners of the drawn square. If a single body of text is large, the supporting style data-structures are insignificant, but with a multiplicity of small labels in a diagram, the content can easily get swamped by the support - as much as 200k can be used for one page of symbols. On the other hand, if the program considers a label to be just a string of characters, the label can be stored frugally and drawn easily, but it would not be as easily editable.

Many commercial programs do not fare terribly well with this problem (no names, no pack drill). There are a few standard techniques. Several painting programs use once-only editing. A new label is editable, but the moment that new label is de-activated, the text in it is converted into a bit-map and merged into the background. Therefore, this label cannot be recovered back into text and edited again. Other programs use a string to represent an individual small text item, then they float editable text over the top of the single active item. This can work, but conceptually it is pretty unattractive and often aligning the floater and the background string can be awkward.

We are obviously going to use objects as far as we can. What is required most often are string objects for the individual small text items. However, at most there will be one editable text, so this will be an editable text object, and any of the string objects can assume this role. What is needed are transmuting objects.

There are to be many string objects, and at most, one of these may be transmuted back and forth to an editable text object as required. The time to transmute is clearly on activation and de-activation, since there is only one editable text at a time (the active one). The only other property required of the objects is the ability to draw themselves, especially when inactive, as might occur during an update. Care must be taken over the drawing, because the pen may have to produce and match exactly the same result when drawing either version of a transmuted object.

Transmutation here amounts to replacing one object with another - perhaps creating one and deleting the other. You would not want to do this with an object that is referred to by other parts of the program, for that might leave dangling references. Caution suggests hiding the transmuted object within a public object - all public references will then be to the public object.

It may be that the editing by the user makes what formerly was a simple label into complex styled text (maybe akin to the opening page of a King James Bible), in which case, the text is not transmuted back to a string on de-activation. Another decision concerns a default style for the labels - each label can have its own, or there could be a global style. The choice is left to the designing programmer.

The code uses Marco Piovanelli's WASTE styled-text engine http://cirrus.sprl.umich.edu/waste/. In a perfect world the code looks something like the following.

class TText : public CAbstractText
    // Abstract text supplies all the other methods
 {
 private:
 TPrivateText  *fInternalText;
 public:
 void   ActivateText (Boolean OnOff);
 void   Compact();
 void   UnCompact();
 virtual void    Update(RgnHandle updateRgn);
 }

void TText::ActivateText (Boolean OnOff)
 {
 if (OnOff)
 {
 UnCompact();    // transmutes from a string, if needed
 FocusToDraw();
 fInternalText->Activate(true);
 }
 else
 {
 FocusToDraw();
 fInternalText->Activate(false);
 Compact(); // attempts to transmute into a string
 }
 }

void TText::Compact()
 {
 Handle itsText;
 TInternalText *newText;
 Point itsPenStart;
 
 if (fInternalText->CanCompact())  {
 itsText= fInternalText->GetText();
 itsPenStart= fInternalText->GetPenStart();
 newText= new TString(itsText,itsPenStart);
 delete fInternalText;
 fInternalText=newText;
 }
 }

void TText::UnCompact()
 {
 Handle itsText;
 TInternalText *newText;
 
 if (fInternalText->CanExpand())   {
 itsText= fInternalText->GetText();
 newText= new TStyledText(itsText);
 delete fInternalText;
 fInternalText=newText;
 }
 }

void TText::Update(RgnHandle updateRgn)
 {
 
 if (RectInRgn(&fBoundingBox, updateRgn))
 {
 FocusToDraw();
 Frame();
 fInternalText->Update(updateRgn);
 }
 } 


class TInternalText  // important fields and methods only
 {
 virtual void    ActivateText (Boolean OnOff) {;};
 virtual Boolean CanCompact() {return false};
 virtual Boolean CanExpand() {return false};
 virtual Handle  GetText();
 virtual Point   GetPenStart(){return PointOf(0,0)};
 virtual void    SetPenStart(Point aStart){;};
 virtual void    Update(RgnHandle updateRgn);
 }

class TString  : public TInternalText
    // important fields and methods only          
 {
 Handle fText;
 Point fPenStart;

 Boolean  CanExpand() {return true};
 Handle GetText() {return fText};
 void   SetPenStart(Point aStart){fPenStart=aStart};
 void   Update(RgnHandle updateRgn);
 }

class TStyledText: public TInternalText
    // important fields and methods only 
 {
 void   ActivateText (Boolean OnOff);
 Boolean  CanCompact();
 virtual Point GetPenStart(){return PointOf(0,0)};
 Handle GetText();
 void   Update(RgnHandle updateRgn);
 }


void TString::Update(RgnHandle updateRgn)
 {
 MoveTo(fPenStart.h,fPenStart.v);
 HLock(fText);   
 DrawText( *fText, 0, GetHandleSize (fText) ); // Toolbox Routine           HUnlock( 
fText );
 }


Boolean TStyledText::CanCompact()
 {
 long oldStart,oldEnd,length;
 long kMaxString=999;
 SignedByte alignment;
 Boolean canDo=false;
 
 length= WEGetTextLength(fMacWE);
 
 WEGetSelection(&oldStart,&oldEnd,fMacWE);
 
 if ((oldEnd-oldStart)<kMaxString) // not too long
 {
 WESetSelection(0,kMaxString,fMacWE);
 
 mode = doFont + doFace + doSize + doColor;
 
 alignment=WEGetAlignment(fMacWE);
 
    // one style
 if ((WEContinuousStyle(&mode, &aStyle, fMacWE)) &&
    // one line
 (WEOffsetToLine(kMaxString, fMacWE)==0) &&  
    // no fancy alignment
 ((alignment== weFlushLeft)
 || (alignment== weFlushDefault))  
 )
 canDo=true;
 
 WESetSelection(oldStart,oldEnd,fMacWE);
 }
else
 return canDo    
 }

Point TStyledText::GetPenStart()
 {
 Point penStart;
 short lineAscent,lineDescent;
 LongRect destRect;
 
 WEGetDestRect(&destRect,fMacWE);  
 
 penStart.h=destRect.left;
 
 _WECalcHeights(0, 1, &lineAscent, &lineDescent, fMacWE);
 
 penStart.v= destRect.top+lineAscent;
 
 return
 penStart
 }

void TStyledText::Update(RgnHandle updateRgn)
 {
 WEUpdate(updateRgn, fMacWE); // passed to the styled text engine
 }

Unfortunately, the real world forced some modifications to this code. The Macintosh styled-text engine and the WASTE styled-text engine were not originally written as objects. They could have been given a wrapper to make them into objects, but normally they are used as Handles to records. This is not much different from Handles to objects. In the practical implementation the internal private text objects are not used. Instead, the fInternalText field is either just a Handle directly to a WASTE record or a handle to the raw text. Strictly speaking, the text transmutes a Handle based internal data structure rather than a Handle based internal object. However, it does work perfectly to produce results like the following sequence.

Figure 1. The top label is active editable text.

Figure 2. Some of the text is obscured (to demonstrate that the drawing routines mesh properly).

At this point, both labels are strings. The first several letters of the top label have been drawn by the text drawing routine.

Figure 3. Text is redrawn by string drawinf routine.

If we move the the obscuring window to one side (Figure 3) we notice that the half ‘e' and the ‘xt' in the top label are drawn perfectly by the string drawing routine and the mesh of half-a-text-draw and half-a-string-draw is exact.

Next, the document and the top label is activated and the ‘xt' changed to Chicago 18. This makes the label styled text, which will not transmute. The text is obscured again. Remove the obscuring window, and there is a perfect redraw of the top label (as styled text) and the bottom label (as a string). (See Figure 4.)

Figure 4. Obscured styled-text redrawn.

Similarly, the document and the bottom label can be activated, the bottom label made into styled text, and the obscuring sequence repeated.

A sceptic might say that the drawing routines here and the end results are visually indistinguishable from one another - how do we know that all this transmutation is actually happening? To see that the code was working properly, a single debugging SysBeep(5) is enclosed with the string drawing routine, and a double SysBeep(5) with the text drawing routine - you can hear the Updates.