Cant Preview Fonts (Font Squirrel) or load fonts - Font Squirrel API changes

just popping in to say am having the same problem.

I came across this issue today too.

Now I think the problem is that the structure of the zip-file provided by fontsquirrel has changed. For some time ago it was just one folder containing the files (eot, svg, woff, ttf). So fontsquirrel module unzipped this folder to sites/default/files/fontyourface/fontname-fontfacekit.

Now the zip-archive provided by fontsquirrel contains some subfolders. The font files (eot, svg, woff, ttf) are now located in a folder called webfonts/fontname_regular_macroman.

And now unzipping the file from fontsquirrel does just result in only getting the files from the top folder in the archive into sites/default/files/fontyourface/fontname-fontfacekit.

So therefore it is not working.

Currently I have found a way around by enabling the requested font and then manually copy the contents from webfonts/fontname_regular_macroman within the archive to sites/default/files/fontyourface/fontname-fontfacekit.

So then I was able to use the font within the site.

I will check for a fix within the module, but could not find a quick fix at this moment.

But maybe this will be of help to get at least the desired font enabled.

THANK YOU! i thought i was the only one who noticed the change in folder structure. i also want to throw out there that it also looks like Fontsquirrel may have changed their font image preview path.

I think there is still something going on at fontsquirrel regarding API changes. I have viewed an URL like this http://www.fontsquirrel.com/api/familyinfo/Desyrel yesterday and today and there were changes regarding listing_image and preview_image so I think there will be major rework necessary in the fontsquirrel module. But maybe we should wait until fontsquirrel has finished changes to their API.

Question: Does the full new archive get extracted with all subfolders in your installation when enabling a font? On my installation only the top folder gets extracted. I am not sure if this is a problem within the fontsquirrel module or maybe a problem elsewhere (maybe permission on file system).

@stefan YES! am having the same exact problem. and now my FYF admin UI is borked too.

I have created this patch to fix the issues with Font Squirrel.
I've tested it and it works ok for me.
Please test it and give feedback, so it can be included in tree if the author agrees.

I apologise that there are small changes in the patch for other issues too. I didn't have the time to release separate issues and split the patch as are the official requirements of Drupal. I hope this will not be a great problem.

Here is the changelog:

[FIXED] Fontsquirrel API changes reflected in code (fixes #2109241 and fixes #2048175)
[FIXED] Views for Google and Font Squirrel fonts use area_text_custom now
[FIXED] Reduced font size for the sample Views to avoid ugly layout issues
[FIXED] Some extra whitespace removed
[CHANGES] Fontsquirrel module now uses own stylesheet.css processed from the original

Some more explanations follow:

• The API for generating custom preview samples on Font Squirrel returns a fixed size image, so some css tweaks are done in the code, so the results look better. This API call(or the url) may be changed in the future by Font Squirrel.
• The default font size for samples viewed in Views is a way too big and causes some ugly layout issues, so I reduced it to 16
• When activating any font for the first time, Fontsquirrel module now creates an own stylesheet.css file with a certain unique filename in a separate folder. This way the user can keep the css files when migrating. A problem could be that the url css attribute uses full site URL, but this remains to be tested on multisite installs. I didn't want to filter it to absolute path url, but it could be changed
• There is an issue in the UI module with the text filters, because it assumes that the user has unaltered configuration of the default filters and untouched full_html filter. But when the user has changed the name, a problem occurs. Since the content in 'area' is send directly by our code, I just turned the area in Views (for Google and Fontsquirrel) to 'area_text_custom', to fix the problem.
• I have included the create directory patch from issue #2048175: Zip font have directory, the module doesnot create folder and cannot extract font file, so credits to @Shellingfox
• This patch should solve these issues too: #2048175: Zip font have directory, the module doesnot create folder and cannot extract font file, #2038705: destination directory is not configured correctly errors.

Thanks

I have split off patches for preview and font enabling into two separate patches. It might be easier for the maintainer to integrate separate patches into the module. Thanks to PhobosK for providing this overall patch which lead me the way.

@PhobosK: You proposed some other improvements/corrections with your patch that are not directly related to the issues with fontsquirrel API changes. I have not added this to my patches because I think it should be separated.

So for making fontsquirrel work again the following worked for me:

1. Apply patch for preview of fontsquirrel fonts from here: https://drupal.org/node/2118281#comment-7991849
2. Apply patch for unzip issue provided here: https://drupal.org/node/2048175#comment-7673443 (Thanks to Shellingfox)
3. Apply patch for enabling fontsquirrel fonts from here: https://drupal.org/node/2118291#comment-7991869
4. Finally update fontsquirrel fonts via: admin/config/user-interface/fontyourface

This worked for me, maybe others can check this and maybe correct if necessary and hopefully we get the fixes included in fontsquirrel module soon, since at this moment fontsquirrel module is not working and this is a major issue.

Thanks stefan... though it will be harder to be maintained till added to tree....

Right now I've added a fix for the API, that will kill an issue with enabling fonts using two words style name (like "Bold Italic"). I got this after thorough testing of almost a 100 different fonts in FS module, so I think now it should work ok...

Sorry but the fix is all in one again on the base of the previous fix (including it as the requirements are to be against the whole current tree)... The only actual change is the refining the names of the zip_directory and css_font_family_name (+ a debug info for the user if finding the original stylesheet.css fails)... here is the code changed (applied against the current tree and very roughly shown):

+			drupal_set_message(t('The default stylesheet for font %fontname from Font Squirrel was not found. The path of the css file missing is: @path_css', array('%fontname' => $font->name, '@path_css' => $css_orig_file,)), 'error');

---------- SKIP --------

+	  'zip_directory' => strtolower(str_replace(" ", "", $variant->family_name) . '_' . str_replace(" ", "", $variant->style_name)),
+	  'css_font_family_name' => strtolower(str_replace(" ", "_", $variant->family_name . $variant->style_name)),

The whole patch folows....
If I am granted a commit perm by the authors/contributors of the module I can fix that directly as a whole patch...

Thanks all...

Thanks PhobosK,

while testing I already discovered this issue about the two words style name too and already considered it here https://drupal.org/node/2118291#comment-7991869.

I would be glad if the module can be fixed shortly either in one step with your whole patch or with separate patches. I just did split the patches if the maintainers would prefer it this way and to maybe speed up the process of fixing the module.

I just saw your altered patch at #2118291-1: Fix font enabling for fontsquirrel provider - (API changes at font squirrel) and I do not think that the approach of altering the source of the unzipped font (in this case the stylesheet.css) is a good one... It will be something like if you have the Libraries module enabled and you try to alter the source of an used library in sites/all/libraries by another module... This will obviously render some complications for other modules that can use the library too.

In the specific case of Font Squirrel, it may not be much of a problem to alter directly the original source css file right now, but when other useful features for handling the font zip are added in the future (like checking a version/md5 or entirely deleting a downloaded font zip etc etc features that need to be coded later on) it could render some problems and incompatibilities... Generally speaking when using an outer source its best to leave it unaltered and make your changes in a separate place...

Besides just a note about directly altering the original css in your patch: you will not need some of the added by me code then, like using the call to file_prepare_directory just after the preg_replace ....

Anyway it is just a question of discussion and community decision ;) :) and has nothing to do with this exact issues... Thanks again for your work...

