GNU bug report logs - #35781
Make Cairo build obey hint-style font setting

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35781 in the body.
You can then email your comments to 35781 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; [PATCH] Improve font display on Cairo builds
Date: Fri, 17 May 2019 19:39:12 +0200

[Message part 1 (text/plain, inline)]

Hi,

The attached patch makes fonts in the Cairo build more readable[1] on
some setups I use.

[cairo-style-hint.patch (text/x-diff, inline)]

diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index e7c73eac4d..51890dc18c 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -146,6 +146,7 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
       cairo_matrix_init_scale (&font_matrix, pixel_size, pixel_size);
       cairo_matrix_init_identity (&ctm);
       cairo_font_options_t *options = cairo_font_options_create ();
+      cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_SLIGHT);
       ftcrfont_info->cr_scaled_font =
 	cairo_scaled_font_create (font_face, &font_matrix, &ctm, options);
       cairo_font_face_destroy (font_face);

[Message part 3 (text/plain, inline)]

More context: I started trying out builds --with-cairo recently to
check out Emacs's support of multicolor fonts.  While these fonts seem
to work fine (emojis! 🙌), I found that the fonts for regular text
look… sharper?  In an aggressive-and-too-contrasted kind of way?

This screenshot shows the difference on one of my desktops[2]:

[desktop.png (image/png, attachment)]

[Message part 5 (text/plain, inline)]

Each frame is a different instance of 'emacs -Q'.  The left one is
configured without Cairo, the middle one --with-cairo *with my patch
applied*, the right one --with-cairo without my patch.

Same visual difference on my laptop[3]:

[laptop.png (image/png, attachment)]

[Message part 7 (text/plain, inline)]

Each frame is a different instance of 'emacs -Q -fn "DejaVu Sans
Mono-9"'[4].  The left frame is configured --with-cairo, without my
patch; the top-right one is without cairo, the bottom-right
--with-cairo with my patch.

On the third setup I could test[5], all three builds look the same
AFAICT; no idea what this can be attributed to.


Does this patch look like something that can be applied
unconditionally?

- CAIRO_HINT_STYLE_SLIGHT has been available from version 1.0, and we
  require 1.12, so AFAICT the setting can be used without checking for
  any CAIRO_… feature.

- On the other hand, maybe this setting should be conditioned by a
  user option: as far as I could test, …_SLIGHT gives the "best"
  visual result[6], but maybe this is specific to my setups.

  I guess that a customizable option would need to specify a :set
  function tasked with making a few Cairo calls for the change to be
  effective without restarting; I have not spent much time looking at
  ftcrfont.c and its users yet, but I imagine that this hypothetical
  setter function should do something along the lines of:

  1. retrieve all 'struct font_info' objects created with
     ftcrfont_open,
  2. call cairo_scaled_font_get_font_options on their 'cr_scaled_font'
     field,
  3. call …set_hint_style on the returned options.

  (… This is absolutely untested guesswork.)


Caveat: I do not know the first thing about font rendering (or any
kind of rendering for that matter), nor font hinting.  This patch is
the result of me googling around for "cairo smooth font" and trying
out random snippets to tweak cairo_font_options_* knobs.  Some
snippets I have seen call …set_{antialias,subpixel_order} in
conjunction with …set_hint_style; as far as I tested, the former two
have no impact, so I left them out of the patch.


Let me know if I should provide more information (font configuration,
results after tweaking other settings… though I cannot access my
desktops until Monday), and thank you for your time!


[1] Objectively-speaking, the patch merely makes fonts "visually
    equivalent to the non-Cairo build"; whether it makes them "more
    readable" is a matter of taste I guess.

[2] OS: Xubuntu 16.04 (libcairo2: 1.14.6)
    xrandr digest: DP-2 1920x1080 509mm x 286mm
    emacs-repository-version: … probably a commit on master from these
                              past two weeks

[3] OS: Debian stretch (libcairo2: 1.14.8)
    xrandr digest: LVDS1 1024x600 230mm x 140mm
    emacs-repository-version: e0ee41d155b210327eb9c9ad5334f80ed59439f4

[4] emacs -Q defaults to a bigger font size than what I use, and the
    "sharpness" difference is less visible then.

[5] OS: openSUSE Tumbleweed (cairo: 1.16.0)
    xrandr digest: DVI-I-0 1680x1050 474mm x 296mm
    emacs-repository-version: … probably a commit on master from these
                              past two weeks

[6] Compiling with any other enum value looked equivalent to not
    setting this option at all IIRC.



