Fonts are not always added to Windows

ID:1516615
 
Mar 12 2014, 1:59 pm
Resolved
Fonts that were not installed on a user's system, but were included in the resources for the game, did not work properly in all cases. Please note: The solution to this issue makes fonts loaded this way inaccessible to browser controls. However, for browsers it is preferable to use Webfonts anyway.
BYOND Version:504
Operating System:Windows 8 Pro 64-bit
Web Browser:Chrome 33.0.1750.146
Applies to:Dream Seeker
Status: Resolved (506.1247)
This issue has been resolved.
Descriptive Problem Summary:
When running a local world fonts are not always added to Windows, resulting in the wrong font being displayed in browser controls.

Unfortunately I don't know exactly what causes this problem, but I've seen it happen randomly while developing that custom fonts that have been added to the resource file are not available in a browser control, when at other times they're perfectly accessible.

I'm curious how the font system works and if it's actually reliable enough to use.

Expected Results:
When a font is added to the resource file and later encountered by the client it should always be imported in Windows, either temporary or permanently. A font that is in the resource file must be accessible to the game and it must be possible to display it in any skin element.

Actual Results:
The font I've included randomly doesn't show up in my browser control even though the CSS specifies that as the font-family. There seems to be either something different for the browser control or there's a bug with adding fonts to Windows.

Does the problem occur:
Every time? Or how often?
The problem occurs randomly during development. When I start my computer up the font seems to be available, but hours later it could suddenly go missing. A restart will then not import the font making the bug reproducible in that case.

In other games?
I remember this problem occurring before where the entire skin lost its font and reverted back to the default (I think it was Verdana or Arial), and I wasn't sure what the cause of that was either.

In other user accounts?
I'm running Win8 on an administrator account, and to my knowledge I am running no modifications that would account for this problem. I'm the only user of the computer.

On other computers?
It happened before on a Windows XP machine, but since it's happening on a Windows 8 machine now I don't think the problem is OS-related, at least not resolved in Windows so far.

When does the problem NOT occur?
The problem does not occur when I restart my PC and work from scratch. It only seems to occur at some point during development.

Workarounds:
Restarting the entire computer seems to resolve the problem but I can't request players to do this, so there's no feasible workaround for this issue.
Mar 13 2014, 6:45 am
Fonts are added via the AddFontResource() mechanism. I'd prefer to switch over to a memory-based version rather than a file-based version at some point, though for browser controls the lack of availability could strictly be a matter of timing.
Mar 13 2014, 7:26 am (Edited on Mar 13 2014, 7:47 am)
Lummox JR wrote:
though for browser controls the lack of availability could strictly be a matter of timing.

I'd like to chime in here, and point out a few things about browser controls:

1) Browsers do not ensure that files are sent successfully.

2) Browsers do not ensure that verbs are accessible before calling them.


In my environment, I find that calling a verb via a javascript winset can result in an inaccessible verb immediately after player login. I've been unsuccessful so far on actually finding a way to detect when a winset verb call has failed, and refire it --without implementing callbacks.

In addition, I've been unsucessful at figuring out exactly why files sometiles fail to update and send to the browser.

The best way I've found of ensuring that a browse() command is successful is something like this:

//snipped from a sort of browser control datum structure.
var
    client/client
    __waiting
Topic(href,href_list[])
    if(__waiting)
        __waiting = 0
proc
    __initial_message(file,browser)
        set waitfor = 0
        __waiting = 1
        var/resend = 0
        var/count = 0
        while(__waiting)
            count = 0
            src.client << browse(file,"window=[browser];display=1")
            while(__waiting && count < 10)
                count++
                src.client << output("\ref[src];","[browsername]:initialize")
                sleep(5)
            if(__waiting)
                resend++
                if(resend==5)
                    __debug_message("catastrophic failure!")
                    return
        __debug_message("successful after [10*resend+count] attempts!")


And my initialization routine is something like this in Javascript:

var __src = null;
var pageloaded = false;

function loadPage()
{
    //perform page initialization
    pageloaded = true;
}

window.onload=loadPage;

function initialize(link)
{
    if(pageloaded==false) return;
    if(__src!==null) return;
    __src = link+";";
    window.location = "byond://?src=" + __src + "action=confirm";
    //perform post-connection initialization. Should be relatively safe to communicate back home now.
}


Unfortunately, I'm not sure how to ensure that the page's required resources wind up downstream. Sometimes, when sending a file that's already in the player's cache, the entire browse function fails completely. After using a structure like the above, though, I find that I have about a 98% success rate until I start working with winsets and verbs. I need to work out some method of ensuring the interface and verbs have been communicated fully by the time the browser loads, and I think I'll need to implement some kind of a callback structure to do that.
Mar 14 2014, 8:22 pm
Descriptive Problem Summary:
.ttf files successfully loaded into the rsc only seem to work once.

Numbered Steps to Reproduce Problem:/Code Snippet (if applicable) to Reproduce Problem:
Use/reference the file via:

var/list/font_rsc = list('font/Signature.ttf')
"<font face='Signature'>text</font>"


Works once then never again.


Does the problem occur:
Every time? Or how often? Every time after the first.

When does the problem NOT occur? First time.

Workarounds: None.

Mar 14 2014, 8:41 pm
In response to Jittai
I have the same problem listed above on both windows 7 and windows 8.1. Byond Version 506.1236 Beta

The first time it shows up, and every time after that it does not show up. My output pane also generates a weird background image used in another part of the interface.
Mar 15 2014, 11:23 pm
In response to Jittai
This issue looks like a duplicate of id:1516615.
Mar 16 2014, 9:23 am
In response to Jittai
Just for the record, mine isn't just with browser controls. It's also with maptext.
Mar 19 2014, 9:16 pm
Wasn't aware it also happened with maptext. The current project I'm helping on uses browsers. Kind of a shame custom fonts can't be used with maptext either though.
Apr 2 2014, 1:33 pm
Dang. My solution for this turns out to be a problem for browser controls. I got this working for general use, but embedded browsers can't use the font because it can't be enumerated when AddFontMemResourceEx() is used.

The dilemma I'm left with is if I should switch to this format anyway and say screw the browser (there are other ways to embed fonts there), because it'll make inline fonts way more stable, or if we should stick with the current, kind of iffy method.
Apr 2 2014, 1:38 pm
In response to Lummox JR
Lummox JR wrote:
Dang. My solution for this turns out to be a problem for browser controls. I got this working for general use, but embedded browsers can't use the font because it can't be enumerated when AddFontMemResourceEx() is used.

The dilemma I'm left with is if I should switch to this format anyway and say screw the browser (there are other ways to embed fonts there), because it'll make inline fonts way more stable, or if we should stick with the current, kind of iffy method.

I think we should go with the method that's most stable. If we need to use another method for browser controls we can always find a workaround. This way almost everything can use fonts and have it be consistent.
May 14 2014, 6:41 am
Stephen001 changed status to 'Verified'
May 14 2014, 12:55 pm
Lummox JR resolved issue with message:
Fonts that were not installed on a user's system, but were included in the resources for the game, did not work properly in all cases. Please note: The solution to this issue makes fonts loaded this way inaccessible to browser controls. However, for browsers it is preferable to use Webfonts anyway.