[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered
From: |
Po Lu |
Subject: |
Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion |
Date: |
Mon, 10 Mar 2025 17:51:49 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Sun, 9 Mar 2025 23:23:39 -0500, Stefan Kangas
>>>>>> <stefankangas@gmail.com> said:
>
> Stefan> Po Lu via Mailing list for Emacs changes <emacs-diffs@gnu.org>
> writes:
> >> branch: master
> >> commit 02681b0fbf02913cd474e082f67649f14115e4a6
> >> Author: Po Lu <luangruo@yahoo.com>
> >> Commit: Po Lu <luangruo@yahoo.com>
> >>
> >> Don't claim that xftfont is being considered for deletion
> >>
> >> * configure.ac: Don't claim that Xft is being considered for
> >> deletion or that recent releases are buggy, or imply that
> >> HarfBuzz support is exclusive to Cairo.
> >> ---
> >> configure.ac | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 9cd19bb6ae6..a3fc4e9fe5b 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -7865,9 +7865,8 @@ fi
> >>
> >> if test "${HAVE_XFT}" = yes; then
> >> AC_MSG_WARN([This configuration uses libXft, which has a number of
> >> - font rendering issues, and is being considered for removal in the
> >> - next release of Emacs. Please consider using Cairo graphics +
> >> - HarfBuzz text shaping instead (they are auto-detected if the
> >> + font rendering issues in its earlier releases. Please consider
> >> + using Cairo graphics instead (they are auto-detected if the
> >> relevant development headers are installed).])
> >> fi
>
> Stefan> When did we take the decision to make this change?
I did, just now, as the Xft build is the only means of rendering
anti-aliased glyphs without Cairo and the issues incident to that (see
below). I do so as the only person who has been maintaining this code
for three consecutive years, I might add.
> I guess you mean to *not* delete libXft support? If the issues
> surrounding support of color fonts have been fixed [1], then I have no
> objections, but I donʼt remember this being discussed.
Xft begun to support non-grayscale rasters in release 2.3.5. BTW, it is
trivial to reproduce the fundamental performance issue with image
transforms under Cairo by loading the gnu.org homepage in EWW and
scrolling across the scaled images that are displayed with
`pixel-scroll-precision-mode' enabled. Cairo builds must download,
transform, and upload transformed images to the X server, whereas the
standard X11 configuration applies transforms to server-side Pictures
directly.
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Stefan Kangas, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Po Lu, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Robert Pluim, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Visuwesh, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Po Lu, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Eli Zaretskii, 2025/03/10
- Re: master 02681b0fbf0 1/2: Don't claim that xftfont is being considered for deletion, Visuwesh, 2025/03/11