There are a few threads available on the web with regard to how to test if a font is installed on a client machine, but I'm not satisfied with any of those that I found. The reason being that they each seem to use a single common font as a baseline measurement and compare the dimensions of some reasonably complex string rendered in the common font against the same string rendered in the test font.

This irks me for a number of reasons:

1. It assumes the common font is installed
2. It only confirms the dimensions of the tested font don't coincide with the common font
3. All of those I saw rerendered the same element over and over, triggering an unnecessary number of reflows

If you want to check if a font is installed, start with a provable test. The system default monospace font should render a string in different dimensions than the system default sans-serif font. But you can test this.

(function () {
var div = document.createElement('div'),
    different = false;

div.innerHTML = '<span style="...;font-family: sans-serif">some string</span>' +
                '<span style="...;font-family: monospace">some string</span>';

document.body.insertBefore(div, document.body.firstChild);

different = div.childNodes[0].offsetWidth != div.childNodes[1].offsetWidth;

document.body.removeChild(div);

alert(different);
})();

Using this tested assertion as a baseline, let the browser tell you if the test font is installed by using the default behavior of font stacks. Create two elements with the same content ("ii" has been sufficient in my tests), each styled with a font-family of the test font followed respectively by the two control fonts that you know to render to different dimensions.

<b style="font: normal 10px/1 'FONT_X', sans-serif !important">ii</b>
<b style="font: normal 10px/1 'FONT_X', monospace !important">ii</b>

The two elements will render to the same dimensions if and only if the the font is installed.

Here's my approach:

function testFont(name) {
    name = name.replace(/['"<>]/g,'');

    var body  = document.body,
        test  = document.createElement('div'),
        installed = false,
        template =
            '<b style="display:inline !important; width:auto !important; font:normal 10px/1 \'X\',sans-serif !important">ii</b>'+
            '<b style="display:inline !important; width:auto !important; font:normal 10px/1 \'X\',monospace !important">ii</b>',
        ab;

    if (name) {
        test.innerHTML = template.replace(/X/g, name);

        test.style.cssText = 'position: absolute; visibility: hidden; display: block !important';

        body.insertBefore(test, body.firstChild);

        ab = test.getElementsByTagName('b');

        installed = ab[0].offsetWidth === ab[1].offsetWidth;

        body.removeChild(test);
    }

    return installed;
}

The code above assumes the string "ii" renders to different width in monospace than sans-serif, but the important part is that this can be tested if you don't feel comfortable with that assumption. Additionally, containing two elements in an absolutely positioned div should limit the scope of the two requisite reflows if the browser is smart about it.

If you want to test more fonts, create more template entries in the innerHTML all at once before attaching the div to the DOM, then just loop through the entry pairs. This will preserve the two reflow impact.

Here's a test page.

And here's the code in a GitHub gist. It's likely this is more up to date than the snippet above.

I'm a big fan of the Factory/Constructor pattern in JavaScript.

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    // the rest of your initialization code
}

Foo.prototype = { ... };

var f1 = new Foo(), // f1 instanceof Foo === true
    f2 = Foo(); // f2 instanceof Foo === true

But this runs into a problem when you want your constructor to accept any number of arguments.

Function Person(mother, father) {
    this.mother = mother;
    this.father = father;
    this.children = [].slice.call(arguments,2);
}

Apply invocation vs Constructor invocation

Unfortunately, you would need to invoke the constructor via Person.apply(arguments) to pass all the arguments in individually, but that doesn't create an instance of Person since it wasn't called via new. You can get around this by referring to a local variable in your constructor that is either this or a new empty instance, then applying the changes to whatever is in the variable and returning it.

Function Person(mother, father) {
    var self = (this instanceof Person) ? this : new Person();

    self.mother = mother;
    self.father = father;
    self.children = [].slice.call(arguments,2);

    return self; // important
}

When a constructor returns an object, the return statement is honored over the default behavior (sans return statement) of returning a class instance.

But this doesn't pan out if it is inappropriate for the class to be called without arguments or if there's some complex logic that needs the seed info in order to make sense.

Quite a list of requirements

Now, at this point any reasonable person would probably rethink the architecture that necessitated such a construct (seriously, is it really a requirement to also support function invocation?), but a) I'm not a reasonable person, and b) hey, fun with code! So here goes.

Circling back to the point that returning an object from a constructor will trump the default behavior, we can just defer the construction behavior to another constructor function.

function Person(mother, father) {
    return new _Person(arguments);
}

function _Person(_) {
    this.mother = _.shift();
    this.father = _.shift();
    this.children = _;
}

Now it doesn't matter how you execute the Person function. It will return an instance of _Person, which is set up with the initialization code in its constructor.

But I didn't ask for a _Person

Now there are two things left to attend to: 1) the returned object isn't an instance of Person, and 2) we now have two constructor functions exposed to our consumers.

var Person = (function () {
    function C(mother, father) {
        return new _Person(arguments);
    }
    function _Person(_) {
        this.mother = _.shift();
        this.father = _.shift();
        this.children = _;
    }

    C.prototype = _Person.prototype = { ... };

    return C;
})();

Assigning _Person's prototype to C (aka Person) makes instances pass the instanceof test and allows for modifying the class prototype with the expected outcome. And defining the helper constructor in a closure hides it from the implementation layer.

Overkill? Almost certainly. But JavaScript is a fun language, and who knows? Maybe this pattern is just the right thing for some use case out there. Ok, maybe not :)