Hi,

I left town rather suddenly just after I posted addHorzScrollbar. I just 
got back into town and saw this message, sorry for the delay.

Adding the ability to measure text width to the Font hierarchy looks 
like it might be a bit of work to do properly. First, you need to break 
the text up into its runs, and get the width of each (not too hard). 
Second, a  refactoring of the 'widthOfString:' methods in the 
AbtractFont hierarchy would be required in order to take emphasis into 
account. This looks, at first glance, non-trivial, and might be a 
potential source of bugs in a very critical piece of code.

I wonder if the suggested fix of just converting to String might be 
acceptable for the moment. It's easy to get a result that is very close 
  most of the time, it's fast, and it's unlikely to add any bugs. Once 
addHorzScrollbar is shown to be rock solid, then we could go for a more 
precise width for Text objects. A proposed patch is shown below.

Thanks, Steve S.

=== Eg. tmp fix to AbstractFont>>widthOfString:====

AbstractFont>>widthOfStringOrText: aStringOrText
	aStringOrText ifNil:[^0].
	^aStringOrText isText
		ifTrue:[self approxWidthOfText: aStringOrText ]
		ifFalse:[self widthOfString: aStringOrText ]

AbstractFont>>approxWidthOfText: aText
	| w |
	
	(aText isNil or: [aText size == 0 ])
		ifTrue:[^0].
		
	w _ self
		widthOfString: aText asString
		from: 1
		to: aText size.

	"If the text has no emphasis, just return the string size.
	If it is empasized, just approximate the width by adding
	20% or so to the width"	
	(((aText runLengthFor: 1) == aText size)
		and: [(aText emphasisAt: 1) == 0 ])
			ifTrue:[^w]
			ifFalse:[ ^w * 6 // 5 ].


====== End of proposed temp fix ===

Doug Way wrote:
> 
> Avi Bryant wrote:
> 
>> If a PluggableListMorph is given a styled item with the 
>> addHorzScrollbar changeset loaded, the Text object will eventually get 
>> given to AbstractFont>>widthOfString:, which doesn't know how to deal 
>> with it.  I'm not sure who is at fault here (should #widthOfString: be 
>> able to deal with Text?  Should it make sure to convert its argument 
>> to a string first?  Should the PLM be converting its items to strings 
>> before asking about their widths?  Should my code not be giving a Text 
>> item to a PLM?).
>>
>> Full debug log is attached. 
> 
> 
> 
> For what it's worth, I ran into the same problem.  If we could get this 
> resolved, it'd be great to get the addHorzScrollbar changeset 
> incorporated into 3.7.  Other than this problem, it looked pretty good.
> 
> Offhand, it seems reasonable that AbstractFont should know how to 
> compute the width of some styled text.  (Converting to a String ahead of 
> time wouldn't be ideal because bold text is often wider than non-bold 
> text, for example.)  The only problem then is that the method should be 
> renamed to widthOfStringOrText:, or something like that.
> 
> - Doug
> 
>