Re: Thoughts on font management

[Isaiah Beerbower]

On 12/11/07, Isaiah Beerbower <public@ipaqah.com> wrote:
> On 12/11/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> > Hi Isaiah,
> >
> > after six hours of sleep I think that my mail really sounds to negative.
> > Sorry for that. Would it be possible for you to rewrite your code to be
> > a compile time option? Lets say use a switch --enable-FontConfig with
> > the default being YES, if that software is installed? That way your
> > change wont interrupt my own development, whereas it is still easy to
> > switch on and test.
>
> Sure. I'll do that as soon as possible.

I've reverted back to using fontconfig only for now. I can add my code
as a compile time option later (when I have time).

> > On the other hand you should also have a look at the FontConfig
> > configuration file and see, what options you are missing there and try
> > to lobby the developers to integrate them. To me these solutions look
> > very similar.
>
> I'll take a look.

Actually, I like this solution much better. If fontconfig cached just
a few more things it would make the reason behind writing my code more
or less obsolete.

- Isaiah Beerbower

> > And for the art backend your code would be a big improvement. You should
> > think about adding it there. Again perhaps as an option.
>
> It would be fairly simple to add it to the art backend.
>
> >
> > Fred Kiefer wrote:
> > > Isaiah Beerbower wrote:
> > >> On 12/10/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> > >>> Isaiah Beerbower wrote:
> > >>>> On 12/10/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> > >>>>> Isaiah Beerbower wrote:
> > >>>>>> 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?
> > >>>>
> > >>> Fine for me.
> > >> Ok, its in trunk now.
> > >
> > > Now I have to admit that I completely misunderstood what you were about
> > > to do. I expected that you upgrade the art backend to be able to work
> > > together with FontConfig. But what you did was downgrade the cairo
> > > backend to work without FontConfig. I should have noticed from your last
> > > mail, but I really way to busy to look into the detail. My fault.
> > >
> > > Does this mean that I will have to set the full path to my fonts to get
> > > all the fonts back that I am currently able to use with cairo? And even
> > > then all the bitmap fonts will be missing? If this is that case, I would
> > > like to ask you to add a compile time switch to go back to the old
> > > behaviour. For the xlib backend we are currently supporting three
> > > different implementations of the font management, just to keep everybody
> > > happy.
> > >
> > > GNUstep is about choice, not about forcing people to use things in the
> > > one and only way. I don't mind if there are other ways to get the a list
> > > of usable fonts beside the FontConfig way. If you want nfont support in
> > > parallel, fine. If you want to force me to use nfont only, no way.
> > >
> > > GNUstep is also about standards. We try to use the standards that are
> > > already available. FontConfig is one of them. It is used in a variety of
> > > environments, by divers applications. Why isn't it good enough for
> > > GNUstep? What you implemented looks to me like a stripped down version
> > > of FontConfig. If we need to work with font cache files, then why not on
> > > the FontConfig ones? I don't want to keep yet another cache and
> > > configuration up to date when I move on to a different release of my
> > > base system.
> > >
> > > Sorry for sounding that negative. I know it was me how said you should
> > > go ahead, but this is just not what I expected and it looks like it is
> > > making live harder for me and other users of GNUstep.
> > >
> >
>
>
> --
> www.ipaqah.com
>


-- 
www.ipaqah.com