Re: Thoughts on font management

[Fred Kiefer]

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.

Fred