Patch is in master branch of my repo:

git+ssh://people.freedesktop.org/~behdad/fontconfig

Sample usage in:

http://svn.gnome.org/viewvc/pango/trunk/tools/gen-script-for-lang-new.c?view=markup

Another non-fontconfig user of orth files is dejavu  (used to generate a script coverage table at build-time so users and distribution packagers know what locales to check before deploying a new dejavu version).

That's a common need when a new font is proposed for inclusion in a distro, it's a shame only dejavu does it.

It's probably cleaner to just add a small tool that takes a ttf/otf file as input and outputs its script coverage table to fontconfig rather than expose the orth files themselves tough. The current dejavu method is a rather ugly orth-parsing perl script

uh, you can already get fontconfig to generate coverage information for a font file; just scan it and look at the resulting pattern. Seems like dejavu could create a fairly simple program to do this.

Well, if the dejavu folks where code-inclined, they'd be rewriting fontforge, not creating fonts

The aforementioned table is this one
http://dejavu.svn.sourceforge.net/viewvc/dejavu/trunk/dejavu-fonts/langcover.txt?revision=1922&view=markup

I try to write fc-scan to do just that...

Nicolas, the only thing DejaVu will lose is the language names.  They can of course use iso639 package to lookup language names.

Thanks! If we can have a nice standard tool we may even start adding a language coverage table in %doc to other font packages in Fedora. The table is a quick way for users to check their script is covered by foo font (which may or may not be a problem for them)

Should be ready to go in.  Renamed FcCharSetForLang() to FcLangGetCharSet() and pushed to my repo.

Please eliminate the 'optimizations' here that cache some of this computation; we don't expect these APIs to be heavily used, and I'd prefer to see simpler code in this case. Also, the documentation should go into the new fclangset.sgml file.

This appears to be the last bug standing before 2.5 can be released, although I need to do another scan over the debian bug database and add anything I find there.

Ah, just saw this message of yours.

(In reply to comment #8)
> Please eliminate the 'optimizations' here that cache some of this computation;
> we don't expect these APIs to be heavily used, and I'd prefer to see simpler
> code in this case. Also, the documentation should go into the new
> fclangset.sgml file.

Makes sense.  Will do this early tomorrow.
 
> This appears to be the last bug standing before 2.5 can be released, although I
> need to do another scan over the debian bug database and add anything I find
> there.

Updated my branch.  Had to fix a couple bugs in doc/edit-sgml.c to get it going too.