Re: xlib backend - Xft without fontconfig

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

  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.

  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.

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

DF