Configurable font storage location (eg. /usr/share/fonts)

easy peasy

Impressive response time! Works for me :)

See also: #496240: sites/<site>/libraries: Standard place for thirdparty module requirements

thanks

however, before this can be committed, I think the issue at #465908: Scan: Name clashes should be decided on, as discussed in http://drupal.org/node/320562#comment-1720562

+1

+1.

I Have just had to fix a site which was messed up by the module update. I'd argue that standard update procedure breaking the site makes this a bug rather than a feature request.

I agree that searching for a directory that's just named 'fonts' is too likely to clash with some other library. Maybe it's better to search in /sites//libraries and /sites/all/libraries for a directory called 'captcha_fonts' rather than just 'fonts'.

Also, while TTF fonts can't and probably shouldn't be packaged, there are some fairly standard system locations like /usr/share/fonts which might be worth supporting. Granted those directories can often be cluttered with a bewildering range of options.

Andrew

I think "captcha_fonts" is not appropriate, because it's entirely possible to write other plugins that use fonts in images (think something like icanhascheezburger.com).

as I mentioned at http://drupal.org/node/320562#comment-1720606 , it might be worth making this sites/all/resources instead of libraries, because
a) fonts aren't code libraries, they're static blocks of useful information (in the same way as icons, backgrounds, and sound files are)
b) avoids name clashes (even though I think anyone who names their library "fonts" is a fool and should be punished ;) ).

Agree with the /usr/share/fonts (although this may be distro specific, and may not even exist on some servers (ie. those with no xorg?), and the analogue for windows.

How about giving the user a configuration setting to choose the path to look in? I'd love to have one single fonts folder for all of my vhosts to use, but the current config doesn't allow that. I've written a patch to add that functionality and it appears to work well.

at seanr in #7: I have my reservations about a webmaster configurable font storage location in the image CAPTCHA UI. Some random thoughts:

• You say you want one single font folder for all of your vhosts, but you already can do that if you share the image captcha module code over those vhosts: just use the font folder in the image captcha module folder or use /sites/all/resources/font (or whatever) when it is decided upon. Moreover, with a configurable font search path, you have to configure that path for every site separately, which does not feel like a win.
• I think that copying a font file or folder (or even creating symlinks) is easier and more intuitive than fiddling in the admin UI. I know the design pattern of a UI for configuring a path is used in other modules/parts of Drupal, but I think it's not a very user friendly/usable system. Having a file browsing widget instead of a text field would be nice though.
• the patch from #7 is not enough: it also needs some validation to check if the entered path is valid for better "fool-proofity" and I would add some more description about how relative paths would be handled.
• making the font search path changeable through the UI also introduces its own class of issues/edge cases/usability-wtfs: when you want to search in a different path you first have to enter the path, submit the form, load the same form again and only then you can select fonts from that folder. Other tricky issue: say you have configured a search path and font, for some reason (e.g. by accident) you change the search path, submit the form and then leave the form to do something else: the search path will be changed, but the original font will still be active (which is probably desired). Now, when later, you update something about the image CAPTCHA (e.g. add noise) and forget to check the font settings, the font to use will be overwritten and you get a crappy default or worse a failing image CAPTCHA. You could throw a lot of jQuery/AJAX magic at this to solve these kind of things but that feels like overkill to me.

my two late night cents, time to go to bed now :)

I went through this a lot when trying to find available fonts on different distros for my imagecache_textactions (and other similar)
- you do NOT know what the system path to scan for is on different OSs. '/usr/share/fonts' is only one possible location.
- You will trigger huge scary warnings if running on a server that enforces open_basedir

Adding a configurable location to the search path would be a good win, then you can re-use whatever central location you like. Adding a filebrowser is overkill, although I have set mine up to at least present a selector of all *.ttf found in all the search paths. That's adequate.
Screenshot from my (unrelated) project, fyi

soxofaan - we have several vhosts on our server, but we don't use the multiple site setup - we prefer to keep completely separate Drupal installs due to the work load involved in updating a particular site (module upgrades can cause all kinds of theme issues, etc.), so we'd really like to have the option to specify where our fonts are stored. For a user who doesn't wish to change that, the default path remains as-is and works well enough for most people.

I've updated my patch to include some validation.

BTW, the whole reason I got involved in this is because when I do a site update using Drush, it moves the entire captcha folder (including the fonts) to a backup directory and then downloads the new version, leaving me with no fonts and a non-working captcha. I REALLY need to get that font path outside of the captcha module's folder. People didn't like sites/all/libraries/fonts, so this patch was really the only alternative. To me, either of the patches in this thread would be fine, but doing nothing here really isn't a good option.

At seanr in #10:

Thank you for your work, and I agree that this issue has to be fixed in some way.
Putting custom fonts in image_captcha/fonts is indeed the wrong way, as updates (e.g. with drush) can break this.

About your patch: you replace the hardcoded image_captcha/fonts path with a user configurable font path.
The configurable font path should be appended to the list and image_captcha/fonts should be kept hardcoded: I'm planning to add some default fonts to the image_captcha package (in the image_captcha/fonts folder of course) for better usability (and it's always nice to have some kind of fallback). See issue #259219: provide a better default font for image CAPTCHA

So I think the user configurable font path should be empty (meaning disabled) by default, and the validation should also accept an empty string apart from valid paths.

For what it's worth: another alternative to avoid drush overwriting/removing you custom fonts, is putting the fonts in your 'files' directory, which is also searched for fonts by image CAPTCHA:

(tagging)

Hi,

I decided to commit the patch from #1:
http://drupal.org/cvs?commit=266866
so now fonts are also searched for in sites/all/libraries/fonts and sites/example.com/libraries/fonts.
This should already address a large part of this thread's feature request.
The discussion about other stuff is still open.