textSize resets textHeight

[monte]

Code: Select all

// MW-2012-02-19: [[ SplitTextAttrs ]] If the textSize is changed, then make sure we
			//   reset the textHeight to derive from it.
			if (which == P_TEXT_SIZE)
				fontheight = 0;

This doesn't seem right to me. If we must do this couldn't we reset the textHeight to what it was at the end?

[mwieder]

Well, that's only if you're setting the textSize. My guess from the context in objectprops.cpp is that setting the fontheight to zero forces the following recomputefonts() to make sure that all the dependent objects do the right thing. Does a fontheight of zero mean "inherit"?

[monte]

I haven't followed this all the way to where the textHeight is reset but if your textHeight is 40 and you change the textSize to 12 it will reset the textHeight to 16.

[mwieder]

Yes. It's documented that way::

Note: If you change the field's textSize, LiveCode automatically sets the textHeight to trunc(4/3 * the textSize of field). For example, if the textSize is set to 12, the textHeight is set to 16 by default. If the textSize is set to 14, the textHeight is set to 18. So, if you want to change the textHeight and textSize, set the textSize first, then set the textHeight.

If a field's fixedLineHeight property is false, the textHeight of the field has no effect: in this case, the text height of each line is determined by the size of the largest text in the line, and changing the textHeight doesn't change the spacing of lines.

[monte]

OK, looks like I'd better set textSize first when setting the properties too otherwise the textHeight could be overridden. I can't see why the textHeight can't be reset at the end but I guess lots of people would rely on this now...

[mwieder]

I think the default case is that people would expect that adjusting the textSize would adjust the line spacing accordingly.
The downside is having to do things in order: textSize first, then textHeight.

[monte]

I guess so... maybe if the textHeight is non-standard it could behave differently...

[LCMark]

This is one of those cases of 'this is how it has always been' and I can only conjecture on the underlying logic...

The textHeight only has an affect if 'the fixedLineHeight' of the field is true and I guess it was considered 'jarring' to set the textSize and then get strange spacing even if the textHeight had been explicitly set.

Ideally the 'textHeight' should be able to be set to either:

• a) an absolute value (in which case setting the textSize should not have any effect on it)

• b) a relative percentage or ratio (in which case setting the textSize would cause it to recalculate in the way the scripter wants)

Indeed, being able to do this more generally with textSize (and other field props) might be quite a nice addition

[monte]

Hmm... It is a funny one. In my mind if we have a property named fixedLineHeight true and setting another property causes the line height to change then it's a bug... But I guess you're right that it's probably in the too hard to change basket... It would seem quirky to have another property to make sure the fixedLineHeight actually stays fixed... we could call it reallyFixingTheLineHeightThisTime

I'm not sure I understand what you are suggesting with the more general approach. What other properties would have this percentage/absolute kind of option?

[LCMark]

Oh I'm not saying there isn't somewhat distinctly dodgy logic in my supposition above - however I didn't design the current functionality, I'm just trying to suggest some reason it was done that way

What I'm suggesting is that it would be cool if you could do (in addition to absolutes):

Code: Select all

set the textSize of control 3 to "30%"
set the textHeight of field 5 to "150%"
set the spaceAbove of line 5 of field 3 to "200%"

Here 'control 3' would have 30% of the textSize of the inherited property, and the textHeight of field 5 would always be 1.5 times the textSize.

[mwieder]

What I'd really like there (someday in the far future) is the ability to use standard css files.

[mwieder]

This is one of those cases of 'this is how it has always been' and I can only conjecture on the underlying logic...

I don't really see much of a conflict here.
If the field has a fixed line height (meaning that all the lines have the same height rather than each line's height being a specific size) then changing the textSize should indeed change the height of the individual lines to prevent clipping.

What's missing is a way to specify a fixed line height separate from the text height.

[monte]

Ah.. I understand what your intention is now @runrevmark. So we would be able to continue to use inheritance and these percentages would be relative to the effective textSize... cool. Change the text size in the stack and it cascades down... much simpler for maintenance or to provide flexible text size stacks.