Add sIFR 3 plugin

It's out!? Cool!

Seems like I've been hearing about sIFR 3 for a year now and there hasn't been any movement on it.

Is there a changelog somewhere that explains what has been improved since sIFR 2.0.2?
Since v3 still seems to be in beta state I'm setting priority to minor.

Any status update on this issue?

I read about the issues that caused the 2.0.5 update of sIFR and in the comments Mark Wubben says "But perhaps you’d be interested in sIFR 3 which has much better font sizing support."- And on the sIFR 3 page linked by phillipadsmith it says "If you’re trying to decide between sIFR 2 and sIFR 3, sIFR 3 is definitely the better choice."

sIFR 3 seems pretty useful, but it's not out of beta yet, are we waiting for the final release?

I've not yet tried sIFR 3. However, implementing it should be quite easy, because you can use the sIFR 2 plugin of Dynamic Rendering module as a template. Patches are always welcome!

I got a problem.. I tried using it but I can't get it to work..
I used the code from the sifr3 default.htm, and tried placing it in the template.php for one of my themes. So I wasn't sure how to go about it, but this is the code if anyone is capable of helping. A friend of mine and myself have both looked at it, and before we had some java script errors we got through those, but I cant get the label to display.. ideally i would change the pink logo (which i think is $h1) but instead I'd just like anything in the font I wish to use.. Here is a link to show everything in the dir needs to be included to display the font.. http://futurepr0n.com/themes/fourseasons/default.htm [The theme I'm using is fourseasons (excellent theme) but I modified it a bit.. I'm sorry, and I don't know if that is allowed]

Actually - I opted to upload the .php please check it out if you get a chance. It's a bit too long to post.

You can visit it live at http://www.futurepr0n.com
Sorry, I wouldn't ask if I didn't need the help. I tried searching but I didn't find any useful information, and since I was working with drupal - I figured to start here.

Thanks

edit: I posted in the wrong place didn't I? I figured out of two relevant threads to post here instead of create a new one hah..

echo here. I also need a sIFR 3 plugin.

I can chip in on the project.

regards,
Luciano

_natron and I (mbutcher) have been working on a patch. I'm attaching the new plugin and JavaScript code:

- sifr3.inc: Support sIFR3 on the server side
- sifr3.activate.js: some streamlined JavaScript to handle the activating of fonts and the rendering of flash content.

Put these in render/plugins/

_natron has a few other patches that he will follow up with, but I believe the two files above will work on an unpatched version of Dynamic Render.

You will still need to download sIFR 3 and put it in render/plugins/sifr3

NOTE: YOU MUST CREATE NEW FONT FILES FOR SIFR 3. sIFR 2 font files do NOT work with sIFR 3.

Glad to see progress here!

Some notes on the files:

- sifr3.activate.js is superfluous. It seems you overlooked that Dynamic Rendering automatically generates a sifr3.rules.js in the files directory, which should contain the required JavaScript along with the configured replacement rules and invocations. Likewise, sifr3_render_render_rule_js() needs to return a string, not an array.

- When comparing sifr.inc with sifr3.inc, it seems you replaced too many instances of "sifr".

- I do not think you need to create a separate directory in sifr3_render_setup().

- It seems you missed to uncomment the hovercolor in sifr3_render_rules().

- Please revert the form key 'text' to 'tweaks' in sifr3_render_rule() for now. The fieldset should only contain optional properties. Also, please do not use fieldsets in fieldsets.

- Please use strtr() instead of sprintf() in sifr3_render_css_screen(). Also, the value "inherit" is not supported in many browsers; you probably do not want to output a color at all instead (see how this is done in sifr.inc).

- sifr3_render_load() does not use render_find_render(), see sifr.inc for how this function should look like.

After reworking above mentioned points, the functions _sifr3_font_registry() and sifr3_fontmovie_activation() are obsolete and can be removed.

This is a patch for sifr.inc. Basically telling sifr to look in the plugins/sifr directory for its sifr.js file.

Uhm. Well, I don't know which version of this module you are patching against, but the one in CVS already contains the proper code in sifr.inc:

