bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#17792: 24.3; hintstyle spewcified via fontconfig is ignored by Emacs


From: Jan Djärv
Subject: bug#17792: 24.3; hintstyle spewcified via fontconfig is ignored by Emacs
Date: Wed, 25 Jun 2014 10:32:16 +0200

Hello.

25 jun 2014 kl. 00:01 skrev James Cloos <cloos@jhcloos.com>:

>>>>>> "JD" == Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> JD> I don't know if cairo itself reads fonts.conf and/or X resources,
> JD> but I suspect it does.
> 
> No.  It uses the fontconfig api.

Thanks for the clarification.

> 
> This bug is a side effect of using xft to render fonts.  LibXft has a
> routine which edits the font pattern before passing on to libfontconfig;
> it adds pattern elements for each of:
> 
>  antialias autohint dpi embolden hinting hintstyle lcdfilter
>  maxglyphmemory maxunreffonts minspace render rgba scale
> 
> based on what it finds in the X Resources.
> 
> It always adds a pattern entry for each of those, with a default value
> if it doesn't find an explicit X resource.
> 
> Fontconfig is written to allow applications to override the default
> values specified in/via fonts.conf, on the reasonable theories that users
> should be able to tell apps to override them, and that some applications
> SHOULD avoid things like hinting, and therefore need a way to do that.
> 
> By forcing its own set of defaults, xft blocks any ability to set those
> via the xml.
> 
> Fixing this will either require changing libxft to avoid adding pattern
> elements for which explicit X Resources do not exist, or changing Emacs
> to use fontconfig, freetype and XRENDER directly, rather than via xft.
> 
> Handa-san's original code supported an fc: prefix for fonts, which was
> defined to do the above, but the xft: won out.


Emacs does have the ftx font backend that gets compiled if libXft is not 
present.
Unfortunately it seems a bit broken w.r.t. sizes (all fonts are too large), and 
also the Gtk+ code in Emacs assumes Xft.  Both of these could be fixed, and we 
could offer both backends.

Ftx does not use XRENDER btw, so I suspect it might be a bit slow.
Another approach would be to add a draw method to the Ft backend.  Currently it 
is just common code for Xft and ftx.

But it seems excessive to work around something that can be made to work anyway.

        Jan D.






reply via email to

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