That sounds like a more than reasonable thing for this plugin to support. I’ll take a look at how this would work then report back on how what is involved to implement it.
I’ve managed to have a quick look at this now.
When requesting fonts from Google, you can list the subsets that you want. These subsets provide the glyphs for various languages. The “latin” subset provides (usually) all the glyphs for English, French, Spanish and German.
“latin” is also the default when no specific subsets are requested, and the Woo framework does not ask for any specific subsets.
Now, there are over half a dozen subsets, and you can request any combination of these, including latin-extended, greek, cyrillic etc. The more you select, the bigger the font files will be. However, not all fonts contain all the glyphs for all the subsets – that is a bit of pot-luck at the moment, but is not the issue here.
So, the Woo framework puts the code into the header of the page to request the Google font. That cannot be extended to support the subsets – it is just not written to be extended. It can possibly be over-ridden, so this plugin can replace the header font requests, but I would rather not get into that, in case a Woo Framework update is then broken by doing this (I just don’t know where Woo is taking this next).
Something for me to explore is perhaps loading the non-latin subsets separately. The Woo framework can load the latin, and the plugin could then load the selected non-latin subsets on top of this. Whether this will work or not, I really don’t know. I’ll do some experimenting and see if it is a possible way forward.
This is exactly what I do now as a workaround, overriding the Woo request with the original Google Webfonts call. Both versions work me, the full override, or the selective subset on the top of latin. Including this feature in your plugin would be a great support for exotic users 😉
<link href='http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700&subset=latin-ext' rel='stylesheet' type='text/css'>
Cool, I’ll give that a go. I will do some experiments downloading the latin and then the latin-ext in two steps, and then as one step. It could be that Google provides two non-overlapping font files in both cases, or doing it in two steps may download two overlapping fonts and so increase the data download. It depends on how google handles subset=latin,latin-ext – whether it gives you one font containing all those glyphs or two fonts to provide the whole set.
In fact, this could get interesting.
If I end up overriding the part of the Woo framework that puts the fonts into the head, then I guess we won’t just be limited to Google fonts – I can put *any* fonts into the site from *any* source, and it should all be picked up by the theme, so long as the plugin keeps track of where each font comes from.
Okay, a quick experiment shows that latin is included in all the other subsets that I have tried. So latin is in latin-ext, and also in greek and cyrillic.
Also the -ext subsets are supersets of the non-ext subsets. So latin-ext conatins the whole of latin already. If you ask Google for subset=latin,latin-ext it will completely ignore the latin and just give you the latin-ext.
However, if you let the Woo framework request latin, and then you request latin-ext on top of that, then you are duplicating a lot of the font download traffic. That’s not too much of a problem after the first visit from a desktop, but for mobiles it can slow things down a lot. Some fonts, just downloading all subsets and variants can involve bulling down half a megabyte (or more) from Google, so the more specific we can get it, the better.
I think the conclusion is, to fix this, we need to override the Woo framework function that inserts the font request into the page head. Give me a week or so to have a look at this, or send me a pull request on github if you already have something working.
You may be interested in this list of fonts available for each supported subset:
https://github.com/judgej/GoogleFontMetadata/blob/master/font_subsets.json
That list is probably ahead of what Google publishes, but I believe they will all be out eventually. Here is a preview, so they are coming soon:
http://www.google.com/fonts/earlyaccess
Most of the work on this is done now, and seems to work fine. For a preview, you can download the files from github:
https://github.com/academe/google-webfonts-for-woo-framework/tree/master/google-fonts-for-woo-framework
I need to find some sample “quick brown fox” equivalent text for the other subsets, and then I’ll put out a beta for acceptance testing.
One thing to watch out for, is that I noticed Firefox/Win7 at least, will automatically put in characters from substitution fonts if it cannot find the glyph in the selected font. Sometimes the difference can be subtle as it does do a good job at matching the fonts, but a noticeable difference can be seen.
@hoppylorinc try this beta release:
https://github.com/academe/google-webfonts-for-woo-framework/raw/master/releases/google-fonts-for-woo-framework-1.3.1-beta.zip
This introduces checkboxes on the admin page so that you can select which subsets you want to load on every page. The subsets apply to all the fonts, though obviously not all the fonts support all subsets.
The preview also displays appropriate text for each subset that is selected.
I’ve released it as a beta, because it overrides the Woo Framework function that puts the font requests into the head (but only if you have a subset other than “latin” selected). It should work, but I don’t know if there are any Woo plugins or themes that will create this function before my plugin gets a chance to create its own version. It is basically a race between all Woo themes and plugins to create this function first. Give it a go, and if you have any problems, just uninstall it and reinstall the latest from wordpress.org
Oh, and any feedback on that beta greatly received, whether it works or doesn’t work for you.
To clear of the aim of this beta release: it opens up additional subsets (international characters) supported by the Google web font API in any theme that uses the “Woo Framework”. I’ll make it an official release after some feedback of its use in the wild, as version 1.3.2 if there are no issues to fix.
Hi Jason,
sorry for the delay and thanks for the great support. Your beta now works just fine on my live sites – but in fact does the same thing I did by manually inserting a new line at the bottom of the page, so the download duplication issue still exists.
To reply your other remarks, I use the Canvas theme, I also noticed the substitution fallback in many browsers, and I found a great list of pangrams (I just learned this expression). In Hungarian the missing glyphs are ő and ű, but as far I know, the issue affects even more many Eastern European languages, such as Czech or Polish:
en.wikipedia.org/wiki/List_of_pangrams
Could you explain the “download duplication issue still exists” issue? The beta should completely replace the font requests that the Woo Framework adds to the page, so there should not be any duplicate fonts loaded. Unless you are talking about using it in conjunction with other plugins that provide workarounds too? Or perhaps you just mean the settings/preview page.
Oh, and thanks for giving it a go 🙂
Oh, wait, it was my fault, indeed. I checked it again, the beta works as intended, I have it’s single font request.
Thanks for the great work!
That’s good to hear – thanks.
I’ll release this version within the next week (when I have a little spare time in case there are any urgent fixes).
I’ll probably also make some changes later to pick up the subsets from the Google Webfonts API, as that information is available in the API. That way the list of subsets that you can request in the admin page can be limited to just what is published (and not the list I have in there now, which includes the subsets that is just around the corner, to be published by Google at some point).
It can also be used to display sample text for each font that is only applicable when the font supports the subset (e.g. only display Cyrillic Extended characters on fonts that have a cyrillic-ext subset, and not display it if the font does not have that subset, as it is a total waste of space).
But those are two nice-to-haves, so I’m not rushing to get them out, so long as the current version works.
Thanks again – you’ve opened my eyes to a whole world of international characters that I did not realised were organised and delivered in the way they are.
Kudos to you. The plugin now it’s even more useful for international Woo users, it might be worthy to set this off in description.
Thanks again for your help. 1.3.2 is out now.
