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: Sun, 08 Aug 2010 16:52:28 +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 05.08.2010 18:30, schrieb Derek Fawcus:
> I've been looking at the xlib backend,  specifically the Xft
> text rendering support.  From looking at it,  I believe the
> parts intended to cope with fontconfig not existing should
> simply be discarded.
> 
> It has two effects,  it allow Xft version 1 to be used,
> (since it preceeds the existance of fontconfig),  and it
> uses the Xlfd matching part of Xft.  The latter seems to
> be pointless (since Xft 1 supported a built in prototype
> fontconfig like matching facility),  broken (the way the
> xlfd list passed in is built depends upon local fonts),
> and a waste (since the X core text support copes with
> xlfd patterns).
> 
> It would appear that these date from quite some time ago,
> Xft version 1 is obsolete (version 2 has existed since
> at least sometime in 2002),  and I believe anyone using
> Xft now will have version 2.
> 
> So I propose that GSXftFontInfo.m be updated such that:
> 
> all code protected by HAVE_FC be unconditional
> the code in the #else part of -setupAttributes be removed
> 
> and similarly in XGContext.m make the code protected by HAVE_FC be 
> unconditional.
> 
> 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.
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)

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





reply via email to

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