Telnet and TrueTypeTextStyle

Yoshiki.Ohshima at acm.org Yoshiki.Ohshima at acm.org
Mon May 12 08:44:12 UTC 2003


  Hello,

> It's in the Telnet package.  I'm probably one of the few people who
> has it loaded in a Windows image along with TrueTypeTextStyle.

  I haven't... I guess I should do more thorough test with the SM
package.

> >   Also, the right thing to do in the future for a method like
> > #widthOf: would be to get aString, instead of aCharacter as argument.
> 
> There's AbstractFont>>widthOfString:.  Is asking a font how much space
> its representation of a character needs fundamentally incorrect?

  The assumption behind it is that the width of a "character" stays
same wherever it is.  Some characters in some languages change its
"width" based on the characters around it.  I can't give you the exact
example, now, but as far as I heard there is an example as below:

  a _ charA.
  b _ charB.
  c _ charC.
  (widthOf: a) + (widthOf: b) > (widthOfString: (String with: a with: b with: c))
  "=> true"

where charA, charB, and charC are some characters.

> I guess you say this for the same reason you comment on #widthOf: and
> since I don't understand that, I don't understand this.  Usually I am
> a mere font user, and that only as a reader, but I had just run into
> the Telnet/TrueTypeTextStyle package conflict when Diego asked about
> #maxWidth.

  Oh, that is fine.  If the application doesn't have to handle any
exotic characters, don't worry about it too much.

  #isMonospace can be read as something like #isUsableForTelnet, and
an implementor can simply return false if there is some doubt.  The
escape sequence interpretation requires some limitation anyway.

  In #maxWidth case, a font instance still could return a value;
however, the value itself is usually useless any precise sense.  In
Connectors example, it actually doesn't have to be 'max' width at all.
One way to determine the default width is to use the width of default
string ('Default Label' or something).

-- Yoshiki



More information about the Squeak-dev mailing list