function sifr_render_load() {
  $plugindir = render_find_render('sifr');
...

If your patch was meant to update the last in #12, then please create a new one, ideally including the changes I asked for in #13.

On comment #13:

One of our goals in composing this plugin was to avoid having to patch render.module. This, of course, made parts of our task more difficult because render.module makes some assumptions about the way that a renderer should work, and sIFR 3 simply does not follow those assumptions. For example, it has fairly stringent requirements about how and when a font must be activated.

I realize now that I did not do a sufficient job explaining the purpose and method of our files, and the version I am posting here includes more comments. But let me explain in detail some of the things you question.

- sifr3.activate.js is superfluous. It seems you overlooked that Dynamic Rendering automatically generates a sifr3.rules.js in the files directory, which should contain the required JavaScript along with the configured replacement rules and invocations. Likewise, sifr3_render_render_rule_js() needs to return a string, not an array.

It is most certainly not superfluous.

First, it is generally considered bad form to embed JS programming logic inside of strings in PHP. It's hard to edit, hard to debug, and hard for newcomers to figure out. It's also more error prone.

Second, I want the freedom to refactor the JS in a couple of ways. I want to wrap it in behaviors, which will make it AJAX/AHAH aware, and I also want to take advantage of some of the other features of the sIFR3 API. Those are features for another day, but it would be a pain to have to edit if I had hard coded it as PHP strings.

So we split out the JS into a separate file to ease ongoing maintenance. (We did the same, as you may notice, with the huge heredoc of CSS -- for the same reason.) We followed the more Drupalish convention of passing data to JS in the form of namespaced object literals. This was also done for a second reason: We need to build up the font list separately from the rules list (in order to ensure that sIFR.activate() runs only once per font).

The end result is that our sifr3_render_wrap_rules() no longer prints out any programming logic. It simply serializes arrays of values into configuration arrays just like drupal_add_js() normally does on dynamically rendered pages. These rules are then written to a static file just like you do in sifr.inc.

Doing things this way has now given us the ability to dynamically inject SIFR rules from programming logic in other modules. We can augment the Render.sIFR data structure using drupal_add_js() calls, and not worry about font loading problems. And if we change the JavaScript logic for our plugin, those modules will not need to make analogous programming changes.

Regarding our choice to have sifr3_render_render_rules_js() return an array, here's our rationale. First, there is no good reason to create snippets of JavaScript by stringbuilding in PHP (see previous note). Second, Drupal provides drupal_to_js (which is essentially json_encode() plus html encoding), which can take an array of arbitrary depth and convert it to JavaScript object literals and arrays. Rather than have sifr3_render_render_rules_js() return strings of hard-coded JavaScript which then have to be manually encoded by the wrap function, we opted to return an array from sifr3_render_render_rules_js() and then handle all of the encoding in one place with drupal_add_js(). It's clean and simple.

Before doing this, we read through render.module to ensure that no other functions relied upon the strings that sifr3_render_render_js() produced. We didn't find any (which is, of course, different than saying that there aren't any). So we went ahead and chose what we feel is the better architecture, and we returned an array.

Our testing revealed no negative side effects and no bugs. If you find any bugs as a result of this decision, let us know and we will see what we can do.

- When comparing sifr.inc with sifr3.inc, it seems you replaced too many instances of "sifr".

I found a couple cases in the the help text and one in a stylesheet. If you see any others, let me know specifically what they are. (_natron and I have rewritten the help text to be more specific to sIFR 3.)

- It seems you missed to uncomment the hovercolor in sifr3_render_rules().

I uncommented it in sifr3.inc. It seems that the render.module doesn't accurately display the hover color. Should I file a new bug report on render.module, or should we track it in this issue?

- Please revert the form key 'text' to 'tweaks' in sifr3_render_rule() for now. The fieldset should only contain optional properties. Also, please do not use fieldsets in fieldsets.

