Maptext wasn't rendering at the correct size in the webclient. Additionally, Dream Seeker also rendered maptext sizes inconsistently.
BYOND Version:507
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 31.0
Applies to:Webclient
Status: Resolved (507.1260)

This issue has been resolved.
Descriptive Problem Summary:
Maptext size is inconsistent in the webclient (though it seems generally smaller than in the dreamseeker).

Screenshot of game in dreamseeker:
Screenshot of game in webclient:

Numbered Steps to Reproduce Problem:
Create an atom with maptext. Set the maptext size using a < font > tag.

Code Snippet (if applicable) to Reproduce Problem:
atom.maptext = "<font size = 0.5> asdf </font>"

Expected Results:
maptext in the dreamseeker and the webclient are somewhat consistent.

Actual Results:
Size of maptext in the webclient is inconsistent and generally unreadable.

Does the problem occur:
Every time? Or how often? Every time
In other games? Yes
In other user accounts? Seems irrelevant
On other computers? Untested

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)
Not applicable

Use dmifonts.
I'll have to check if we are properly mapping all font formats, but you may try specifically using the px format which I believe is the one we translate to natively. I swear I tested all of this but might not have checked the obvious "default" format.
Chrome exhibits the same behavior with maptext in the webclient. Drawn font sizes in Chrome seem to be exactly the same as those in Firefox.
Did you try outputting in different font formats (mainly px or pt)?
Not yet, will get to that next.
I just finished converting between html font tags to css spans for the maptext so that I could test with different font formats.

In the game, the standard font size is 10pt. The smaller size is 8pt, and the larger size is 14pt.

Here are my results:
Dream Seeker -
Webclient -
This might be a problem with how we're choosing the default maptext size. That's taken from the map control itself, which would normally be exactly your default size without changes, if you didn't specify. We might need to include some logic to make it a certain size when not specified, at least in translated skins.
You probably shouldn't be using a deprecated tag like font.
In response to EnigmaticGallivanter
EnigmaticGallivanter wrote:
You probably shouldn't be using a deprecated tag like font.

Don't be a poop. Read my latest comment; I changed the font tags to spans and am still getting the same problem.
We're translating the font tag anyway, so that's not really the issue. Basically DS has a different way of calculating the default size and we want to bring the webclient more in line with expectations.
Tom resolved issue with message:
Text size wasn't rendering properly in the webclient.
I'm still seeing issues with this. The left side is the webclient and the right is DS.

That's a different font, which would account for some of it. The one on the right is the system font MS Sans Serif. The webclient default is to use whatever sans-serif the browser normally uses.

That should be 12pt Comic Sans MS in both of them.
    O.maptext = "<div style='font-size:12pt; font-family:\"Comic Sans MS\"; color:#ff6;'>This should display the same in DS or the webclient</div>"

EDIT: Tested in IE and Chrome and the web client displays the same in both.
Okay, good to know. With the same font I wouldn't expect a size difference like that. Oddly though I'm wondering if DS isn't the one in the wrong.
I will test this out, but to help, can you tell me which font seems more accurate, eg, when comparing to a web-page rendering that same font? My gut feeling is that DS is rendering incorrectly (which would be better IMO if the goal is to faze that out).
Seems that DS is correct.
<div style='font-size:12pt; display: table-cell; vertical-align:bottom; height: 128px; width:128px; background: url(mtback.png); font-family:"Comic Sans MS"; color:#ff6;'>This should display the same in DS or the webclient</div>

produces this which looks just like the DS version above, at least in Chrome on my system.
Ok! We will figure it out.
Off topic, but that HUD is absolutely gorgeous.
On further investigation, I believe this is actually DS's fault.

DS appears to be routinely setting a positive value for lfHeight in its LOGFONT struct for the map, when a negative value is actually correct. (The output control has a whole other behavior because of the way it uses a rich text control, but I'm not too concerned about making sure it conforms.) Correcting this erases the discrepancy between DS and the webclient, and text metrics are lining up perfectly.
Page: 1 2