This is a brilliant module, works really well. But, with the advent of @font-face, its usefulness might be on the decline. However, here I see an opportunity.

Implement @font-face in the module, which then uses flir as backup for when browsers dont support @font-face. You would already have the font uploaded, selectors set and so the implementation would mostly be correctly disabling the flir part, when needed.

Comments

btopro’s picture

btopro CreditAttribution: btopro commented

Yeah, CSS 3 has the future of this project mostly being in the backwards compatibility side. Sorta like the IE PNG fix module / projects that exist currently.

hadsie’s picture

hadsie CreditAttribution: hadsie commented

This is a really small module, so I'm not too worried about that. I'm looking forward to @font-face but it's still a ways off before most people won't need to support browsers that don't support @font-face.

@a_c_m can you explain how that would work? Can you explain the workflow you see happening there? I don't really know how it would work.

a_c_m’s picture

a_c_m CreditAttribution: a_c_m commented

@hadsie - quite simple, 2 steps.

1) instead of the JS we have now that triggers the replacement, you add some browser detection to the front so its disabled for browsers that support @font-face.
2) using the selectors setup in the settings page of the module, we inject some extra css, so the fonts that would have been used by flir, are used on these selectors as @font-face fonts.

I dont think it should be that hard to do.

btopro’s picture

btopro CreditAttribution: btopro commented

@hadsie

I think that's close. You put the @font-face in there by default, then get a list of all the browser versions that are the minimum to support the @font-face property. Then, if you detect a version that isn't supported, run the jquery functional from flir.

For reference, this is what we used in one of our themes that gets pretty solid cross-browser support

@font-face {
font-family: 'League Gothic';
src: url('fonts/LeagueGothic.eot');
src: local('League Gothic Regular'), local('League Gothic'),
url("fonts/LeagueGothic.woff") format("woff"),
url("fonts/LeagueGothic.otf") format("opentype"),
url("fonts/LeagueGothic.svg#LeagueGothic") format("svg");
}

stemount’s picture

stemount CreditAttribution: stemount commented

It is worth noting that @font-face has been supported in IE from version 4. Quite poor that "leading" browsers like Chrome (v4), Firefox (v3.5) and even Safari (only made available in version 3) have only recently supported @font-face.

hadsie’s picture

hadsie CreditAttribution: hadsie commented

I also recently noticed this module: http://drupal.org/project/dfont which supports @font-face.

I haven't had time to look at what it does yet but it seems like it may have similar goals.

a_c_m’s picture

a_c_m CreditAttribution: a_c_m commented

hadsie, i would perhaps like to see the two work together, or merged into a single module. So if the browser is capable of using font face, we do, otherwise reverting to the flir method.

hadsie’s picture

hadsie CreditAttribution: hadsie commented

I'd like to see all the font replacement options work together somehow. But it doesn't make sense for the flir module to do that (it's name kind of limits what it should be capable of). If the dfont author wants to make some sort of an API for other modules to work with (which he may have already done, I don't know) I totally think it would be worth the effort to convert flir to work through that API. I guess to me it just feels that it doesn't make sense for flir to be the like "parent" module for this stuff, since it's kind of a simple module just devoted to integrating the 3rd party flir code into drupal, and doing anything more might make things confusing.

And just so I'm clear, having fonts render with @face-font and then fallback to flir is something I'd definitely like to see happen.

hadsie’s picture

hadsie CreditAttribution: hadsie commented

I also just noticed this ticket and module today:

#292594: Turn into plugin for Dynamic Rendering and abandon this project
Dynamic Rendering

Judging by the goals of it the flir module should probably be run as a plugin for it. As well as the dfont module.

vph’s picture

vph CreditAttribution: vph commented

hi,
i'm the author of dfont. I'm willing to help with providing an API of some sort (please let me know what you have in mind). I am a little hesitant to make dfont a plugin of the module render because of several reasons:

+ I think it will be difficult and dfont doesn't quite behave the way that render assumes a "plugin" does. But I could be wrong.

+ Another reason is that dfont is quite light weight and simple to use.

+ I think dfont will work great in parallel with all of these modules flir, sfir, render, etc.