Make it possible to include local installed fonts (local on the webserver)

Here's an overview of how I think this could work:

1) Create a new submodule called, e.g., local_fonts.
2) in local_fonts_fontyourface_import(), scan files/fontyourface/local_fonts/ for directories. Assume each directory contains a font, and associated stylesheet: stylesheet.css.
3) Run regex on stylesheet.css for font-family, font-weight, and font-style to get font info.
4) In local_fonts_preprocess_page, add stylesheet.css.
5) Add a message on the settings form explaining how this works.

Just what I need. I have some webfonts that aren't on the supported services (I have them local on my site). They are licensed as webfonts so I would really like to use them locally rather than via a service.

The other way I was thinking was that instead of adding the files inside your files folder, the user could maybe upload a zipped file (or provide five file upload fields for eot, otf, ttf, woff, svg) and provide a font-family name, font-weight, font-style (unless you want this also as a css in which case the css isn't dynamically created and won't need to create a css file as a result). And you add the stylesheet.css on the preprocess page.

I'll try and get a patch rolling for this over the next few days (doing a file_scan on what I'm thinking shouldn't be too difficult if that is the way you want to approach it) and should get similar results.

@BTMash, good idea. I like the sound of a form to generate the necessary CSS. I hadn't thought of that option. It would allow for a more guided process and wouldn't require whoever is choosing the fonts to have direct filesystem access. I'd lean toward separate fields for each font file type, both because not everyone has PHP compiled with ZIP and because that would be a good place to explain which browsers support which font file types.

@BTMash, I hope you manage to write that patch.

I look forward to testing it.

Subscribing! But I have a question. The FLIR module doesn't have a D7 and waiting for a response if there are. I have custom .ttf for Palaeo Hebrew installed on my Ubuntu 10.04 and need to know if this update your working on will pickup this font also?

@Vc Developer, as with so many questions, the answer to yours is: yes, except in IE. Because IE only supports .eot fonts, you'd need to convert the .ttf to .eot to make the font work in IE. There are tools that will convert the font for you, e.g., one from Font Squirrel.

Thanks!

I've been working on this on and off over the past few days and I figured this would be a good time to get some help on it and I'm attaching what I have so far. The status of it all:

1) SVG - currently, the svg needs to specify a hash tag consisting of the font name that is embedded inside it. I'm not sure if this should be done programmatically (more cpu resources) or ask the user to add it (problematic for user). As a result, I have commented out the ability to upload a svg file.

2) I have been able to get the uploads working along with generating the css file. I have been able to verify that this works in the preview and in the edit screen to view how the font looks at different size. What I *haven't* been able to figure out is how to get it to actually get used outside that area. I see the css file get loaded so I don't think that's the issue but I'm not sure where else this part lies.

3) Code cleanup and consistency with the other modules. I am very certain there are places this could and should happen. I was using a form_alter to change the import button into a link to go to the form and whatnot. And there are places where it does seem like certain variables/whatnot get repeated.

4) Validation. Currently, I am only validating for the filetype. We'll need to add in validations that the font has not been entered before.

Please note that this is for the D6 version as the D7 version has different functions for saving files/whatnot and so a chunk of that aspect will need to be ported to D7 once we get this all fixed up. Marking as needs works for now.

Thanks @BTMash! I'll look at this in the next couple days.

I think this is pretty close. I don't see much more than the issues @BTMash already mentioned:

1) I lean toward pulling the hash tag out of the SVG file. I don't think CPU resources is a big deal, since this is just a one-time thing during the upload. I am a little worried about doing that reliably, but we can always make it better if people run into issues.

2) At first I wasn't able to get it working even in the preview for the font I was testing, but I got it to work both there and on the main site by changing a couple things in the CSS, making it more closely match the CSS I already had from Font Squirrel. That CSS puts the .eot src on a separate line, with no ? after it. I'm not sure why that one is treated differently. It also lists the format of the .ttf as "truetype" rather than "ttf." So I'm not sure why it was half-working for you; the only issues I saw were in the CSS formatting.

3) I'll clean it up as much as I can before committing.

4) Yeah, it needs to catch duplicate fonts, and it also needs some way of dealing with them, i.e. edit and/or delete interfaces.

