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: Fred Kiefer
Subject: Re: xlib backend - Xft without fontconfig
Date: Mon, 09 Aug 2010 20:56:37 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

Am 08.08.2010 21:10, schrieb Derek Fawcus:
> On Sun, Aug 08, 2010 at 04:52:28PM +0200, Fred Kiefer wrote:
>>> This then eases some other clean ups and fixes I spotted.
>>
>> Removing some unused, broken or just left over code is always a good
>> idea and the xlib backend is surely the place where we have the most of
>> this still lying around. But we must also make sure that we don't force
>> people to use technology that isn't available on their system.
>>
>> In this specific case you failed to explain the benefit we would be able
>> to gain by your clean ups that currently aren't possible.
> 
> True;  but then I thought that the clean up of the Xft using code stood on
> its own merits,  and did not need my subsequent suggestions.
> 
> 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 :-)

>   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 have managed to make the Xft font code do more than simple pixel
> scaling,  by using the font matrix.  So more of the output with my
> Matrix.app test program is correct - or at least more closely matches
> the results seen with the cairo and art backends.  See the attached
> xft image.

Great. At the moment we aren't putting much effort in to any other
backend than cairo, but if somebody contributes code to the other
backends or even a new one this is fine for me.


>> Still you are surely right that who ever is still using Xft 1 could as
>> well update to Xft 2 or fall back to standard xlib fonts without losing
>> much. (Even Riccardo is using Xft 2 and that says a lot)
> 
> Well;  I seriously doubt that anyone is using xft-1.
> 
>> I even wouldn't mind to drop support for XGFontSetFontInfo, which is
>> broken anyway. What I would like to keep is the ability to not require
>> Xft. I hope that nobody is using XGFontInfo, but it should still be
>> around when somebody needs it. At least for a bit more time. I still
>> expect that we all be able to make the move over to a backend based on
>> Eric's Opal code. Which just reminds me to check out this code...
> 
> I'd say leave both of XGFontSetFontInfo and XGFontInfo in the xlib code.
> 
> However,  I'm tempted to create an X render backend that depends on
> the use of the render extension.  Just for the simplicity,  I've been
> finding playing with the xlib backend to be a useful/simple was of testing
> behaviour.  In which case I'd suggest renaming the xlib backend to
> xcore (or corex)...
> 
> As far as I can see,  said render backend could be generated by relatively
> simple mapping from the existing art backend code.  The only bit that the
> render extension seems to lack is native bezier code,  so it'd have to
> 'steal' it from some of the existing code - possibly the xlib code.
> 
> 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.



reply via email to

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