Take the 2-minute tour ×
Tridion Stack Exchange is a question and answer site for Tridion developers and administrators. It's 100% free, no registration required.

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

original

vs

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?

share|improve this question
    
How are the fonts being loaded in the CSS? –  jarnohenneman Jul 4 at 10:39
    
Is there any error in browser console? –  Raj Kumar Jul 4 at 10:58
    
I've updated my post with more info –  Reinder Wit Jul 4 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 –  jarnohenneman Jul 4 at 20:07
add comment

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

share|improve this answer
    
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.... –  Reinder Wit Jul 4 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... –  Reinder Wit Jul 7 at 14:25
add comment

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)

share|improve this answer
    
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 –  Reinder Wit Jul 4 at 12:26
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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