5) Regarding the comment in the code "sreynen might have ideas on how to use the importer function that he has written to link outward", I'm not sure what that means. In general, I think the current workflow is good, with a link to the import form where the import button is on the other providers.

I'll try to do a little more work on this and then get it checked into CVS soon so people can more easily test it.

one idea is to be able to define which folder is going to be the local storage of fonts... so each site in a multisite installation could have different fonts set to choose.

interesting, subscribing to this

Quickly tested patch / submodule from #9

Had to manually create a 'local_fonts' folder in my 'fontyourface' files folder.

And converted my OTF font from dafont.com to EOT, TTF and WOFF, using onlinefontconverter.com
My font currently only works with Safari (5). Not Firefox (3.6). Not IE (8).

Hints for further testing are welcome.

This is now committed to the D6 dev version. If you see any problem with it, please open a new issue. I'd like to keep this focused on porting to D7 now.

@PieterDC, that problem should be fixed in the version in CVS. If not, please open an issue.
@hedac, I'm not sure how @font-your-face works with multisite in general, but I think it might already work how you want if each site has its own files directory. This uses file_directory_path() to determine where to save the font files. If not, please open an issue.

An overview of what I changed from BTMash's work, which generally matches the discussion above:

1) Uncommented SVG upload and added code to get font ID from file.
2) Added more directory checks and (I think) improved the directory names.
3) General code cleanup
4) Added a delete button to the edit screen. I didn't add a duplicate check; I'm not sure that's really necessary now that any duplicate can be deleted. Please open an issue if you think it's important.

oh .. it is true.. if the fonts are in the files directory then it is ok.
I wanted to try but I do not see the local-fonts module in the dev version yet.

@hedac, the dev versions are packaged nightly, so it probably wasn't in the package when you looked. It should be in there now.

it is working nicely sreynen. It created the local_fonts and everything
one question I have .. what is the src:local that appears in the css file?
src: local("Ä¿– ´¿Ÿ¨ÄŒŽ"),

also look at this guide for css syntax adding a ? after the .eot for Internet Explorer <9 compatibility
http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax

@hedac, at the bottom of that post, they link to a newer version they're using to address a problem with that original version:

http://www.fontspring.com/blog/further-hardening-of-the-bulletproof-syntax

The local src is a different solution to the same problem, recommended here:

http://paulirish.com/2010/font-face-gotchas/

As I understand it, the Font Spring option has the advantage of saving downloads in IE while the Paul Irish option has the advantage of not using CSS hacks. With those advantages and disadvantages in mind, I chose the Paul Irish option. I'm generally okay with imposing a tax on browsers that don't follow web standards to avoid hacks. Hacks like that question mark have a long track record of breaking when browsers improve, as happened with the original Font Spring CSS hack.

The random text in a local source certainly looks like another hack, but it's not really; it works exactly how it's specified to work. There's no font on your local machine with that name (because it's a really strange name for a font), so it won't load in any browser.

All of that said, if someone knows of a reason this is a bad solution, please let me know. I'm no expert on how this all works; I just tried to follow expert advice.

Hello, one question:

Is the local font feature available on 6.x-2.x-dev ?

@doomed, yes, it's in 6.x-2.x-dev, but it's also in 6.x-2.4. If you don't have a good reason to be using dev releases (i.e. you're doing development), you should stick with the stable releases.

Thanks sreynen!

I'll check the stable one. No show-stopping issues on it right?

Hi, I've downloaded the latest git version, I'm not seeing any local fonts module or options? The readme says so you may want to download KERNEST fonts and use the Local Fonts module to load them from your server instead. Can someone please explain how to get this working on Drupal 7 with a local font?

Thank you,
Tony

tgroff, this hasn't been ported to D7 yet, hence the status. If you have any coding experience, it shouldn't be very difficult to port, and I'd be happy to help answer any questions that come up. Otherwise, I'll get to it eventually, but it will probably be a while, since I have several higher-priority issues.

This was ported to D7 in #1243964: D7 Port of Local Fonts Module. I'll close this after that's committed.

#1243964: D7 Port of Local Fonts Module is committed now.

I hate spammers