If you try activate Linux Libertine family, that contain five fonts (http://www.fontsquirrel.com/fonts/Linux-Libertine), then you got only first - LinuxLibertineRegular.
Problem not in downloaded "@font-face Kit" from Font Squirel - it contain all five fonts. Problem in functions fontsquirrel_fontyourface_import and fontsquirrel_fontyourface_enable.
fontsquirrel_fontyourface_import don't check "family_count", and add to database only one family_name without querying to http://www.fontsquirrel.com/api/familyinfo/ for get "style_name" if family_count bigger then 1.
fontsquirrel_fontyourface_enable check only first object in received array, and not look farther ahead.
Unfortunately Font Squirel don't have api for choosing font subsets - it fixed to only MacRoman :(
Comment | File | Size | Author |
---|---|---|---|
#11 | fontyourface-Batch_import_variants_from_Font_Squirrel-1124500-11.patch | 5.29 KB | Drave Robber |
Comments
Comment #1
sreynen CreditAttribution: sreynen commentedHi BondD,
This is a very clear explanation of the problem, thanks. Unfortunately it will be probably take a while to solve.
Comment #2
sreynen CreditAttribution: sreynen commentedThis should happen in 7.x-2.x now.
Comment #3
rachelf CreditAttribution: rachelf commentedThis also appears to be the case in 6.x-2.8 and 6.x-2.x-dev (at least where I am trying to activate Lato from fontsquirrel). Will the fix you did in 7.x-2.x-dev also work for the 6 branch?
Comment #4
sreynen CreditAttribution: sreynen commentedThis isn't fixed anywhere yet. #2 only changed the target version of the fix.
Comment #5
rachelf CreditAttribution: rachelf commentedSorry - my mistake. Is there anything that can be done to help on this?
Comment #6
sreynen CreditAttribution: sreynen commentedThe next step is writing a patch. The current Font Squirrel import does one API call for all info. To fix this, I think we need to do a separate API call for each family to get the full list. That will be slow enough that the import needs to change to be a batch process, like the Fonts.com import already is.
Beyond writing a patch, you can work around this bug by downloading the font you want from Font Squirrel, then uploading it with the local fonts submodule.
Comment #7
drupal_was_my_past CreditAttribution: drupal_was_my_past commented@sreynen I saw that as of commit 88ba6e1 it looks like the Fonts.com module isn't doing a batch import anymore. Is that correct? Would the next step for fontsquirrel.com still be to write a patch to use a batch process?
Comment #8
sreynen CreditAttribution: sreynen commentedFonts.com no longer does a bulk import at all. Instead, it imports on demand while browsing, which is only possible because the Fonts.com API takes search parameters. That's not an option on Font Squirrel with the current API, so it still needs to move to a batch import, yes.
Comment #9
eubielicious CreditAttribution: eubielicious commentedI came across a similar problem when trying to enable the "Ostrich Sans" font. I could enable it (I assigned all headers to use this font) but just got the default (Times) font in its place.
Looking at the /sites/default/files/fontyourface directory, the CSS file (font.css) looks like this:
h1, h2, h3, h4, h5, h6 { font-family: 'OstrichSansLight'; }
The other stylesheet loaded (ostrich-sans-fontfacekit/stylesheet.css) looks like this:
As you see there is no font family titled "OstrichSansLight". So by manually editing the font.css file, I can load the fonts I want (OstrichSansMedium for example) but the problem then is if I then make any changes via the @font-your-face UI those manual edits will be lost.
The way around all this appears to be to enable the fonts, but not to assign them specifically to tags/classes etc. in the UI. Instead, add the font declaration to the theme .info file:
Then by looking at the font stylesheet.css as above, I could add "OstrichSansBold" (for example) as I want.
That works fine.
Comment #10
Drave Robber CreditAttribution: Drave Robber commentedI'm going to give this a try.
At first, I was skeptical about batch import (600+ non-parallel HTTP requests can take a lot of time if your server is located somewhere on the fringe of the world), but I couldn't conceive a workflow to get variants later that would not be overly complex and confusing. So batch import will it be.
Comment #11
Drave Robber CreditAttribution: Drave Robber commentedWell, it's not as bad as I expected.
Only 242 families have multiple variants at the moment, and importing them all takes ~2 minutes, even across the pond.
Patch attached. (it could probably use some more error handling / logging, and interface texts could be more polished, but functionality first)
Comment #12
sreynen CreditAttribution: sreynen commentedCommitted. Let's worry about improving error handling if/when people start reporting errors. Everything worked fine in my tests. I think fixing this one very old issue probably cuts the average bug age in half. Yay!