In GNU Emacs 27.0.50 (build 3, i686-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2019-05-13 built on nc10-laptop
Repository revision: d2d4916046e31e46598f0a0edbc65e75b8cb4cc3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: BunsenLabs GNU/Linux 9.8 (Helium)

Recent messages:
nnimap read 178k from imap.gmail.com (initial sync of 11 groups; please wait)
nnimap read 222k from imap.gmail.com (initial sync of 11 groups; please wait)
nnimap read 257k from imap.gmail.com (initial sync of 11 groups; please wait)
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Checking new news...done
nnimap read 0k from imap.gmail.com
No more unseen articles
Mark set
Quit [2 times]

Configured using:
 'configure --with-xwidgets'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF
XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  minibuffer-depth-indicate-mode: t
  icomplete-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  electric-pair-mode: t
  diff-hl-flydiff-mode: t
  global-diff-hl-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug rect cl-print debug backtrace magit-extras magit-patch
magit-subtree magit-ediff ediff-merg ediff-wind ediff-diff ediff-mult
ediff-help ediff-init ediff-util ediff org-indent org-rmail org-mhe
org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex
bibtex org-bbdb org-w3m org-element avl-tree org org-macro org-footnote
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs bug-reference magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process magit-mode transient git-commit magit-git magit-section
log-edit pcvs-util add-log with-editor async-bytecomp async server
url-util sendmail nnir eieio-opt speedbar sb-image ezimage dframe
gnus-fun shr-color color shr svg dom browse-url sort gnus-cite
mm-archive mail-extr gnus-async gnus-bcklg qp gnus-ml nndraft nnmh
nnfolder utf-7 epa-file gnutls network-stream nsm gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view
mml-smime smime dig mailcap nntp gnus-cache gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc
nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus nnheader
find-func help-fns radix-tree conf-mode magit-utils crm dash jka-compr
pulse find-dired ffap etags fileloop generator xref cus-edit wid-edit
whitespace notifications dbus xml thingatpt noutline outline view
message rmc puny dired dired-loaddefs format-spec rfc822 mml mml-sec epa
derived epg gnus-util rmail rmail-loaddefs text-property-search
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader flyspell ispell executable shell pcomplete misearch
multi-isearch vc-mtn vc-hg cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs footnote rx vc-git vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs project delight advice
eighters-theme quail cl-extra help-mode rg rg-ibuffer rg-result wgrep-rg
wgrep s rg-history rg-header rg-compat ibuf-ext ibuffer ibuffer-loaddefs
grep compile comint ansi-color ring edmacro kmacro disp-table paren
mb-depth icomplete page-break-lines elec-pair diff-hl-flydiff diff
diff-hl vc-dir ewoc vc vc-dispatcher diff-mode easy-mmode delsel
cus-start cus-load mule-util tex-site info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 510108 60620)
 (symbols 24 35458 1)
 (strings 16 125803 16010)
 (string-bytes 1 4146628)
 (vectors 8 59808)
 (vector-slots 4 1472134 107810)
 (floats 8 508 454)
 (intervals 28 32090 73)
 (buffers 564 69))

Message #8 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>,
 35781 <at> debbugs.gnu.org
Subject: Re: bug#35781: 27.0.50; [PATCH] Improve font display on Cairo builds
Date: Fri, 17 May 2019 20:54:35 +0300

On 17.05.2019 20:39, Kévin Le Gouguec wrote:
> - CAIRO_HINT_STYLE_SLIGHT has been available from version 1.0, and we
>    require 1.12, so AFAICT the setting can be used without checking for
>    any CAIRO_… feature.

Isn't font hinting something that the user sets in their global display 
configuration? With different people preferring different levels of hinting.

Message #11 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35781 <at> debbugs.gnu.org
Subject: Re: bug#35781: 27.0.50; [PATCH] Improve font display on Cairo builds
Date: Fri, 17 May 2019 20:14:41 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> Isn't font hinting something that the user sets in their global
> display configuration? With different people preferring different
> levels of hinting.

Possibly?  Though AFAICT on my setups, font hinting in Emacs varies just
by enabling --with-cairo; I am fairly sure my "global display
configuration" remained unchanged while testing this (if by global you
mean "system-wide", or "independent of Emacs's configuration").

So naively, if I didn't explicitly change this global configuration, I
would expect any difference in display in Emacs to be Emacs's
responsibility…

Of course, I may be missing something.

Message #14 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35781 <at> debbugs.gnu.org
Subject: Re: bug#35781: 27.0.50; [PATCH] Improve font display on Cairo builds
Date: Fri, 17 May 2019 20:23:57 +0200

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> Isn't font hinting something that the user sets in their global
>> display configuration? With different people preferring different
>> levels of hinting.