The name 'tweak' caused a little bit of a hubub here in the first place. The CSS spec does not refer to tweaks. It classifies things into font settings, text settings, and so on. We tried to follow the CSS terminology more carefully (see http://www.w3.org/TR/CSS21/text.html). Since this plugin is separate from the original plugin, we figured it would not be an issue.

As far as UX goes, there is no requirement that fieldsets be grouped by "required" and "non-required". That's what the #required flag in FAPI is for. Consequently, we see no rationale for breaking up fieldsets by requirement. It just gets confusing. (Why, for example, would font face be selected in one place and font size be set in another?).

Also, we are about to add another fieldset for effects. We have internally tested drop shadow effects, and we wanted to put those in a separate field set from text-based stuff. Again, adding everything but the kitchen sink to a 'tweaks' fieldset seemed not very user friendly; we have hence decided to group our options by functional group.

We would humbly suggest that you change 'tweaks' to something else, too. It's not a very descriptive name for a fieldset... sorta like saying "options" or "settings". The Jargon File, for example, defines 'tweak' as To change slightly, usually in reference to a value (http://www.eps.mcgill.ca/jargon/jargon.html#tweak). Given this definition, shouldn't any configuration change be a tweak?

- Please use strtr() instead of sprintf() in sifr3_render_css_screen(). Also, the value "inherit" is not supported in many browsers; you probably do not want to output a color at all instead (see how this is done in sifr.inc).

Done. Fixed both.

- sifr3_render_load() does not use render_find_render(), see sifr.inc for how this function should look like.

We dropped this intentionally for compatibility reasons.

In your sifr module, you require the sifr.js and sifr.css files to be copied into the render/plugins directory. We want to be able to use sifr 2 and sifr 3 at the same time -- or at least we don't want to preclude the possibility of somebody doing so. (Our testing documents used both 2 and 3 in the same document, so we know it works.)

Here's the root of the problem: sifr 2 and sifr 3 both use files named sifr.js and sifr.css. Furthermore, sifr 3 does the wise thing by breaking out its files into subdirectories, rather than storing them all in the same place. For both reasons, it was impractical to put sifr.js and sifr.css from sifr 3 directly into render/plugins. That would have required (a) dropping sifr 2 support and (b) potentially rewriting any parts of sifr that depended on a specific path configuration.

So we needed to put the sifr 3 files somewhere else besides render/plugins. Instead of having partial copies of sifr 3 in two places (as is the case with sifr 2), we chose to put all of them in one place. And the obvious candidate for the location to put a plugin is in the render/plugins directory.

However, render_find_render doesn't find files there. Furthermore, we couldn't see much value in running that function anyway. Even in its best case it incurs more overhead. So we did not use the function.

(I think _natron's patch even changes the sifr.inc plugin to do the same thing.)

If you would like to test out the code and then suggest a way to resolve this problem without preventing dual support for sifr 2 and sifr 3, please do. But for now we haven't been able to get things working for an unpatched sifr 3 and the render_find_render() function. Again, that's not to say that it *won't* work -- just that we can't get it to work.

Finally, we would like the option to maintain our plugin in a separate module file so that we can easily turn it on and off, use standard update/install tools, and so on. Frankly, the custom 'plugin' thing is a little hard to work with. Worrying about file name collisions, path munging, and such need not be done when files are separated into modules. The manual installation is a pain, too, and we still can't figure out how to appropriately handle an uninstall of a plugin. We might be able to dedicate some time to developing a patch to render.module that would provide this if you are interested.

Installation

Once again, the steps for installing:
1. Untar the file.
2. Copy the sifr3.inc and sifr3.activate.js files to the render/plugins directory.
3. Get the sIFR 3 distribution and put it in render/plugins/sifr3 (so that render/plugin/sifr3/js contains the sifr.js).

* You must generate new fonts. sIFR 2 fonts do not work with sIFR3.

Thank you for explaining your reasonings in detail. That's a big list of issues you mention there. I would definitely consider some of your points valid, but some others not, which means they need a lot of further discussion. However, this is what we call scope creep or eatin' baby kittens in Drupal. So, the title of this issue is "Add sIFR 3 plugin", but you are trying to change Dynamic Rendering's design in one fell swoop "while being there". Again, I am not opposed to all points you mentioned, but as the maintainer of this module I have to take every single decision deliberately, ensure that changes won't break existing sites, support all users that have issues with the module in the long run, and lastly ensure that all developments are in line with the scope, intention, and design goals of this module.

I will try to reply to your points in brief here, however, those should really be discussed further in separate issues:

• "Embed" JS in PHP: DR is not really embedding inline JavaScript in PHP, it is rather intentionally generating the contents of JavaScript and CSS files, which are saved as static files, and served by Apache without Drupal's interaction afterwards. This happens on purpose, since the contents are the same for all pages, and DR does not really need to run to do the same and waste CPU cycles on every single page request. If we want to change this design and behavior, we should discuss in a separate issue.
• Wrap JS code in behaviors: Nothing stops you from doing so in sifr3-rules.js using the current design. If we want to change it globally (which would probably be a good thing), we should introduce behaviors for sIFR 2 at the same time. But this would be a separate task/feature request "Use behaviors to support AJAX/AHAH contents".
• JS settings for font definitions: See my first point.
• Inject rules dynamically: There was not one feature request since this module (and the previous sIFR module) exists. If there is a use-case, we should discuss the potential implementation in a separate issue (perhaps following a hybrid approach, and perhaps implementing a similar "JavaScript hook" design like in Wysiwyg API).
• sifr3_render_render_rules_js(): See my first point.
• Fieldsets: The original UX goal was to "hide" all optional settings, since many users of DR/sIFR do not properly understand them anyway. I can see your point that the fieldset(s) should probably called "Advanced xyz settings" then, but ideally, we should change it the same way for the sifr2 plugin for consistency then.
• "Tweaks": See previous point.
• render_find_render(): This is where I still think you did not understand the purpose of this function - instead of hardcoding any location, it does the exact opposite for UX reasons: Many users failed to drop the sIFR files into the proper location, which lead to a horrible mess of support requests in the past. This function scans the filesystem for the actual location of the plugin files and caches the results in a variable. The installation instructions looked like your 3rd installation step before, but those lead to approx. 1 support issue every week. If we want to change or improve this behavior, we should discuss this in a separate issue.
• sifr 2 and sifr 3 use the same filenames: Clearly, this is a design flaw of the current architecture. I could imagine that using a similar method to detect plugins and library versions like in Wysiwyg API would work out, but we should discuss this in a separate issue. For now, I would be fine with adding exclusive support for either of both versions at the same time and adding a notice on the project page and README.txt until the plugin discovery process has been rewritten.
• Providing plugins via 3rd party modules: This needs further discussion. The original goal was to explicitly remove the need for searching, finding, installing many different rendering modules (also considering that every single module adds burden to Drupal's overall performance), but in the meantime, I would agree with Crell that it should at least be possible. That would be another reason for using the API architecture of Wysiwyg (which is almost the same as can be found Panels), probably best handing off this job to CTools directly, but (you guessed it) we should discuss this in a separate issue.

To repeat: I like your thinking here in general and I am open to discuss and work on further improvements for Dynamic Rendering. Since this was one of my first modules I created for Drupal and it is widely based on the former sIFR module (which I took over prior to creating Dynamic Rendering), I am not very pleased with the current code and architecture either. However, the module is used in its current way on a bunch of sites (including our own), so we have to make sure that all developments follow the usual process. Basically in your interest, I would like to add support for sIFR 3 using and following the current architecture, which means you are safe to use it on your site without patching the module. Afterwards (or in parallel), we can discuss those other issues separately, think about the best long-term solutions for each one, and come up with one we all agree on.

I really hope you understand my reasoning. Also, I'm desparately searching for a co-maintainer, so if we are able to join forces and can agree on the usual development process and standards of Drupal (core), then I'd certainly consider you here.

The only point of yours, which was too vague to tell whether it is related to this issue or may be a general issue is "doesn't accurately display the hover color". Since the hover color was disabled prior to the port to 6.x, it may be possible that there might be an issue with it, but I can't tell this based on your description.

Just a few things.

First, we didn't change any of the features of the Render module itself, or make any necessary changes to the sIFR 2 plugin. We are *just* implementing new features in a new plugin, and we're doing it in a non-invasive way. I'm not sure why you view adding a new js file for a new plugin as "feature creep". We just wanted to build our plugin in a way that makes it easier for us to maintain. (Note that everything is *still* statically cached and served that way. We're not really generating anything on the fly. We just split the JavaScript functions from the JavaScript settings.)

Second, our use case for injecting style info: We want to be able to write modules and themes that configure their own sIFR fonts in code. This allows us to turn on and off definitions based on active modules or themes. That's the use case, but we have not done any coding to do things that way. Currently, we're just using the admin interface.

Third, I understand the rationale for render_find_render()... we just can't seem to get it to work. It could just be because of the sIFR2/sIFR 3 naming issues. It could be because we did something wrong (you can see the commented code in the patch).

It appears from our testing that our sIFR 3 plugin works without patching any of the render module. We've been able to run sIFR 2 and sIFR 3 fonts *on the same page*. But we haven't been able to do that without our intra-plugin hacks (like returning an array instead of a string).

Finally, Crell, _natron, and I all have a vested interest in the success of this module -- we use it on client sites all the time. And our use cases for the module are getting more and more sophisticated. We drew straws and I won (or lost). If you're interested, I would like to become a co-maintainer.

I'll open a separate issue to discuss module-based plugins. That is the issue I am most interested in in the short term.

1) This means I was not able to communicate anything I wanted to say in #17 at all. I thought I did, but obviously I did not. Sorry for that. In short: Let's patch support for sIFR 3, using the identical style and API approach like sIFR 2. Afterwards, think about improvements for the API - not before or while being there.

2) You still do not need two separate JavaScript files for that, if you can load and live with one. (see below)

