* Source/fontconfig/FCFaceInfo.m (-matchedPattern): Cache the
resolved pattern and return this. The method characterSet now uses
this cached pattern.
Patch by Josh Freeman <gnustep_lists@twilightedge.com>
Some simple code for getting access to the main SFNT tables used for
drawing the right glyphs in the right ways. It's hidden with an "#if 0" for
future use.
Rather than sorting fonts by the integer value of "traits", let's sort by
the traits we are looking for specifically. Again, like many other things,
totally correct handling of this stuff will have to wait for a good method
of inspecting and correctly processing SFNT tables.
Fontconfig's font weights are almost but not entirely defined by the
constants found in its source code. Things like FC_WEIGHT_LIGHT are not,
as we had presumed, a list of definitive weights. As such, it seems there
are a goodly number of fonts that have weights not appearing in the list.
For example, say there's a font that is heavier than Medium (weight 100 for
fontconfig, and 6 for us) but not as heavy as Demibold (FC: 180, GS: 7),
then it might tell Fontconfig it has a weight of 130.
When this happens, we _could_ assign its NSWeight to be 6 or 7, but it's
possible that there will be another face in that font that ALSO fits there,
which might throw off the sorting. Instead, what I suggest is to do what
I have done...assign an NSWeight with a weight class that represents the
numeric distance _between_ the two defined values.
So the GS weight for this font face becomes something like:
NSWeight = 6 + ((FCWeight - Medium) * (1.0 / (Demibold - Medium)))
or, in numeric terms, 6 + 0.375
In service of this change, I have switched the actual Weight value within
the font dictionary from int to float. This is an attempt to translate this
situation into a sortable form we can work with, compressing an approximate
range of possible FC font weights into our 0-15 system.
There may well be a better way to go about this, such as figuring out where
fontconfig gets this info in the first place and converting from the source
directly, but accessing the SFNT tables (which will almost certainly be
required) is something for a later day.
Can't use fullname ALL the time, because some (mostly Adobe) fonts store
a duplicate of their PostScript name in the fullname field (and for that
case, we can just do what we already did), but it works well for just about
everything else.
GNUstep's font architecture makes it extremely difficult and annoying to
have a properly sorted font panel (or even one that makes any sense at all).
This might not be the best place to implement font sorting, but I'll be
damned if I can find a better one. The font enumerator knows where to look,
and has all the information needed to do it.
So, once we've enumerated all the fonts, sort them with a function that's
only slightly more clever than alphabetizing them. We sort by these
criteria, in order of importance:
1. font weight
2. traits (numeric ordering)
3. style name, with special cases so "Regular"/"Normal"/"Roman" sort
earlier than other stuff (caption, titling, etc.)
This sorting function seems to work about as well as can be expected,
producing the obvious "Regular"/"Italic"/"Bold"/"Bold Italic" for
undemanding families, while getting more advanced ones (like, say, the 168
font faces of Kepler Std) pretty close.
GNUstep has been bending over backwards to deal with fontconfig's baffling
lack of support for PostScript-style font names, just as it bent over
backwards to deal with XLFD's lack of same. Luckily, the fontconfig guys
have done us (and let's be honest, ghostscript and every pdf reader in
creation) a solid, and now that it's here it would be downright criminal
to not use it.
Implement it. :)
Fixed a bug in CairoGState: a NSDebugMLLog() had this obvious mistake in its format (as was printed out by the compiler): @"%self"
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/back/trunk@37066 72102866-910b-0410-8b05-ffd578937521
