Icon font with SiteEdit 2009 SP2 Proxy

Question

We have an issue with a custom icon font that we are using in our website, when accessing it through the SiteEdit proxy. This happens in all browsers, the icon just isn't displayed

vs

I've added all the fonts in the MIME types section in IIS and I can also download all the different version of the fonts (EOT, WOFF, SVG and TTF) correctly through the proxy if I point it to the locations of those files.

Net tab in firebug shows no errors, nor does the console panel. All seems well, SiteEdit works as well.

We are using SiteEdit 2009 SP2.

Here's part of the CSS that loads the font:

@font-face {
    font-family: 'OHRAicons';
    src: url('../img/ohraicons.eot?version');
    src: url('../img/ohraicons.eot?version#iefix') format('embedded-opentype'),
        url('../img/ohraicons.woff?version') format('woff'),
        url('../img/ohraicons.ttf?version') format('truetype'),
        url('../img/ohraicons.svg?version') format('svg');
    font-weight: 400;
    font-style: normal;
}
@media screen and (-webkit-min-device-pixel-ratio:0) {
    @font-face {
        font-family: 'OHRAicons';
        src: url('../img/ohraicons.svg?version') format('svg');
    }
}
.ohraicon {
    font-family: 'OHRAicons';
    font-style: normal;
    font-weight: normal;
...

Any suggestions?

Answer 1

It looks to me as though your font is getting used, but is displaying the wrong output. The obvious suspect here is an encoding issue. Are you using UTF8 everywhere? I would suggest checking the configuration of the proxy site, and also the response headers to ensure they are correct. (Presumably in this case, "correct" means "the same as on the live site".)

Answer 2

Can you try by creating a sample HTML and executing on the Server and see if this font loaded or not. If not, can you try by registering the Font Family in OS (or may be if it is already registered, then Un-registering and re-registering it)

Answer 3

tl;dr: ensure that your web server serves a Content-Type header for your custom font.

When you access your web site through the SiteEdit proxy, that proxy potentially parses all textual content for SiteEdit tags. This means that the SiteEdit proxy ends up reading the text that your web site serves and writes it out to the browser. It seems that your text is getting mangled up in this step.

There are two ways that SiteEdit uses to determine the encoding of the response:

1. the SiteEdit proxy parses the HTTP resonse for a Content-Type header with a charset. If such a header is present, SiteEdit uses it to read the text with the correct encoding.
2. If no Content-Type header is present, SiteEdit scans the actual content for a meta tag with the Content-Type. If that is present, SiteEdit will re-start reading the response with the specified encoding.
3. If none of the previous tests result in a different character set, SiteEdit uses ISO-8859-1 to parse the text. To ensure backlash on that choice goes to the correct recipients: ISO-8859-1 is defined as the default charset in the HTTP 1.1 specification.

In the initial release of SiteEdit 2009, only the first and third method were present. I don't recall exactly in what version the meta scanning was implemented, but hopefully the release notes will make mention of it.

Either way: I guess that your web servers serves the font without a Content-Type header and (since it's not HTML) it does not contain a meta equivalent. So SiteEdit ends up parsing it as ISO-8859-1, which maps the bytes to the wrong characters.

The simplest way to solve the problem is to ensure that your web server serves a Content-Type header for your custom font.