3) Yes, as mentioned before, the current capabilities are very limited. Since sIFR 2 uses a different file structure and contains a unique and required file sIFR-print.css, the trick is to simply re-order the dependencies array for sIFR 2.

Okay. Talk is silver, code is gold:

- Fixed plugin information.
- Fixed version detection by removing filepaths, and changing order of sifr2 dependencies.
- Removed unnecessary creation of render/sifr3 directory.
- Fixed coding-style in various places (wrong indentation, white-space, etc.)
- Removed obsolete hovercolor remarks.
- Changed rule configuration form to be more comparable with sifr2.
- Fixed form element descriptions in rule configuration form containing needless white-space and escaped quotes.
- Fixed wrong option values for new form select lists (copy and paste error).
- Removed debugging code.
- Fixed usage of tabs instead of 2 spaces in generated CSS.
- Removed sifr3.activate.js.
- Changed sifr-rules.js into Drupal JavaScript behavior.
- Fixed sifr3_render_load() to use render_find_render().

@todo
- The new form elements in rule configuration form need a proper description; good example found in "Text indent".
- sifr3_render_help()
- sifr3-README.txt

@unsure
- Why does all replaced text wrap behind each word? My fault or default configuration error? (=> README or FIXME)

Thus, most tasks done, but there are still some things left to do.

That said, especially the coding-style of sifr3.inc made me worry though. It's not that DR underwent a beauty care recently (again, the module needs love), but I should probably tell you upfront that I'm a bit nitpicky about coding standards, the key to collaboration and innovation. This needs to improve a bit.

Patch lost somehow.

Patch looks good to me. I will be out until new year's, and will not be able to do any additional testing/development until then.

Internally we have drop-shadow and blur effects working, but I'll have to regenerate a patch for those. That'll be some time in January.

Hi, have given the patch a go and it seems to mostly work. I used the Sifr Generator to generate a sifr3 font (axaxax). The dynamic render admin page displays the font and detects the plugin fine. However when the home page of my site first tries to load on a clean browser (no cache, no cookies) IE7 hangs with "Downloading .... sites/default/render/axaxax.swf" and the source of the blank page which results is:

If I refresh the page everything works as expected from then on, with the sifr3 font substituted in the tags expected.

This might be related to the use of Drupal behaviors. On occasion, I have seen conflicts between jQuery's 'ready' event (which is behind Drupal behaviors) and other third party libraries when injecting Flash into a DOM.

Any idea how to resolve this? Am using a ready event to rotate a series of jpg images. Could this be conflicting?

bejam: Using jQuery's 'ready' for other things won't impact sifr. So no need to change your other code.

I'd suggest commenting out the behavior function by changing two lines in the sifr3_render_wrap_rules() function, like this:

function sifr3_render_wrap_rules($rules) {
  $output = '';
//  $output .= "Drupal.behaviors.renderSIFR3 = function () {\n";
  if (is_array($rules)) {
    $fonts = array();
    $rules_output = '';
    foreach ($rules as $rule) {
      // Build JavaScript-safe variable name.
      $rule['fontname'] = preg_replace('@[^a-zA-Z0-9_-]@', '', $rule['font']);
      // Output sIFR font object once for each font.
      if (!isset($fonts[$rule['fontname']])) {
        $fonts[$rule['fontname']] = $rule['fontname'];
        $output .= "  var ". $rule['fontname'] ." = { src: '". $rule['font'] ."' };\n";
      }
      // Prepare replacement rules.
      $rules_output .= "  sIFR.replace(". $rule['fontname'] .", ". drupal_to_js($rule) .");\n";
    }
    // Output sIFR font activation.
    $output .= "  sIFR.activate(". implode(', ', $fonts) .");\n";
    // Output sIFR font replacements.
    $output .= $rules_output;
  }
//  $output .= "}\n";
  return $output;
}

(See the two lines that have out-dented comments? Those are the ones I have commented out.)

If that works, perhaps we can re-roll this patch before it gets committed.

Matt

I have a transparency problem with sIFR 3.

Background color is always #FFFFFF. It doesn't matter whether "Text Background Color: " value is(even empty) and "Flash Player wmode: " set as "transparent".

I compared HTML source codes created by sIFR 2 and sIFR 3 and I suppose problem is sIFR 3 can't read wmode and bgcolor values somehow(difference between two versions shown with bold lines below each sample code):

