[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xlib backend - Xft without fontconfig
Re: xlib backend - Xft without fontconfig
Mon, 09 Aug 2010 20:56:37 +0200
Mozilla/5.0 (X11; U; Linux x86_64; de; rv:184.108.40.206) 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
> 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.