Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Robert Pluim]

Eli, is it too soon for this?

diff --git a/configure.ac b/configure.ac
index 592d745797..73d4c52e8b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5898,6 +5898,15 @@ m4_define
   esac
 fi
 
+if test "$with_xft" = yes; then
+AC_MSG_WARN([This configuration is compiled to use libXft,
+which has a number of font rendering issues, and is scheduled for
+removal in the next release of Emacs.  Please consider using cairo
+instead (cairo is auto-detected if cairo development headers are
+installed).])
+
+fi
+
 # Let plain 'make' work.
 test "$MAKE" = make || test -f makefile || cat >makefile <<EOF
 .POSIX:
diff --git a/etc/NEWS b/etc/NEWS
index d5a1d27267..60e1ddf25a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -28,6 +28,10 @@ applies, and please also update docstrings as needed.
 '--with-cairo' is now the default, if the appropriate development files
 are found by 'configure'
 
+** Configure now warns if using libXft.
+XFT support is scheduled for removal in emacs-29, so configure now
+warns about it and suggests cairo instead.
+
 \f
 * Startup Changes in Emacs 28.1
 

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 14 Jan 2020 11:45:28 +0100
> 
> Eli, is it too soon for this?

Hmm... soon? no, I don't think so.  I just am not sure this is the
best approach.  First, I don't think we have enough data and
experience to commit ourselves to remove Xft in Emacs 29, we should
first see how painful such a removal will be wrt our users.
Therefore, it might be better to turn Cairo ON by default on master,
and only use Xft if Cairo is unavailable.  If that proves to be a
reliable configuration (i.e., we aren't flooded by complaints about
the Cairo problems), then perhaps we will be able to remove Xft in
Emacs 29 after all.

WDYT?  If you agree, then instead of mentioning the removal in Emacs
29, I'd prefer saying in NEWS that Xft is not actively maintained and
has known problems with some modern fonts, and therefore we recommend
against using it, as long as alternatives are available, Cairo being
the best one of those.

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Robert Pluim]

>>>>> On Tue, 14 Jan 2020 18:00:26 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Tue, 14 Jan 2020 11:45:28 +0100
    >> 
    >> Eli, is it too soon for this?

    Eli> Hmm... soon? no, I don't think so.  I just am not sure this is the
    Eli> best approach.  First, I don't think we have enough data and
    Eli> experience to commit ourselves to remove Xft in Emacs 29, we should
    Eli> first see how painful such a removal will be wrt our users.
    Eli> Therefore, it might be better to turn Cairo ON by default on master,
    Eli> and only use Xft if Cairo is unavailable.  If that proves to be a
    Eli> reliable configuration (i.e., we aren't flooded by complaints about
    Eli> the Cairo problems), then perhaps we will be able to remove Xft in
    Eli> Emacs 29 after all.

Turning on cairo by default I did earlier today in
88efc736f562656efab778d35c32d549ef6270d7 . That automatically ends up
not using Xft if Cairo is detected.

    Eli> WDYT?  If you agree, then instead of mentioning the removal in Emacs
    Eli> 29, I'd prefer saying in NEWS that Xft is not actively maintained and
    Eli> has known problems with some modern fonts, and therefore we recommend
    Eli> against using it, as long as alternatives are available, Cairo being
    Eli> the best one of those.

OK, I can go with that.

Robert

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Stefan Monnier]

> +** Under X, some characters are unexpectedly wide.
> +
> +e.g. recent versions of Inconsolata show this issue for almost all of
> +its characters.  Due to what is probably an Xft bug, the determination
> +of the width of some characters is incorrect.  One workaround is to
> +build emacs with Cairo enabled ("configure --with-cairo" and have the
> +appropriate Cairo development packages installed) as this
> +configuration does not suffer from this problem.  See
> +<https://github.com/googlefonts/Inconsolata/issues/42> and
> +<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00456.html>
> +for more discussion.

Does the use of Harfbuzz affect the result?


        Stefan

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Robert Pluim]

>>>>> On Tue, 14 Jan 2020 08:57:52 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> +** Under X, some characters are unexpectedly wide.
    >> +
    >> +e.g. recent versions of Inconsolata show this issue for almost all of
    >> +its characters.  Due to what is probably an Xft bug, the determination
    >> +of the width of some characters is incorrect.  One workaround is to
    >> +build emacs with Cairo enabled ("configure --with-cairo" and have the
    >> +appropriate Cairo development packages installed) as this
    >> +configuration does not suffer from this problem.  See
    >> +<https://github.com/googlefonts/Inconsolata/issues/42> and
    >> +<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00456.html>
    >> +for more discussion.

    Stefan> Does the use of Harfbuzz affect the result?

I see this in an XFT build both with and without Harfbuzz.

Robert

Re: emacs-27 7ec66a5: Document spacing issues with Xft for some fonts

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 14 Jan 2020 15:17:45 +0100
> Cc: emacs-devel@gnu.org
> 
>     Stefan> Does the use of Harfbuzz affect the result?
> 
> I see this in an XFT build both with and without Harfbuzz.

Which is expected: we only call HarfBuzz for character composition,
not for "simple" text such as ASCII.  Otherwise, we use the glyph
metrics as returned by the lower-level facilities, in this case the
Xft API that returns the "text extents".