On 12/10/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Isaiah Beerbower wrote: > > On 12/1/07, Isaiah Beerbower <[EMAIL PROTECTED]> wrote: > >> On 11/30/07, Fred Kiefer <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
