Re: Thoughts on font management

[Isaiah Beerbower]

On 12/10/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 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.

I've already done both.

> 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.

Currently I have made changes in only three classes
(CairoFontEnumerator, CairoFaceInfo, & CairoFontInfo) and I've tested
it in several situations already and consider it stable.

The reason I asked is because you said "I would prefer to see code,
before I judge on it". Shall I put it in trunk then?

- Isaiah Beerbower

--
www.ipaqah.com