Yes, you maybe right that it is not the best way to alter the file directly. But I change the font-family name to the name provided by fontsquirrel API with fontface_name in the json. In my opinion it is an inconsistency from fontsquirrel to not use the name they provide with the API in the css file as well. So i considered this as a way of correcting the fontsquirrel data and not as altering ;-)
In addition I could not detect any pattern about the font-family name used in the css file, sometimes style name is added, sometimes not. Sometimes there are spaces and sometimes there are font-family names that have nothing in common with the font name.

And you gave me that masterpiece of regular expression to use:preg_replace('#^(\s*font-family\s*:\s*).*$#im', '$1 \'' . $font->css_family . '\' ;', $css_content); - I really like it

Well my first idea was to use all font source unaltered, with no additional tweaks etc, so I created the css_font_family_name var.... but then that needed too much altering of the main @FYF module code, so a simpler approach was just to copy the orig css file and alter the font-family in it.... anyway i left the initial css_font_family var unused for future reference, just in case someone needs it later on... As far as I did my initial tests (not that thorough), the pattern they use in the css was:
strtolower(str_replace(" ", "_", $variant->family_name . $variant->style_name))

but anyway since i dumped that idea, i had not tested it thoroughly...

Best approach is just contact them (Font Squirrel) and ask what is the pattern they use for compressing all source font data... but i didn't have that much time...

Besides there is one small problem with showing the custom font pattern in Views of the module... It uses a "deeply hidden" interface with a default return of 700px image that is supposed to be called manually (read slowly) from a page on their site (though using ajax), and not called multiple times per second (as it is done in @FYF now)... so i guess someone has to contact them and ask for permission to use their server resources this way...

Anyway I leave that to the module maintainers or some user with a better negotiating skills than i do have ;)

thanks for your work on it PhobosK, did the job for me!

I tried to apply the patch in #11, but it just resulted in WSODs and undefined checksum errors. It's very possible I messed up the patch as it is a very large one. I'm just going to move on to some other method since this basically makes the module unusable with Font Squirrel.

I also applied the patch in #11 against the latest dev (which is from last year), and I can confirm it works for me. However, I had to manually delete the public://fontyourface directory to get fonts that I had previously tried to download before the patch to work (they were giving me an error that the stylesheet couldn't be found when I tried to enable them). Thanks!

This is a bug report, not a support request. In the future, please do what you can to help keep issue metadata accurate.

The patch in #11, as noted by PhobosK, contains changes that are irrelevant to this issue. Please move those changes to separate patches on separate issues. It's difficult to review a patch that makes many different changes. I will revise the patch myself if no one gets to it sooner, but cannot do that right now.

I already tried to separate the parts of the patch that are needed to fix only this issue, look at #10: https://www.drupal.org/node/2109241#comment-7991891

So maybe you can revise patches from there easier.

Creating Related Issues

Sorry, but I'm trying to add related issues and keep doing it wrong. :-(

Just came across this issue and it seems like the folder structure of the zip-archives from fontsquirrel changed again. The patch #11 almost worked, though I had to change line 230 from

$css_orig_file = file_build_uri('fontyourface/fontsquirrel/' . $metadata['path'] . '-fontfacekit/web fonts/' . strtolower($metadata['zip_directory']) . '_macroman/stylesheet.css');

to

$css_orig_file = file_build_uri('fontyourface/fontsquirrel/' . $metadata['path'] . '-fontfacekit/web fonts/' . strtolower($metadata['zip_directory']) . '_macroman/specimen_files/specimen_stylesheet.css');

Hope it helps anyone...
Cheers.

The big problem is that font squirrel doesn't officially support them. I worked on this for the D8 port. I'll try and take a look in the next week and see where the patch is / what needs to be revised.

Anything new about this?