sIFR 2 sample code:
<embed class="sIFR-flash" height="15" width="470" src="/sites/default/files/render/calibri_bold_tr.swf" quality="best" flashvars="txt=Solutions&textalign=left&textcolor=#bbbbbb&linkcolor=#bbbbbb&w=470&h=15" wmode="transparent" bgcolor="transparent" sifr="true" type="application/x-shockwave-flash" style="width: 470px; height: 15px;"/>

wmode="transparent" bgcolor="transparent"

sIFR 3 sample code:

<object id="sIFR_replacement_2" class="sIFR-flash" height="19" width="37" type="application/x-shockwave-flash" name="sIFR_replacement_2" data="/sites/default/files/render/sifr-calibri-bold-tr.swf" style="">
<param name="flashvars" value="id=sIFR_replacement_2&content=%253Ca%2520href%253D%2522/en/works%2522%2520target%253D%2522%2522%253EWORKS%253C/a%253E&width=37&renderheight=19&link=/en/works&target=&size=10&css=.sIFR-root%257Bdisplay%253Ainline%253Bfont-weight%253Apointer%253Bfont-style%253Apointer%253Bcolor%253A%2523999999%253Bbackground-color%253A%253Bmargin-left%253A0%253Bmargin-right%253A0%253Btext-align%253Aleft%253Btext-indent%253A0%253Btext-decoration%253Anone%253Bletter-spacing%253A0%253Bleading%253A0%253B%257Da%257Btext-decoration%253Anone%253B%257Da%253Alink%257Bcolor%253A%2523999999%253B%257Da%253Ahover%257Bcolor%253A%2523bbbbbb%253Btext-decoration%253Anone%253B%257D&cursor=pointer&tunewidth=0&tuneheight=0&offsetleft=&offsettop=&fitexactly=false&preventwrap=false&forcesingleline=false&antialiastype=&thickness=&sharpness=&kerning=false&gridfittype=pixel&flashfilters=&opacity=100&blendmode=&selectable=true&fixhover=true&events=false&delayrun=false&version=436"/>
<param name="wmode" value="[object Object]"/>
<param name="bgcolor" value="#FFFFFF"/>
<param name="allowScriptAccess" value="always"/>
<param name="quality" value="best"/>
</object>

param name="wmode" value="[object Object]"
param name="bgcolor" value="#FFFFFF"

I followed instructions explained@#16 and used given file. I also tried to create a new font file using appropriate transparency settings for publishing flash movie.

I did not use patch file, because i don't know how to patch :(. But i suppose patch file doesn't include a fix for this problem.

I'm using: Drupal 6.6, WampServer 2.0, Firefox 3.0.3, IE 7

Vegetator,

To fix your transparency issue.

Change this line 'wmode' => $wmode, to 'wmode' => $wmode['wmode'], in sifr3.inc.

Clear Cache.

I'll do this officially when I find out the status of the sifr 3 plugin.

Thank you _natron, it worked :)

I also want to thank everyone who spent time and effort for this great module.

It took days to fix sIFR 2 for horizontal primary links, but it seems new resizing algorithm of sIFR 3 works fine. There might be another "non-vital" issues(loading font files, some of new features, cache etc); but i am not sure for now. I will keep testing and giving feedback.

Thanks mbutcher, commenting out the lines you indicated has solved all my issues!

If someone could update the patch with the required changes, I'd commit it.

I am looking to roll a patch, however I cannot find the 'wmode' => $wmode, line to modify. If someone can let me know where it is, I will create an updated patch.

I went ahead and committed the patch in #20. Please re-open this issue if there needs something to be altered.

The patch that was committed was broken because of the Drupal JavaScript behavior.

Attached is a patch that removes the behavior.

According to the sIFR 3 documentation, only sIFR3.activate has to be called outside of a load/ready event. However, I couldn't get the sIFR.replace() function to fire correctly inside of a behavior, either. So I removed the behavior altogether.

Yeah, I committed the original (incomplete) patch on purpose, so other users are able to test the new plugin. However, I am not sure whether we really want to remove the Drupal.behaviors yet.

I haven't had any luck getting the code to work with the behaviors. On FF3 Mac, the module simply does not work at all with the behaviors code. (Haven't tested on IE, but given the particular issue, I'd be surprised if it works.) IF you can send along info on what browsers you've seen it working on, that might be helpful in tracking down any potential solution to this loading thing.

Here's my main observation about what seems to be going on:

The main issue, as I see it, is that sIFR's activate() function calls its attach() function (line 551 in source version), which binds an initialization function (fire(), which calls initialize()) to the load event. There are bound to be compatibility issues between this and jQuery's ready event (which is used to execute behaviors). The initialization event seems to fire on load. But if attach() is called from $().ready(), and the load event has already fired, there seems to be room for failure there.

So at the very least, the activate() call appears to need executing outside of the $().ready().

I tried simply moving that bit out of the behavior, but with no luck. Something apparently wasn't ready in time for the replace() function to work. There may be a remedy there, somewhere... but it's not immediately evident.

Hello,

I'm a typical user who has installed this module and have no development experience.

Basically, I've installed 5.x-1x-dev with sifr3 support and unfortunately it doesn't work - fonts simply doesn't render properly. The production module works fine and I'm using Drupal 5.14.

Here is a summary of what I've done:
1) Ensured my .swf files are encoded in sifr version 3 not version 2.
2) Uploaded the latest sifr.js version 3 436 and created a directory sifr
3) Production module works fine, 5.x works fine with sifr2 support in the same drupal installation.
4) Applied the patches in this post but realised they were the same as the development module.
5) Used ie6,ie7,google chrome, firefox 2-3 and all browsers report the same symptoms.

Would appreciate some help or further feedback. I'm keen to get this sifr 3 working.
Cheers,
Daniel

Reverting issue status. Please test the patch in #33.

How looks actual required file structure of the render(module) directory, please? Where to put sIFR distribution?

Can I / have I use?:
modules/render/sifr2/
modules/render/sifr3/

or

modules/render/sifr/ (no version number)
modules/render/sifr3/

or if I'd like to use only sIFR 3, then I put it to

modules/render/sifr/ or modules/render/sifr3/?

Here #120308-16: Add sIFR 3 plugin (at the end) its written about putting sIFR 3 version to directory modules/render/sifr3/.
Then here is #120308-19: Add sIFR 3 plugin Removed unnecessary creation of render/sifr3 directory.
I'm quite not sure what to do..
Thank you so much.

I use Drupal 6.10. I've done same like #120308-37: Add sIFR 3 plugin (patches, fonts atc), only diference

* I put sIFR 2 distribution to modules/render/sifr2/
* sIFR 3 to modules/render/sifr3/.

* I uploaded 4 fonts (2 for each version):
(sites/default/)files/render/neuzeit-book-heavy-sifr2.swf
(sites/default/)files/render/neuzeit-book-heavy-sifr3.swf
(sites/default/)files/render/neuzeit-book-sifr2.swf
(sites/default/)files/render/neuzeit-book-sifr3.swf

Adding sIFR 2 rule

Now when I'm trying to add a new rendering rule for plugin sIFR 2 everything works I see scrshot: drupal-sifr2.png (attached).
* Fonts for both version are loded (sIFR3 font is only not selectable).
* Loaded:
Related CSS:
modules/render/render.css
(sites/default)/files/render/sifr-screen.css
modules/render/sifr2/sIFR-print.css
Related JS:
modules/render/sifr2/sifr.js (v2.0.7)
(/sites/default)/files/render/sifr-rules.js (my rules)
and inline JS code:

<script type="text/javascript">
if(typeof sIFR == "function") {
 sIFR.replaceElement(".render-font-neuzeit-book-heavy-sifr2-swf", named({sFlashSrc: "/sites/default/files/render/neuzeit-book-heavy-sifr2.swf", sColor: "#000000", sLinkColor: "#000000", sBgColor: "#FFFFFF"}));
7 sIFR.replaceElement(".render-font-neuzeit-book-heavy-sifr3-swf", named({sFlashSrc: "/sites/default/files/render/neuzeit-book-heavy-sifr3.swf", sColor: "#000000", sLinkColor: "#000000", sBgColor: "#FFFFFF"}));
 sIFR.replaceElement(".render-font-neuzeit-book-sifr2-swf", named({sFlashSrc: "/sites/default/files/render/neuzeit-book-sifr2.swf", sColor: "#000000", sLinkColor: "#000000", sBgColor: "#FFFFFF"}));
 sIFR.replaceElement(".render-font-neuzeit-book-sifr3-swf", named({sFlashSrc: "/sites/default/files/render/neuzeit-book-sifr3.swf", sColor: "#000000", sLinkColor: "#000000", sBgColor: "#FFFFFF"}));
};
</script>

HTML:

...
<span class="render-font-neuzeit-book-heavy-sifr2-swf render-font">neuzeit-book-heavy-sifr2</span>
...
<span class="render-font-neuzeit-book-heavy-sifr3-swf render-font">neuzeit-book-heavy-sifr3</span>
...
<span class="render-font-neuzeit-book-sifr2-swf render-font">neuzeit-book-sifr2</span>
...
<span class="render-font-neuzeit-book-sifr3-swf render-font">neuzeit-book-sifr3</span>
...

Adding sIFR 3 rule

When I'm trying to add a new rendering rule for plugin sIFR 3 not working I see scrshot: drupal-sifr3.png (attached).

* No fonts are loded.
* Loaded:
Related CSS:
modules/render/render.css
(sites/default)/files/render/sifr3-screen.css
modules/render/sifr2/sIFR-print.css
Related JS:
modules/render/sifr2/sifr.js (v2.0.7)
(/sites/default)/files/render/sifr-rules.js (my already set rules)
modules/render/sifr3/js/source/sifr.js (version 3, revision 436)
and inline JS code:

<script type="text/javascript">
Drupal.behaviors.renderSIFR3 = function () {
 var sitesdefaultfilesrenderneuzeit-book-heavy-sifr2swf = { src: '/sites/default/files/render/neuzeit-book-heavy-sifr2.swf' };
 var sitesdefaultfilesrenderneuzeit-book-heavy-sifr3swf = { src: '/sites/default/files/render/neuzeit-book-heavy-sifr3.swf' };
 var sitesdefaultfilesrenderneuzeit-book-sifr2swf = { src: '/sites/default/files/render/neuzeit-book-sifr2.swf' };
 var sitesdefaultfilesrenderneuzeit-book-sifr3swf = { src: '/sites/default/files/render/neuzeit-book-sifr3.swf' };
 sIFR.activate(sitesdefaultfilesrenderneuzeit-book-heavy-sifr2swf, sitesdefaultfilesrenderneuzeit-book-heavy-sifr3swf, sitesdefaultfilesrenderneuzeit-book-sifr2swf, sitesdefaultfilesrenderneuzeit-book-sifr3swf);
 sIFR.replace(sitesdefaultfilesrenderneuzeit-book-heavy-sifr2swf, { "font": "/sites/default/files/render/neuzeit-book-heavy-sifr2.swf", "selector": ".render-font-neuzeit-book-heavy-sifr2-swf", "css": { ".sIFR-root": { "display": "", "font-size": "16px", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "", "text-indent": 0, "text-transform": "", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#000000", "text-decoration": "none" } }, "wmode": "", "fontname": "sitesdefaultfilesrenderneuzeit-book-heavy-sifr2swf" });
 sIFR.replace(sitesdefaultfilesrenderneuzeit-book-heavy-sifr3swf, { "font": "/sites/default/files/render/neuzeit-book-heavy-sifr3.swf", "selector": ".render-font-neuzeit-book-heavy-sifr3-swf", "css": { ".sIFR-root": { "display": "", "font-size": "16px", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "", "text-indent": 0, "text-transform": "", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#000000", "text-decoration": "none" } }, "wmode": "", "fontname": "sitesdefaultfilesrenderneuzeit-book-heavy-sifr3swf" });
 sIFR.replace(sitesdefaultfilesrenderneuzeit-book-sifr2swf, { "font": "/sites/default/files/render/neuzeit-book-sifr2.swf", "selector": ".render-font-neuzeit-book-sifr2-swf", "css": { ".sIFR-root": { "display": "", "font-size": "16px", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "", "text-indent": 0, "text-transform": "", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#000000", "text-decoration": "none" } }, "wmode": "", "fontname": "sitesdefaultfilesrenderneuzeit-book-sifr2swf" });
 sIFR.replace(sitesdefaultfilesrenderneuzeit-book-sifr3swf, { "font": "/sites/default/files/render/neuzeit-book-sifr3.swf", "selector": ".render-font-neuzeit-book-sifr3-swf", "css": { ".sIFR-root": { "display": "", "font-size": "16px", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "", "text-indent": 0, "text-transform": "", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#000000", "text-decoration": "none" } }, "wmode": "", "fontname": "sitesdefaultfilesrenderneuzeit-book-sifr3swf" });
}
</script>

HTML:

...
<span class="render-font-neuzeit-book-heavy-sifr2-swf render-font">neuzeit-book-heavy-sifr2</span>
...
<span class="render-font-neuzeit-book-heavy-sifr3-swf render-font">neuzeit-book-heavy-sifr3</span>
...
<span class="render-font-neuzeit-book-sifr2-swf render-font">neuzeit-book-sifr2</span>
...
<span class="render-font-neuzeit-book-sifr3-swf render-font">neuzeit-book-sifr2</span>
...

See anybody where's in problem? Thank you very, very much!
(I'm more graphic designer then coder, but I'm trying to do my best... :)

Please, is here anybody with more knowledge of this case, who can give some hints.
Many spring thanx.

Is the Drupal.behavior commented out in the generated JavaScript? (see comments 33 and 35)

mbutcher many thanx for your reaction/reply.
Unfortunately I dont understand you well. :/
Which JavaScript file, or inline JavaScript you mean?
One generated JS is inline in HTML head (posted above), second is generated JS file with rules (sifr3-rules.js) looks like (no comments there too):

Drupal.behaviors.renderSIFR3 = function () {
	var sitesdefaultfilesrenderneuzeit-book-sifr3swf = { src: '/sites/default/files/render/neuzeit-book-sifr3.swf' };
	sIFR.activate(sitesdefaultfilesrenderneuzeit-book-sifr3swf);
	sIFR.replace(sitesdefaultfilesrenderneuzeit-book-sifr3swf, { "font": "/sites/default/files/render/neuzeit-book-sifr3.swf", "selector": "asd", "css": { ".sIFR-root": { "display": "inline", "font-size": "", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "left", "text-indent": 0, "text-transform": "none", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "pointer" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#666666", "text-decoration": "none" } }, "wmode": "window", "fontname": "sitesdefaultfilesrenderneuzeit-book-sifr3swf" });
}

IMHO you mean something different.. isn't it?
Thanx a lot for your coop..

mattez:

Code in your comment (comment 43):

Drupal.behaviors.renderSIFR3 = function () {
var sitesdefaultfilesrenderneuzeit-book-sifr3swf = { src: '/sites/default/files/render/neuzeit-book-sifr3.swf' };
sIFR.activate(sitesdefaultfilesrenderneuzeit-book-sifr3swf);
sIFR.replace(sitesdefaultfilesrenderneuzeit-book-sifr3swf, { "font": "/sites/default/files/render/neuzeit-book-sifr3.swf", "selector": "asd", "css": { ".sIFR-root": { "display": "inline", "font-size": "", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "left", "text-indent": 0, "text-transform": "none", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "pointer" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#666666", "text-decoration": "none" } }, "wmode": "window", "fontname": "sitesdefaultfilesrenderneuzeit-book-sifr3swf" });
}

That is the problem. Comment out the first and last line of the section above, so that it looks like this:

//Drupal.behaviors.renderSIFR3 = function () {
var sitesdefaultfilesrenderneuzeit-book-sifr3swf = { src: '/sites/default/files/render/neuzeit-book-sifr3.swf' };
sIFR.activate(sitesdefaultfilesrenderneuzeit-book-sifr3swf);
sIFR.replace(sitesdefaultfilesrenderneuzeit-book-sifr3swf, { "font": "/sites/default/files/render/neuzeit-book-sifr3.swf", "selector": "asd", "css": { ".sIFR-root": { "display": "inline", "font-size": "", "font-weight": "normal", "font-style": "normal", "color": "#000000", "background-color": "", "margin-left": 0, "margin-right": 0, "text-align": "left", "text-indent": 0, "text-transform": "none", "text-decoration": "none", "letter-spacing": 0, "opacity": "100", "leading": 0, "kerning": "false", "cursor": "pointer" }, "a": { "text-decoration": "none" }, "a:link": { "color": "#000000" }, "a:hover": { "color": "#666666", "text-decoration": "none" } }, "wmode": "window", "fontname": "sitesdefaultfilesrenderneuzeit-book-sifr3swf" });
//}

That code is actually generated from a PHP file (against the standard Drupal practices), so if you want to change it, you will need to find that section in the PHP code and comment it out (See comment 25). I don't have the code in front of me at the moment, but it's in the sifr3 plugin.

Sun: Can you just fix this already? I reported it in December.... and I still don't understand why you decided to add this to my patch and then check it in when you knew it was broken.

think i have same issue trying to use sifr3. i use sifr2 and sifr3 rule. sifr2 rule seems to pull correct files from render (from /render/sifr folder) but sifr3 wont know how to pull its files, right? aka you have to decide on using one or the other. then populate the /render/sifr with sifr files you want right?

I happen to have the same issue: blank page on first request while loading in the swf file.

Patch in #33 worked for me but I think only after I cleared the render cache admin/settings/render. Clearing admin/settings/performance as well.

Thx mbutcher!

I'm having this blank page on initial load issue and patch 33 didn't work here. Well the page loaded with no issue but the iSRF fonts were missing.

It's not a big deal here as in an instant fix but it is proving to have an impact of usability trials which people who should understand failing to remember they were told to reload the page.

If I revert to using iSRF2 will that solve this for now?

When might a patch that has been tested and confirmed be released?

Yani

Patch in #33 did work for me with sIFR 3.

"When might a patch that has been tested and confirmed be released?"
There is no one who can answer this question. But you can be part of the answer by sorting out why patch #33 does not work for you.

OK before the patch when the page freeze happens Firebug see this as HTML

script src="/sites/default/files/render/traveling%20typewriter.swf" type="sifr/prefetch" defer="">
1CWSÎ��xÚl»TRé÷?¼ÁKz°¬Dͦ@³”£eZfaf9¨Y*ÚX}Ñr¦�/ÞÊD‹Ñ"-š/¡à­r2mlÌ,­´HÇÑòf6¦–53/~ÿ¿õ{×½/‹½à<{Ÿ}û|žç
28€Ø2ÍØÿýL7Ý4œüÌ!9ð[$ïOÙ²Ÿ“šžr4a2ü“ð}ÌñGÙû᏾‹IHÝÿÿ~–ËdîO‚vJ졃ÉÃf'…¤ÔƒðLáf°è',˜ah¶?ƒÖÌhñÌ«ñÿ¼š˜ÀâÿëjÓÿ^=Ëpõÿ÷7Ìh¶ðïüp!�òÀ:")æðþ„؃Lû=3jIŠMٟô`c�’² °Ò ß@aÐ`K€ûáÎ7ÜÎ|€ï­�°x€Ci7H
3À[€S�ܼþ`Ïb�5Àßà•€Ò€¹`¾ÀWƒ”:ޓ�nÄÉà?+Þ¹Ô¬8î°tá·×PÖì[J1èèж À h3€é·�ßÜ0ðp@YÀá0€/4€¨€¿wƊ¨Ø
4Kȉøwaœ½†1b�òBþàã>*à # +àb¼Áõ
5ö°

I applied the patch again. Cleared DR, performance and browser cache... this time I turned OFF all performance cache.

Worked

Turn back on ALL performance cache.

Worked.

It's possible I made an error when I applied that patch last night but I was pretty careful to double check.

The only thing different I did was turn off the all performance cache and load the site before turning it back on.

I'll watch carefully for an issue over the next week. I'm using FF3.5 B4 so I'll test a few other browsers.

Yani

#33 worked for me. Thank you!

Patch at #33 seems to work for the last 3 people who applied it and tested it.

I noticed there are two problems. One related to the wrong path to the java plugin for sifr3 reported here: #500288: sifr3 path wrong The other I could fix and had to do with font file names that were not stripped to a valid javascript variable name. I changed the following code:

      // Build JavaScript-safe variable name.
      $rule['fontname'] = preg_replace('@[^a-zA-Z0-9_-]@', '', $rule['font']);

... to ...

     // Build JavaScript-safe variable name.
      $rule['fontname'] = preg_replace('@\W@', '', basename($rule['font'], ".swf"));

Produces shorter and cleaner variable names preventing the javascript errors I experienced.

#33 appears to have solved the page freeze to white issue for me. Will keep an eye on it. Is the patch at #52 meant to apply on top of #33? Might be better to reroll a complete patch.

Patch #33 did NOT work for me. I'm on drupal 6.13. Here are my steps:

1. Install 6.x-1.x-dev render
2. patch with patch from #33
3. download latest nightly of sifr3
4. put sifr.js and sifr.css and sifr.fla into sifr directory

Doesn't work

5. tried renaming sifr.css to sIFR-print.css to match README.txt instructions

No dice! I downloading a font from sIFR fonts library (http://www.isarie.com/index.php?p=17) but that doesn't render eithere. Help!

Any idea what I'm doing wrong or what's going on? sIFR v2 does the random size bug for my website, so I'm needing to go to sIFR v3 to see if that fixes that issue. Thanks!

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

@com2: Let's move your patch to a separate issue, please.