Fontconfig has been used in several projects; these have all been done by the author, so future experiences with others will be of great interest.
Porting Mozilla to Fontconfig was really more like porting Fontconfig to Mozilla. The Unicode coverage and Language group information was added during this port. Because Fontconfig already provides font matching similar to CSS2, that was used in place of the existing Mozilla mechanisms which were designed only for core X fonts.
This port took approximately three days of time for two engineers and resulted in less than 1000 lines of new code. A patch is being maintained for the current Mozilla CVS sources and will be integrated into the main Mozilla source pool in time for version 1.1.
One interesting feature of this particular port was how much application code could be eliminated. The Unicode text API of Xft and the near-CSS2 font matching algorithm within Fontconfig replaced thousands of lines of application code. As Fontconfig migrates to a CSS2 compatible matching mechanism and some degree of automatic glyph substitution, the amount of application code can decrease while the functionality increases.
As Qt version 2 already contained support for the original Xft API, the expectation was that a port for version 3 would be relatively straightforward. Unfortunately, the Qt designers used a deprecated API within Xft for all text output. Replacing that API and associated datatypes was responsible for most of the work in this port.
Several kludges in the original Xft code were eliminated by capabilities present in Fontconfig, in particular the Unicode coverage eliminated the need to open every available font to discover what locales they were useful for. As the original Qt port of Xft was rapidly adopted into the main Qt source pool, it should be easy to get the new patch integrated as well. No new features were needed for this port.
Gtk+ 2.0 and Pango 1.0 both had support for the original Xft API, but that support was limited to X server supporting the Render extension as they both used the Xft API limited to the Render extension. Converting these to the more general API was relatively straightforward as both of them had reasonable abstractions for text output and rendering objects.
Within Pango, a copy of the original Xft library was discovered. It had been edited to allow use of the Xft configuration by applications not using an X display. This ``miniXft'' was replaced by direct calls to Fontconfig. Pango provides it's own internal Unicode coverage maps for fonts; instead of providing an abstract data type that could map to either the internal Pango map or the Fontconfig maps, a new API for Fontconfig was added that made enumeration of the available Unicode glyphs efficient. This new API was used to copy the mapping from the Fontconfig datatype into the Pango datatype. Obviously it would be more efficient to avoid this copy; perhaps future Pango versions could include such a change.