GNU bug report logs - #28236
'configure --with-cairo' causes 'emacs -font' to fail

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#28236: closed ('configure --with-cairo' causes 'emacs -font'
 to fail)
Date: Sat, 08 Jun 2019 05:14:01 +0000

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

Your message dated Sat, 08 Jun 2019 14:13:44 +0900
with message-id <wlzhmsek1j.wl-mituharu <at> math.s.chiba-u.ac.jp>
and subject line Re: bug#28236: 'configure --with-cairo' causes 'emacs -font' to fail
has caused the debbugs.gnu.org bug report #28236,
regarding 'configure --with-cairo' causes 'emacs -font' to fail
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
28236: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28236
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: andrei.elkin <at> pp.inet.fi
To: bug-gnu-emacs <at> gnu.org
Subject: 'configure --with-cairo' causes 'emacs -font' to fail
Date: Fri, 25 Aug 2017 22:57:59 +0300

Hello.

I've been checking out the master branch periodically for quite a while but never
configured it with cairo.
Today I gave it a try, appending the option to my regular option list, as below.

$ git show HEAD
commit 579890f1c7703cd8ecfe2e56f52cc06fcd1b2442
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Fri Aug 25 18:01:19 2017 +0300

  bash# ./configure --with-xft --with-x-toolkit=lucid --with-dbus \
                    --with-cairo && make ...
  => ... [ ok ]
The resulted executable complains about a font that otherwise
"orthodoxically" built one never has done (as the font really exists,
 which xlsfonts double-proves:

  bash# xlsfonts | grep 7x14
  =>7x14
).

  bash# src/emacs -Q -font 7x14
  => Font ‘7x14’ is not defined

This effect is observed in earlier commits as well. (I first suspected the
failure was introduced by a commit in the range started from my last
pull (about two weeks ago)).

I've not investigated any further, still hope this report is not in
vain.

Using this chance, thank you all for working and maintaining this
wonderful piece of software!

Andrelkin.

[Message part 3 (message/rfc822, inline)]

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 28236-done <at> debbugs.gnu.org, ari.roponen <at> gmail.com, andrei.elkin <at> pp.inet.fi,
 dgutov <at> yandex.ru
Subject: Re: bug#28236: 'configure --with-cairo' causes 'emacs -font' to fail
Date: Sat, 08 Jun 2019 14:13:44 +0900

On Tue, 04 Jun 2019 16:47:56 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> On Thu, 13 Dec 2018 23:56:21 +0900,
> Robert Pluim wrote:
> > 
> > >> So xfns.c only initializes the xfont driver when not using Cairo. I
> > >> made the obvious changes there, and 'emacs -Q -fn 7x14' starts up, and
> > >> 'C-u C-x =' tells me:
> > >> 
> > >>  x:-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 (#x68)
> > >> 
> > >> Unfortunately *scratch* does not (re-)display properly
> > >
> > > Can you tell more details about this improper redisplay?
> > 
> > I see text for the menu-bar, but *scratch* looks empty (and thereʼs no
> > text displayed in the mode-line). The text is actually there in
> > *scratch*, though.
> > 
> > I donʼt think this is a viable path to look at, especially given Ari's
> > workaround of copying the required fonts.
> 
> Previously the cairo drawing code does its own double-buffering using
> the image surface, where all the drawing should happen on the client
> side and not compatible with X core fonts that are drawn on the server
> side.  Copying back the result of server side drawing is not
> impossible, but inefficient.
> 
> Recently, I've made a change to the cairo drawing code in the master
> so it draws into Xlib surfaces instead of image ones if the X Double
> Buffer Extension is available.  On top of that, it is rather
> straightforward to cope with X core fonts.
> 
> I implemented both in the attached patch.  The former corresponds to
> the case that the frame parameter `inhibit-double-buffering' is t, and
> the latter to nil.  I think the latter is usable, but the former is
> not.  The code for the former is not an total waste because we can use
> it for exporting displayed contents to bitmap images, i.e.,
> (x-export-frames FRAME 'png).  The same approach cannot be used for
> exporting to outline images (PDF or SVG), so characters in X core
> fonts are replaced with hollow boxes in such cases.

Pushed to master as faf10bd8eb3.

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

Previous Next

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