The good news: this test file seems to be working on the iPad in Safari, Chrome, and Firefox.
The bad news: on the desktop, it works only in Safari. Both Chrome and Firefox exhibit only the default sans serif font.
I have submitted this issue to Workman support, but wondering if anyone else has had this problem, or has a clue.
Thank you.
It is just a Cross Origin resource sharing issue. This is because technically you are serving the fonts from a different sub domain than the page. This is because you have the path to your fonts with the www in it and you are probably requesting them from http://pomelopress.com/fonttest09.
If you actually type http://www.pomelopress.com/fonttest09/ into your browser then the page renders the fonts correctly in Chrome and Firefox.
Obviously you need to account for requests coming from both variants and this is achieved by telling your server to allow the fonts to be accessed from other locations. You do this by adding the following instruction to your htaccess in the directory where the fonts are located:
Header set Access-Control-Allow-Origin "*"
or if you just want to allow certain domains, replace the * with a comma separated list of the domains.
Andrew, thank you for your response. You are correct. It does work with the entire url link.
So next problem. I am not sure how to upload an htaccess file. Problems in the past trying to do just that included the file disappearing and other weird problems.
And secondly, where does it go? Does it just go into âwwwâ, or does it go into the /resources file where the fonts are actually located?
Thirdly, does the text include the quotation marks?
Thanks.
The /resources file, BTW, is in www.
It needs to go at the root of where your fonts are - so in this case the same directory as your published site. public_html or similar.
Have a look via an ftp app and see whether you already have an htaccess file on the server.
If there is already one present you just need to add that line to it and donât change anything else that way you wont break anything existing.
If there isnât one, you can either create on in most ftp apps directly or create a text file on your mac called htaccess (NO LEADING DOT - or it will become a system file and invisible). Add the access control line from my post above and save it. Upload it to the root directory of your site via an ftp app and once there rename it to include the leading dot so it becomes .htaccess
This is not unfortunately working.
I created a file in TextEdit. It saved as an rtf (there was not txt option), which I named htaccess.
First I uploaded it to www, and got the following error message:
I blew that one away, and uploaded it to user root. The page showed up, but again failed to exhibit the proper fonts.
Thanks again.
I also created a .txt file in TextWrangler. It still didnât work.
While creating an htaccess file is somewhat of a hassle, in principle it is not too much of a hardship if it were successful. The jury, of course, is still out on that.
I am nevertheless curious about an exchange on this forum with Robert Ziebol (@zeebe) of Team Workman on June 1st of this year:
I enquired: âAre you having to create an htaccess file in order for Font Pro to work?â
He replied: âNope, no htaccess file is necessaryâ.
Wondering, therefore, why it is.
Iâm just wondering why you are creating a rtf file. Just use Textedit and create it as a simple txt file. It could be something as simple as that.
TextEdit did not offer the option to save as a txt file, only an rtf. But I did, as I mentioned previously, create a txt file in TextWrangler. It made no difference whatsoever.
Ah - OK - however the file you have uploaded opened my Textedit as a rtf file.
Yes, of course. That was the original file that I created.
Image below of the options for saving in TextEdit in El Cap. There appears to be no option to save as a txt. Am I missing something?
In TextEdit open preferences and under format tick âplain textâ. Close TextEdit then re-open it. Now it should save as .txt format.
Better solution:
Do a search on Mac App store for âtext editorâ. CotEditor is free I think and its okay for this kind of thing.
This is absolutely correct WHEN the fonts and the website are being served from the same domain (and subdomain) - this is why your page works when you go to the full url with the www in it.
As I mentioned in my first reply, expecting http://mySite.... to serve fronts from 'http//www.mySite..... addresses will cause Chrome and Firefox to trigger a cross origin restriction unless the server tells them that this is allowable - just the same is if you were serving fonts from http://fonts.mySite.com which many people do.
Here is a plain text htaccess file which you can just copy to the root of the pomelopress.com directory on your server and add the leading dot.
You must have a way with txt files, Andrew. Mine didnât work, but yours did.
So thank you once more.
A small, but niggling questionâŚI am wondering if you have any idea why the bottom of this H1 Nanu font is being cut off. The same thing happened with your late lamented Font Styles. Itâs not the end of the world, but I would love it to go away.
The cut off can happen with some very tall and condensed fonts like that. The simple solution is usually just to add a little bottom and/or top padding or margin to the header stack (in the Stacks layout settings at the very top). The more precise and correct method would be to increase the line height for h1âs using the Font Styles stack in Font Pro
All this discussion about domains and sub-domains has been a revelation. I had no idea, as I did not personally set up pomelopress.com with a sub-domain of www. That is the default configuration on LittleOak, an organization (apropos of another recent discussion) that I am less than enamored with.
In any case, I am very curious: is there a logic to that kind of configuration? Do other internet hosts do it differently?
