Debugging a Web Type Font Served from a Different Domain

A client came up with a type face that she found on some site. The supplied file type was .ttf (truetype).

Because I treat my public_html folder as source code, I always keep a third level domain for static file server, eg,, to hold files that need to be directly served. I expect that this might have worked more easily if I had been able to/chosen to serve the type file from the site's public_html folder instead of the different domain.

I put the .ttf on the static domain and added this coding to the web page:

@font-face {
  font-family: 'demoFont';
  src: local('demoFont'), url( format('ttf');

Even though the internet said that Firefox wants .ttf , it didn't work.

I have used Google fonts before so I checked that out for comparison.
@font-face {
  font-family: 'demoFont';
  font-style: normal;
  font-weight: 400;
  src: local('demoFont'), url( format('woff');

I find a site that does ttf-woff conversion ([1] below). It works great but, after I copy it in and edit to use the google version of @font-face. No dice.

Reading the internet ([2] below), I got the idea to look at the headers ('curl -I') coming back from google and my static domain specifically to see about 'Access-Control-Allow-Origin'. I found that google's header included "Access-Control-Allow-Origin: *" and mine did not.

The website suggested using .htaccess to add the goodies to the header:

<FilesMatch "\.(ttf|otf|eot|woff)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"

(Actually, I added the '|woff')

Checking the header... No dice. The line does not appear.

I notice mod_headers.c and check my Apache config. Not there. Navigate to /etc/apache2/sites-enabled:

ln -s ../mods-available/headers.load headers.load

service apache2 restart

Bada Bing. Bada Boom!

The header is there and the the typeface shows. Win! And, for good measure, it works in Chrome, Safari and late model Internet Explorer.

[1] -
[2] -