Closed (fixed)
Project:
@font-your-face
Version:
7.x-2.x-dev
Component:
Code (general)
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
8 Aug 2010 at 20:43 UTC
Updated:
15 Nov 2011 at 03:50 UTC
It would be nice if a theme could require a font and use @font-your-face to make sure the font gets loaded. I'm not sure how that could work without dependencies in themes, but it's something to look into.
On the other end, themes could expose groups of CSS selectors that should maintain a common font (e.g. "standard text" and "header text") to be used in something like #876726: Add list of commonly-used CSS selectors to add form.
Comments
Comment #1
sreynen commentedUntil #474684: Allow themes to declare dependencies on modules is in D8, I think the best we'll be able to do here is provide sample code for themes to put in template.php that checks if @font-your-face is enabled and shows an error message if it's not. Once enabled, themes could call a new function like fontyourface_require_font($provider, $url); and @font-your-face could take it from there, checking the provider is enabled and automatically importing and enabling the font as necessary. So next step is to write that function.
Comment #2
sreynen commentedComment #3
sreynen commentedIn #970922: Theme .info integration, mark.wise pointed out that fonts could be declared in theme .info files, removing the need for the function call I was planning to add. I'm thinking the format would be:
font[PROVIDER][] = "URL"
e.g.:
font[google_fonts_api][] = "http://code.google.com/webfonts/family?family=Allerta&subset=latin"
If the provider isn't enabled, @font-your-face would display an error prompting an administrator to enable it. Otherwise, it would enable the font from the provider at the URL, so that font can be reliably referenced in the theme CSS.
Comment #4
sreynen commentedThis should happen in 7.x-2.x now.
Comment #5
BarisW commentedWorking on this one now. Just to make sure: what should happen when a font is added using the .info file?
Suppose a provider has been enabled, but the import has not been run yet. Should one run the importer first? Of should we load the font without imported font info?
Comment #6
sreynen commentedI think we need to give a prompt if the identified font isn't found. That should suggest running import as a possible resolution, but there's also a possibility themes could reference a font that just doesn't exist from the provider anymore, so that should probably say something more general since we don't actually know import will fix it, e.g. "The specified theme font is not available. You may need to run import." or something like that.
Comment #7
sreynen commentedIf you haven't seen this already, mark.wise did something similar in a stand-alone module specifically for your Google Fonts module here:
http://drupal.org/node/1216704
Comment #8
BarisW commentedAdding Google Fonts using the .info file is quite easy, because Google Fonts only need a drupal_add_css($path_to_font, array('type' => 'external')). Other @font-your-face font-providers need to download the font and serve the CSS from the local file system, like FontSquirrel.
The easiest solution would be to use the module to:
I'm already done implementing this for Google Fonts and Fontsquirrel, and now working on implementing it in the other modules.
However; it would be better if step 2 could be skipped, so to only load the font definitions of the font that is added via the interface.
My thoughs:
- Import the fonts of the provider automatically if those haven't been loaded yet. So they will be loaded by fontyourface_preprocess_page()
- Expand hook_fontyourface_import() with an attribute to import just one font, so only that font can be enabled.
For now I'll just continue working on the current solution (first enable and import the fonts), then add them using the .info file.
The way fonts can be added now:
Comment #9
BarisW commentedCommitted to 7.x-2.x-dev. Please test.
Added support for:
- Google Fonts API
- TypeKit API
- KERNEST
- Fontsquirrel
Update README.txt
Fonts can be added in your THEMENAME.info like:
fonts[typekit_api][] = "Lobster"
fonts[fontsquirrel][] = "1942 Report"
fonts[kernest][] = "Alte DIN 1451 Mittelschrift Gepraegt"
Comment #10
BarisW commentedCommitted to 7.x-2.x-dev
Comment #11
sreynen commentedA few questions on this:
1) Is google_fonts_api_fontyourface_info_font() being used? I'm not seeing any calls to that. It looks like something that should be necessary, since it's mostly duplicating what google_fonts_api_preprocess_page() already does on any enabled font.
2) Currently every implementation of hook_load_font_by_info_declaration() is nearly identical. Could we handle that for all providers in fontyourface_add_theme_info_fonts() without a separate implementation in each submodule? I see that Google is using css_family instead of name, so maybe we could just include the field to search optionally in the google_fonts_api_fontyourface_info() response and default to name where it's not specified?
3) I'm a little concerned about relying on providers to use consistant names or CSS selectors. URLs seem more stable, but would that be too much clutter in the theme .info files?
Comment #12
BarisW commented1) Hmm, I think you are right. That one isn't used anymore. Must have been a left-over from a night hacking ;) I've removed it.
2) I agree, there is room for improvement. As you might have noticed, I've made the 'name' column unique - so we could use that one to search on instead of path and/or family.
3) That's exactly why I've chosen this setup. The problem with URL's is that there can be a lot of confusion of which URL to use. Some examples:
- http://fonts.googleapis.com/css?family=Contrail+One
- http://www.google.com/webfonts/specimen/Contrail+One
- http://www.google.com/webfonts/family?family=Contrail One&subset=latin#regular
Which one to use? That's why I've chosen to use the names like this:
By te way, I've just added a small helper function to count the number of fonts. I see a lot of separate SQL queries to count fonts, I'll walkthrough the code soon to replace those strolled queries with a function call.
Comment #13
sreynen commented1) Cool.
2) I hadn't noticed name is unique. I think that's actually a problem. If two providers offer the same font and use the same name, it now throws an error on import. Since most fonts are available from multiple sources, this is common. The combination of provider and name should be reliably unique if we really can't use URLs, but I still don't see why we wouldn't use URLs, since they are unique by definition.
3) While there are multiple URLs in public, there's only one URL in the database for each font. So that's the one to use. I think this is actually more confusing with names, as the same font can and does go by slightly different names in different places. How will a themer know they need to use the font family for Google, but the display name for everything else?
I think the way to avoid confusion is to output somewhere (maybe the settings page) exactly what needs to be added to the .info file for the currently enabled fonts so they can just copy and paste. And once the process for adding these is just copying and pasting, I think the benefits of URLs (reliably unique) outweigh the drawbacks (long, less readable).
I'm moving this back to needs work. If nothing else changes, we at least need to be able to import the same font name from two different providers.
Comment #14
sreynen commentedI just realized it only throws an error if you save the same-name font directly. If you use the updated fontyourface_save_font(), it actually overwrites the font from the other provider with the same name. That's also a problem.
Comment #15
BarisW commentedWhat if I change the UNIQUE key in the table from using name only to a combination of provider and name?
That combination should be unique. The problem with using the URL is that it can be hard for the end-user to determine which URL to use in the .info file. As given in the example above, the last one is the one returned by the API (http://www.google.com/webfonts/family?family=Contrail One&subset=latin#regular). And that URL cannot be found on the Google Web Fonts library. So you first have to enable the FYF UI and the Google Fonts submodule to determine which URL to use.
In my solution, just the following line would work:
fonts[google_fonts_api][] = "Contrail One"Comment #16
sreynen commentedWe had a long conversation about this in IRC. I'm not sure I convinced Baris, but I at least wore him down. :P