ID:2563917
 
Resolved
MeasureText() returned incorrect values for maptext beginning with an HTML entity such as >.
BYOND Version:513.1510
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 81.0.4044.113
Applies to:Dream Seeker
Status: Resolved (513.1519)

This issue has been resolved.
Descriptive Problem Summary:
The MeasureText proc will return a zero height value if text being measured leads with a HTML encoded angle brace. (>)

Numbered Steps to Reproduce Problem:
1. MeasureText with a leading encoded > (see below) with a pre-set width of 96 pixels
2. The returned height is zero (specifically returns "96x0")

Code Snippet (if applicable) to Reproduce Problem:
var/wxh = client.MeasureText("<span class='center maptext'>&gt; test</span>", null, 96)
var/h = text2num(copytext(wxh, findtextEx(wxh, "x") + 1))


Expected Results:
Return a non-zero value

Actual Results:
Returns a zero

Does the problem occur:
Every time? Or how often? Every time.
In other games? n/a, didn't test
In other user accounts? n/a, didn't test
On other computers? n/a, didn't test

When does the problem NOT occur?
When measuring a string that doesn't start with a HTML-encoded right-angle brace with the exact same classes and styling.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
n/a

Workarounds:
Swap out the problematic encoded character for temporary characters to measure, or to assume some minimum height.
I have verified that this appears to happen with html-encoded left angle brackets as well. I would take a guess to assume metacharacters in general cause measuring to fail.
Lummox JR resolved issue with message:
MeasureText() returned incorrect values for maptext beginning with an HTML entity such as &gt;.
This was a weird one. I'm not sure why it was breaking but I managed to fix it more or less by accident over the course of investigating the problem. A big part of this appeared to be that an empty string was being sent to the maptext output manager and that was somehow messing up the display driver's font info.