all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Pieter van Prooijen <pieter.van.prooijen@teloden.nl>
Cc: Eli Zaretskii <eliz@gnu.org>, 54564@debbugs.gnu.org
Subject: bug#54564: 29.0.50; [PATCH] Use gsettings font rendering entries for pgtk builds
Date: Wed, 30 Mar 2022 16:59:19 +0800	[thread overview]
Message-ID: <87bkxnx1co.fsf@yahoo.com> (raw)
In-Reply-To: <88d833f72df4f4cbb5769f1a75057d3f957a812c.camel@teloden.nl> (Pieter van Prooijen's message of "Wed, 30 Mar 2022 10:01:49 +0200")

Pieter van Prooijen <pieter.van.prooijen@teloden.nl> writes:

> Here's the second version of my patch to use the gsettings for font
> rendering:

Thanks.

> When playing around with the font settings, I noticed that cairo/pgtk
> doesn't seem to use the subpixel antialias (e.g. cleartype style)
> rendering setting, even though that option is set. I'll investigate
> further, it doesn't look like a regression due to this patch, but
> existing behavior.

It works here for me, so I don't know why you're seeing that behavior.
There could be something wrong with fontconfig on your system.

Some minor comments below:

> * src/ftcrfont.c (ftcrfont_open): Use the font_options derived from gsettings
>   when opening a font.
> * src/ftcrfont.c: (ftcrfont_cached_font_ok): Report a cached font as invalid
>   if its font options differ from the current gsettings ones.
> * src/xsettings.c, src/xsettings.h (xsettings_get_font_options): Retrieve the
>   current gsettings derived cairo font_options.
> * src/xsettings.c (apply_gsettings_font_hinting): Convert the gsettings hint
>   setting to the font_options struct.
> * src/xsettings.c (apply_gsettings_font_antialias): Convert the gsettings
>   antialias setting to the font_options struct.
> * src/xsettings.c (apply_gsettings_font_rgba_order): Convert the gsettings
>   rgba order setting to the font_options struct.
> * src/xsettings.c (init_gsettings): Invoke the apply functions when
>   initializing from gsettings.
> * src/xsettings.c (something_changed_gsettingsCB): Invoke the apply functions
>   if the relevant gsettings changed.
> * src/xsettings.c (store_font_options_changed): Store an event to re-render
>   the fonts.

Please don't indent the first asterisk of the filename inside the commit
message, or the other lines of the text, and don't repeat the filename
for each change within the same file.  (You can type C-c C-w inside the
*vc-log* buffer to generate an appropriate commit message.)

In many cases there is also no need to repeat the same description of
a change with changes to a single word.

Here is how I would write the commit message (make sure the entire
message is no wider than 64 characters):


* src/ftcrfont.c (ftcrfont_open): Use the font_options derived
from gsettings when opening a font.
(ftcrfont_cached_font_ok): Report a cached font as invalid if
its font options differ from the current options inside
gsettings.

* src/xsettings.c (apply_gsettings_font_hinting)
(apply_gsettings_font_alias, apply_gsettings_font_rgba_order):
Convert the settings from GSettings to the cairo_font_options_t
object.
(init_gsettings, something_changed_gsettingsCB): Invoke the
apply functions if the relevant settings changed.
(store_font_options_changed): Store an event to re-render the
fonts.
(xsetting_get_font_options)
* src/xsettings.h (xsettings_get_font_options): New function.

> +/* Determine if the cached font should be re-opened, by comparing
> +   its font_options with the ones derived from gsettings.  */

I would say "determine if FONT_OBJECT is a valid cached font for
ENTITY by comparing the options used to open it with the user's
current preferences specified via GSettings".

> +static void
> +store_font_options_changed (void)
> +{
> +  if (dpyinfo_valid (first_dpyinfo))
> +    {
> +      store_config_changed_event (Qfont_render,
> +                                  XCAR (first_dpyinfo->name_list_element));
> +    }
> +}

Please remove the extra braces in this if statement.

> +#ifdef HAVE_PGTK
> +  else if (strcmp (key, GSETTINGS_FONT_ANTIALIASING) == 0)
> +    {
> +      apply_gsettings_font_antialias (settings);
> +      store_font_options_changed ();
> +    }
> +  else if (strcmp (key, GSETTINGS_FONT_HINTING) == 0)
> +    {
> +      apply_gsettings_font_hinting (settings);
> +      store_font_options_changed ();
> +    }
> +  else if (strcmp (key, GSETTINGS_FONT_RGBA_ORDER) == 0)
> +    {
> +      apply_gsettings_font_rgba_order (settings);
> +      store_font_options_changed ();
> +    }
> +#endif /* HAVE_PGTK */
>  }

Once again, please reword these tests as !strcmp (key, ...

> +  /* Only use the gsettings font entries for non-X11 cairo backends
> +     (which is the recommended way of running pgtk builds).
> +     For the X11 backend cairo will apply these entries itself,
> +     reading them from xrdb.  */
> +#ifdef HAVE_PGTK
> +  font_options = cairo_font_options_create ();
> +  apply_gsettings_font_antialias (gsettings_client);
> +  apply_gsettings_font_hinting (gsettings_client);
> +  apply_gsettings_font_rgba_order (gsettings_client);
> +#endif /* HAVE_PGTK */

This should say "the Cairo backend running on PGTK".

> +/* Return the cairo font options, updated from the gsettings font
> +   config entries. The caller should call cairo_font_options_destroy
> +   on the result.  */

This needs two spaces between "entries." and "The".

> +#ifdef HAVE_PGTK
> +#include <cairo.h>

Please move this include to the top of the file.

Otherwise, LGTM.  Thanks for working on Emacs.  Have you completed the
necessary copyright paperwork?





  reply	other threads:[~2022-03-30  8:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25 11:23 bug#54564: 29.0.50; [PATCH] Use gsettings font rendering entries for pgtk builds Pieter van Prooijen
2022-03-26  1:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-26  6:01   ` Eli Zaretskii
2022-03-26  6:07     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-26  6:20       ` Eli Zaretskii
2022-03-26  6:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-26  7:45           ` Eli Zaretskii
2022-03-26  8:11             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-26  9:36           ` Eli Zaretskii
2022-03-26 15:48           ` Pieter van Prooijen
2022-03-27  0:59             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-30  8:01               ` Pieter van Prooijen
2022-03-30  8:59                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-03-31 17:30                   ` Pieter van Prooijen
2022-04-01  2:00                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-07 19:24                       ` Pieter van Prooijen
2022-04-07 23:38                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 18:44                           ` Pieter van Prooijen
2022-04-09  0:35                             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-13 11:38                             ` Pieter van Prooijen
2022-05-13 11:55                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-13 11:57                                 ` Lars Ingebrigtsen
2022-05-13 12:12                                 ` Eli Zaretskii
2022-05-13 12:51                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkxnx1co.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=54564@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=pieter.van.prooijen@teloden.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.