So I assume that Foundry is looking in the pages’ internal resources for the font, not on the external server.
I could hack the styles.css of the SeltHostedFonts Child stack and eliminate the “…/” in the font-face src path of course but shouldn’t it now be working out of the box?
RapidWeaver and Stacks 5 Plug-In are all up to date and Foundry 3 is freshly installed.
So I misunderstood using the URL feature in the video…?!
No prob, I added an additional selfmade child stack which does the job.
So here is my proposal:
Why not build it in?
saves diskspace (well, few, but it does) when I do not have to upload similar fonts used in different projects in each single project
same font files could even be used on projects other than built with Rapidweaver
improves page loading time because of two (or three) seperate https connections (one for the website, one for fonts and maybe a third one for warehoused images) instead of only one
the responsibility of correctly licensed fonts is at the web designers’ side and not on Elixir
developing workload would be minimal as it is only another child typeface stack without the “…/” in the font-face src URL
Sorry I did forget that I said in the video you can link to an outside source. It looks though like the API is now adding a bit of extra code in there that I don’t believe I ran into when building Typeface. Perhaps something changed along the way since I built the tool. I can look at changing this in the future, but it will require working around how the API functions by adding a feature which would remove that extra bit in the generated URL. For now you’ll want to use the Resources.
Really though, the added size of a font is miniscule. That is the point of web fonts – they’re supposed to be small so that they load quickly.
The reason the Resources is the preferred method is that it is centrally located and easy to use for the vast majority of RapidWeaver customers. Most do not like to mess with uploading their own font files to their server via FTP. That is why they’re using RapidWeaver. It also prevents users that don’t know any better from running into problems with blocked cross origin requests then they inevitably try to access a font from a different server than the one their site is hosted on.
True. Again though this is definitely for the more advanced user like yourself. As I said I’ll look at adding a toggle to work around the added code from the API to allow this in a future update.
I’m glad it sounds minimal, but with the way the API works I have to also develop added code within the addon itself that the user interacts with, not just the code it outputs.
Any time you’d like to submit a feature request, please do so using the instructions found here: