Add jITR/DynaText plugin

I've created a similar technology some months ago, which I was not able to release yet. I'll have a look at your script.
However, it would be great if you could post a patch - see http://drupal.org/patch/create

Hi Daniel, if you've already done this, you might prefer to release your own work then? Given that my files are a plugin so all new files (not alterations to existing files), is a patch still the best way to offer this?

Yes, I plan to publish a release of that script. We spent weeks for cross-browser compatibility. However, I can't predict when time will permit this. Additionally, it's based on plain JavaScript - so your jQuery based approach might work faster/better, who knows.

A patch would be the easiest way for me (and others) to test your code. That is only possible if you create a patch against a CVS checkout. http://drupal.org/patch/create contains further information about the -N switch and how you can add files to your local working copy (without having privileges to add files to CVS).

Good luck for publishing your script - I hope you find the time to do it. If you get a chance to look at my plugin, let me know.

It seems a patch file can't create a directory. Therefore I've included two patch files - jitr_jitr.patch creates files that go inside the 'jitr' directory that you must create. 'jitr_plugins.patch' creates files for the plugins directory. The patch also won't copy the .png of course, so you will have to grab that from the archive in my first post.

I can't see how this is easier, but I hope this helps.

bump

Sorry for not responding -- I'm currently finishing a rather large project and just don't have time to follow-up on all issues.
However, this one is already on my task list (for later), so please don't worry.

Subscribing.

I'd like to commit this, however:

1) jquery.jitr.js contains a copyright/license statement, and everything on drupal.org is automatically licensed under the GPL. Did you ask the author Jamie Thompson for permission to convert his code to GPL?

2) There are (minor) coding-style issues. If this hits CVS, I will do a thorough review and a follow-up patch will be required.

3) If I commit this, will you keep hanging around here, fix bugs, ensure updates and answer support questions of users regarding jitr?

Jamie Thompson said he'd be happy for it to be used in a Drupal module. Obviously the code will have to be reviewed. I'd be happy to hang around & fix bugs, particularly for a Drupal 6 release.

+1

I would like to add this now. However, we need to get the code in shape before.

- Originally, it was never planned to distribute plugins directly with Dynamic Rendering (most often caused by licensing issues). If we create a jitr sub-directory now, we should probably create a sifr directory, too. And that said, I was also thinking about moving files around - wouldn't it be better if all files of a plugin would reside in one directory? Or is it cleaner to separate module and external library files?

- I have searched for jITR on the net, but did not find any page about it. Based on the links in the README.txt, isn't this either "jQuery jITR" or "DynaText"?

Aside from that, I have cleaned up the coding style of all files (including library files). I think the code is ready to go after another review. However, I'd like to solve the previously mentioned points first.

I think it would be better if all a plugin's files were in its own directory, then everything to do with that plugin is in one place. Jitr was the name Jamie Thompson used for his script, so it seemed sensible to use that name.

If it was never planned to distribute plugins directly with Dynamic Rendering, I'd be happy to contribute 'jitr' as a separate module (though it would be nice to be able to plug in to the menu hook to clear cache that I mentioned in my original post). However, if you want to include it in Dynamic Rendering, that would be great.

I didn't mean that jitr should be separate module. I was just identifying the fact that the directory layout of Dynamic Rendering is not yet prepared for directly distributed plugins. And I'm fine with changing the layout as well as distributing plugins directly with Dynamic Rendering (as long as they are (re)licensed under the GPL). So we're proceeding in the right direction.

I also think that having all files in one folder is better than having the basic support file, logo image and README.txt in a separate location. However, that means that we need to

1) move the existing files around and ensure that everything is still working properly
2) setup a naming function for plugin include files, since we need to search for them in all sub-directories of render.module. I thought of either always re-using the directory name, i.e. sifr/sifr.inc, or requiring a certain name, such as sifr/plugin.inc or sifr/render.inc. I don't know what would be safer - the only name clash could happen if there was a plugin that ships with an identical filename, i.e. if jitr would rely on a jitr.inc instead of heading.php, for example.

Last, but not least, I think we should rename this plugin to DynaText, because this was the original name used in the ALA article, and one finds much more sites (and perhaps help/support) in search engines when searching for that name. [Actually, you find no relevant sites when searching for "jitr"...]

Any feedback to my last post?

Regarding 1), moving existing files around basically means that this will lead to version 2.x of this module. Otherwise, existing users would expect that 5.x-1.2 is a minor bugfix release and they can update their module without any hazzle. Because we agreed on this point already, this issue needs work.

is this method the least bandwidth consumption??

sifr looks to load the whole flash font of about 20k or so

is it in D6?

@chasz: Please do not hi-jack existing issues. If you have support questions about the sIFR library, please post them in sIFR forums (and not for this Drupal module); if you have a support question about Dynamic Rendering module for Drupal (this project), then please post a new support request in the queue. Thanks.

It seems a pity to not use Jamie's name seeing it's his jquery code that inspired this plugin, but if you wish to rename it, go ahead. As long as the plugin can link in to the menu hook giving users the option to clear the jitr cache I'll be happy. I'm not sure it matters too much about the naming functions for plugin files ... as long as things are consistent.

Quick update: While working on Wysiwyg API it turned out that placing external libraries into a module folder is not a good idea regarding module updates. This consideration might look OT for this plugin, but it affects the thinking in #14, because if external libraries are moved to somewhere else in the filesystem, I see no need to move around plugin support files at all.

Hi Sun ... what's the status of this? My jitr code from May was integrating with DR - it didn't touch any of the original Dynamic Rendering files, as Dynamic Rendering was initially written to accept plugins. If you'd rather not have the headache of cleaning-up, including & maintaining it though, perhaps it might be better if I submit it as a separate module?

I have tried the module uploaded on the main post of this issue. Sorry I haven't tried the latest patch because it seemed that more work was required before testing. The module seemed to work, however, I have two small comments, not sure if any of those apply to the further patches.

1. I found a blank line after the php closure on heading.php. This may lead to unwanted whitespaces thrown to the browser. Please read http://drupal.org/coding-standards (PHP Code Tags) for more details about this. I would suggest removing the ?> closing tag altogether.

2. There seems to be a case sensitive problem on the file names. Not sure if this is an issue on the jitr module, the render module or how the form file field is configured, but if the filename extension is other than .ttf (in lowercase), the font is accepted and uploaded but not listed on the manage screen (probably because it's not on the db either).

Has there been any progress on this?

I'm curious if DynaText/jitr was ever turned into a module.

@ auzigog - it was a working module when I submitted it in May 08.