gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xlib backend - Xft without fontconfig


From: Derek Fawcus
Subject: Re: xlib backend - Xft without fontconfig
Date: Mon, 9 Aug 2010 14:13:28 -0700
User-agent: Mutt/1.4.2.3i

On Mon, Aug 09, 2010 at 08:56:37PM +0200, Fred Kiefer wrote:
> Am 08.08.2010 21:10, schrieb Derek Fawcus:
> > Anyway,  the extra stuff is:
> > 
> >   The other bits of code in setupAttributes querying FC params for the
> > pixel sized font are unnecessary (all of the bits related to traits and
> > weight),  and seem to be a consequence of a simple bug in the initial
> > FC scan code.  They can be removed when the other (one line fix) bug
> > is dealt with.
> 
> Could you please provide this bug fix as well :-)

Sure,  I'll have to dig back in my git repository.

> >   The FC enumerator is almost identical between the Xft and the cairo
> > backends - it can be shared (not suprising giving that it looks like
> > that bit of the cairo code was simply copied from the Xft code).
> > I split it out in to a pair of classes: FcFontEnumerator and FcFaceInfo;
> > then a specialisation of the FcFaceInfo for Cairo use.
> 
> The problem with sharing that code is that only even one of these
> directories will be compiled at a time. We could of course copy the file
> at compile time (I think we already do something like this for the font
> cache).

I thought we could possibly create a Source/font directory,  move the
various enumerators and font info's there,  then have the makefile
build them as necessary (since the X backends currently compile from
multiple directories,  the mechanism is there - somewhere).
But I've not tried that yet.

> > This should the have the behaviour of the art backend,  but with similar
> > advantages to using the xlib backend.
> 
> I don't see the big advantage of such a backend over a cairo based
> backend that wont just use xrender but also all other available
> extensions of a specific system. But as I said, I wont stop you from
> contributing this code, as long as it doesn't break other stuff too badly.

Well,  its probably not a 'big' advantage.  Fewer dependancies,  and
possibly simpler code.  However,  the real advantage (to me) is learning;
since ultimately I fancy trying to create a backend for wayland,  if/when
enought of it is upstream to easily build;  that would I suspect be based
on the cairo backend.

The other advantage is/was subject to some discussion and debate previously,
so maybe you don't view it as an advantage: the use of the nfont mechanism.
I'd like to see the cairo backend have the option (at compile time) to use
nfont rather than fontconfig.

I also suspect that there is some scope for taking advantage of code in
the art backend within the cairo backend,  if that code gives better results,
i.e. refactoring.  Simply because all of art, cairo,  and Xft ultimately
make use of freetype.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]