[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: |
Mon, 10 Dec 2007 13:37:16 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070801) |
Isaiah Beerbower wrote:
> On 12/1/07, Isaiah Beerbower <public@ipaqah.com> wrote:
>> On 11/30/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>> 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 :-)
>> In that case I'll write some ...
>
> I have an almost complete implementation working with the cairo back
> end. Should I create a new branch for it under /libs/back/branches?
> This is my first contribution to GNUstep, which is why I ask.
The first thing you need to do is of course to assign the copyright to
the FSF :-)
After that you should be able to get write access to the SVN repository.
Whether we need a separate branch for this change depends on the amount
of code that changes and on how stable the change is in the beginning. I
prefer to work on the trunk, so that people will actually test the
changes I make. But this is only advisable if you are willing to correct
any problems very fast.
Cheers,
Fred
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/01
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/09
- Re: Thoughts on font management,
Fred Kiefer <=
- Message not available
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/10
- Re: Thoughts on font management, Fred Kiefer, 2007/12/10
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/10
- Re: Thoughts on font management, Fred Kiefer, 2007/12/10
- Re: Thoughts on font management, Fred Kiefer, 2007/12/11
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/11
- Re: Thoughts on font management, Isaiah Beerbower, 2007/12/11