[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on font management
From: |
Fred Kiefer |
Subject: |
Re: Thoughts on font management |
Date: |
Fri, 30 Nov 2007 20:47:58 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070801) |
Isaiah Beerbower wrote:
> Hello all,
>
> A while back there was some discussion about the way GNUstep handles
> fonts. The two ways discussed were nfont bundles and fontconfig. I
> like nfonts because they give you more control over how your fonts are
> organized, but I also like the fontconfig method because it makes font
> installation easier for fonts which don't need to be organized beyond
> the computers knowhow. I would like to propose a new method which
> gives both advantages.
>
> If we used a GNUstep maintained font index plist as our only cache and
> used fontconfig + FreeType for retrieving information from font files
> except when we come across an nfont (in which case we would read its
> plist) we would receive many advantages from both sides:
>
> * Those who want to distribute a font family in a pre-organized way
> can do so using an nfont.
>
> * Those who don't, won't have to do anything.
>
> * Those who want to keep their fonts organized a specific way can
> either put them all into nfonts, or change values in the font index.
>
> * Those who don't care aren't bothered.
>
> * GNUstep gets to choose which folders get indexed.
>
> We can also put other information in the index (if we want) such as
> wether an installed font is enabled or not.
>
> The index I am envisioning at this point would be a plist with an
> array of dictionaries, each dictionary holding the path to a font
> file, the file's last modification date, the font's family name,
> postscript name, style, whether it should use anti-aliasing or not,
> etc., etc..
>
> I would like this for cairo, but if it can be coded once then used in
> art also, that would be great to.
>
> I'm ready to implement such a thing if acceptable.
>
Sounds like a nice idea to me, but I would prefer to see code, before I
judge on it :-)
As I understand it, the nfont model provides more information per font
than we can get from FT and FC. How would your code try to substitute
values for that?