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



missing character

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?

  • How are the fonts being loaded in the CSS?
    – user219
    Commented Jul 4, 2014 at 10:39
  • Is there any error in browser console?
    – Raj Kumar
    Commented Jul 4, 2014 at 10:58
  • I've updated my post with more info Commented Jul 4, 2014 at 11:27
  • Sorry, can you see in your css file if there is a decleration of UTF-8 in it ? See w3.org/International/questions/qa-css-charset.en.php
    – user219
    Commented Jul 4, 2014 at 20:07

3 Answers 3


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".)

  • The encoding of the JSP page itself is the same as on the website: UTF-8. I'm looking at the CSS file now, because the icon itself is set using, for instance, '.ohraicon-reisverzekering:before{content:"\e001"}'. I have the feeling this character is rendered incorrectly when publishing the CSS file. I need to look into this a little more.... Commented Jul 4, 2014 at 12:44
  • Somehow, once published, the CSS is already scrambled up with incorrect characters: before{content:""}. Strangeley enough this is not a problem on the website. However it is for the SiteEdit proxy. The CSS file itself is indeed coded in UTF-8, as is the website. There's no separate UTF-8 declaration present in the file. We are using a CSS minifying plugin in our TBB, which seems to replace the "\e001" parts in the CSS with incorrect characters. I have to dive deeper into this... Commented Jul 7, 2014 at 14:25

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)

  • I created a static HTML file on the CMS server, with the custom icon font. I opened the file, both locally and trough the Tridion CMS website: the icon was showing. The icon is also showing for the website itself when accessing it on the test environment. So all looks OK, except when requesting it through the SiteEdit proxy Commented Jul 4, 2014 at 12:26

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.