Re: Thoughts on font management

[Fred Kiefer]

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.
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.
And for the art backend your code would be a big improvement. You should
think about adding it there. Again perhaps as an option.

Cheers,
Fred

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