Ah-ha!  Just noticed some hint-related code in xftfont.c and xsettings.c
which seems to be responsible for applying this global configuration.
Now to investigate why the end result differs in the Cairo build…

Message #17 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35781 <at> debbugs.gnu.org
Subject: Re: bug#35781: 27.0.50; [PATCH] Improve font display on Cairo builds
Date: Fri, 17 May 2019 21:24:43 +0300

On 17.05.2019 21:14, Kévin Le Gouguec wrote:
> Though AFAICT on my setups, font hinting in Emacs varies just
> by enabling --with-cairo;

That might mean that Cairo doesn't follow the system font hinting 
configuration, and that should be fixed.

Hopefully someone more knowledgeable will tell us more.

Message #20 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 35781 <at> debbugs.gnu.org
Subject: Discrepancies between xftfont.c and ftcrfont.c
Date: Sat, 18 May 2019 22:43:28 +0200

retitle 35781 Make Cairo build obey hint-style font setting
thanks

I am nowhere close to a proper fix, but at least I think I am starting
to get a clearer picture of the situation.

The distribution installed on my laptop sets the "hint-style" font
setting to "slight" in both ~/.config/fontconfig/fonts.conf and
~/.Xresources.  AFAICU fontconfig and X resources are two (competing?)
mechanisms that tell graphical applications what fonts and font
settings they should use.  OK.

I am still studying the lay of the land; I see that xftfont_open in
xftfont.c calls xftfont_add_rendering_parameters, which has a bunch of
hint-style-related code calling fontconfig functions, while
ftcrfont_open in ftcrfont.c seems blissfully unaware of fontconfig.

At this point I am assuming that only ftcrfont.c is used in Cairo
builds, since config.h does not define HAVE_XFT, but my knowledge of
font management in Emacs is pretty lacking so I will have to check this
assumption.

As I said, I am far from being able to cook up any sort of patch at
this point; I still intend to keep digging Soonish™, but since that
may take a while, I figured I would update this report with whatever
information I gathered this far for posterity.

Message #25 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Alex Gramiak <agrambot <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35781 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Sun, 19 May 2019 13:48:33 -0600

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> retitle 35781 Make Cairo build obey hint-style font setting
> thanks
>
> I am nowhere close to a proper fix, but at least I think I am starting
> to get a clearer picture of the situation.
>
> The distribution installed on my laptop sets the "hint-style" font
> setting to "slight" in both ~/.config/fontconfig/fonts.conf and
> ~/.Xresources.  AFAICU fontconfig and X resources are two (competing?)
> mechanisms that tell graphical applications what fonts and font
> settings they should use.  OK.
>
> I am still studying the lay of the land; I see that xftfont_open in
> xftfont.c calls xftfont_add_rendering_parameters, which has a bunch of
> hint-style-related code calling fontconfig functions, while
> ftcrfont_open in ftcrfont.c seems blissfully unaware of fontconfig.
>
> At this point I am assuming that only ftcrfont.c is used in Cairo
> builds, since config.h does not define HAVE_XFT, but my knowledge of
> font management in Emacs is pretty lacking so I will have to check this
> assumption.
>
> As I said, I am far from being able to cook up any sort of patch at
> this point; I still intend to keep digging Soonish™, but since that
> may take a while, I figured I would update this report with whatever
> information I gathered this far for posterity.

Perhaps ftcrfont.c could use FcPatternAddFTFace, FcFontMatch,
cairo_ft_font_face_create_for_pattern, and otherwise the same pattern
building as xftfont.c.

Message #30 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Alex Gramiak" <agrambot <at> gmail.com>
Cc: 35781 <at> debbugs.gnu.org,
 "K?vin Le Gouguec" <kevin.legouguec <at> gmail.com>
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Tue, 21 May 2019 19:59:55 +0900

[Message part 1 (text/plain, inline)]

> Perhaps ftcrfont.c could use FcPatternAddFTFace, FcFontMatch,
> cairo_ft_font_face_create_for_pattern, and otherwise the same pattern
> building as xftfont.c.

I tried making ftcrfont_open look much like xftfont_open.
Could you try the attached patch?

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

[xft-like-ftcr.diff (application/octet-stream, attachment)]

Message #33 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: mituharu <at> math.s.chiba-u.ac.jp
Cc: 35781 <at> debbugs.gnu.org, Alex Gramiak <agrambot <at> gmail.com>
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Tue, 21 May 2019 21:03:25 +0200

