A possible bug with Typeface: may be a wrong path when using Self hosted font on 2nd child-level page.
Works fine Inside Rapidweaver but not when published
test embed font.rw8.zip (258.3 KB)
Hey there @beretrouge – Can you give me some more details about what you’re running into? Also, a live URL, in addition to the project file you sent, will help out. Please let me know as many details as possible.
Here is a live url:
http://qtbridge.com/Download/testembed/
the specific page where Self hosted fonts are not loaded:
http://qtbridge.com/Download/testembed/Level%202/Hosted%20L2/
Looks like RapidWeaver is inserting an extra / in the URL for the path. You’ll notice the double slash in the URL here:
I’ll take a look to see if I can thwart RW. I’m back in the office Monday and will have a look then.
I notice, thanks a lot Adam, I’m gonna check if RW7 has same behaviour.
same result using RW7
This is a know bug in RW that has been in RW6, RW7 and looks like RW8 too.
A really elegant way to solve this would be for Typeface to have a new facility to allow fonts to be linked to directly using the Link function. I.e. put your fonts into a server folder called fonts and point the Typeface to my server.com/fonts, or add a font folder to resources and point the Typeface to my server.com/resources/fonts.
2 Likes
Hi Beretrouge, I have the same problem.
When i review te page within in Rapidweaver then i have to go first to the home page in order to get the other page preview allright. When i put the site online i encounter the same problem as you have.
Thanks Adam for the // thing. I was interested so i did change for all subpages (.css) the …/…/…//…/…/ into …/…/…/ and now all pages are working fine. Off course no fix solution,
but at least i know now how to solve it.
I was very glad because it was effecting also the drop down in mega menu that was not properly lined out. Maybe it depends on which fonts you are using.
Thanks Rene_J for your comment!
Happy to not be alone with this bug.
So I agree with the solution proposed by webdeersign (Link function).
External Goggle fonts work without problems, so what is the benefit using local hosted fonts instead?
The reason i switched to self hosted fonts, because of the GDPR privacy recommendations in Europe. See this thread for more info:
Thanks Rene_J for the thread, but there is now a function in RapidWeaver 8 to anonymise requests to third party servers, and If I inform visitors via a privacy message…
Hi Beretrouge,
That is good news.
I have already RW8 but did not know this feature. Thanks for pointing it out.
Looking into this now. Have been consulting with @isaiah on it to try and track down whether it is a bug or whether I can approach it differently. Just wanted to provide a quick update though, as I didn’t want it to seem like I’d forgotten about this thread.
2 Likes
Sorry to take so long on this, but it needed some close inspection. I think I’ve worked up a solution for this problem. I’m going to do some more testing tomorrow, but I think I should be able to get this one completed in the near future.
5 Likes
Now everything seems to work fine!
Thanks a lot
That is great to hear! Glad it has sorted out the problems for you.
I’m going to mark this thread as being solved by the recent Foundry v1.3.3.7 update if no one else is still experiencing this problem.
I still see this issue or a similar issue in Preview occasionally and is only obvious when a font quite different to the default fonts is used.
What I see is the issue where RW can’t connect to the resources folder for some reason and is a long standing RW issue going for years and is not a Foundry issue.
The solution is simple but not currently possible in the way that Typeface has been implemented, in that fonts can only be stored in resources. If this restriction was lifted then fonts could be stored in a server folder of choice such as https://mysite.com/fonts/font.woff. This is not possible in Foundry because in RW preview the local server address (http://127.0.0.1:56088 in this case) is prepended to the font URL and therefore, doesn’t work.
I would suggest emailing Realmac Support directly if you’re running into an application error.
As for the way Typeface loads self-hosted fonts – the stack will retain its functionality as-is for now.