mituharu <at> math.s.chiba-u.ac.jp writes:

> I tried making ftcrfont_open look much like xftfont_open.
> Could you try the attached patch?

Thank you for this patch!

I applied it on top of cb367c8e0d, and AFAICT this fixes the issue: on
both setups where I used to see a difference in hint style[1], the
fonts now look the same (i.e. with slight hinting).  Things haven't
deteriorated on the third setup[2].

I glanced at your patch to try and get a sense of how things worked;
from what I can tell you moved some logic from xftfont.c to ftfont.c,
which is used by ftcrfont.c, so the XFT and Cairo build would use more
common code?

(Is there a reason why you left xftfont_add_rendering_parameters in
xftfont.c despite adding ftfont_add_rendering_parameters in ftfont.c?
Should this function be added to ftfont.h so that xftfont.c gets rid
of its duplicate implementation?)

(Also, I see you removed some code related to the bitmap_strike_index
and ft_size_draw members of struct font_info; is it because whatever
this code was doing is now handled by… something else in ftfont.c?)

(Sorry for these Boeotian questions!)

Again, thanks a lot for this patch!



[1] Debian stretch (cairo 1.14.8) and Xubuntu 16.04 (cairo 1.14.6).

[2] OpenSUSE Tumbleweed (cairo 1.16.0).

Message #36 received at 35781 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35781 <at> debbugs.gnu.org, Alex Gramiak <agrambot <at> gmail.com>
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Wed, 22 May 2019 18:24:33 +0900

[Message part 1 (text/plain, inline)]

On Wed, 22 May 2019 04:03:25 +0900,
Kévin Le Gouguec wrote:
> 
> mituharu <at> math.s.chiba-u.ac.jp writes:
> 
> > I tried making ftcrfont_open look much like xftfont_open.
> > Could you try the attached patch?
> 
> Thank you for this patch!
> 
> I applied it on top of cb367c8e0d, and AFAICT this fixes the issue: on
> both setups where I used to see a difference in hint style[1], the
> fonts now look the same (i.e. with slight hinting).  Things haven't
> deteriorated on the third setup[2].

Thanks for testing.  An updated patch is attached.

> I glanced at your patch to try and get a sense of how things worked;
> from what I can tell you moved some logic from xftfont.c to ftfont.c,
> which is used by ftcrfont.c, so the XFT and Cairo build would use more
> common code?
> 
> (Is there a reason why you left xftfont_add_rendering_parameters in
> xftfont.c despite adding ftfont_add_rendering_parameters in ftfont.c?
> Should this function be added to ftfont.h so that xftfont.c gets rid
> of its duplicate implementation?)

I've overlooked it at the last minute change for xftfont.c.  It is
fixed in the updated one.

> (Also, I see you removed some code related to the bitmap_strike_index
> and ft_size_draw members of struct font_info; is it because whatever
> this code was doing is now handled by… something else in ftfont.c?)

Screening bitmap fonts from passing them to ftfont functions in
ftcrfont_get_bitmap, ftcrfont_anchor_point, and ftcrfont_shape is
resurrected by a new member bitmap_position_unit, which is primarily
introduced for HarfBuzz, in the updated patch.  The member
ft_size_draw is removed because it was a workaround in the previous
design.

In the updated patch, ftfont_open2 is merged into ftfont_open just as
before the introduction of the cairo drawing code, because they are no
longer used in cairo.

I'll push the updated one to master and also adapt it for the harfbuzz
branch in 15 hours or so.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

[xft-like-ftcr.diff (application/octet-stream, attachment)]

Message #41 received at 35781-done <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Alex Gramiak <agrambot <at> gmail.com>, 35781-done <at> debbugs.gnu.org
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Thu, 23 May 2019 11:00:22 +0900

> I'll push the updated one to master and also adapt it for the harfbuzz
> branch in 15 hours or so.

Done at 03feb9376b5 and b40dde705af.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #44 received at 35781-done <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Alex Gramiak <agrambot <at> gmail.com>, 35781-done <at> debbugs.gnu.org
Subject: Re: bug#35781: Discrepancies between xftfont.c and ftcrfont.c
Date: Thu, 23 May 2019 19:53:36 +0200

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

>> I'll push the updated one to master and also adapt it for the harfbuzz
>> branch in 15 hours or so.
>
> Done at 03feb9376b5 and b40dde705af.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp

I've built the master and harfbuzz branches on my Debian stretch and
Xubuntu 16.04 setups, and everything looks peachy.

Thanks a lot for this patch, and for keeping the harfbuzz branch
up-to-date!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.