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

Previous Next

Package: emacs;

Reported by: andrei.elkin <at> pp.inet.fi

Date: Fri, 25 Aug 2017 20:00:02 UTC

Severity: normal

Tags: help

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

Bug is archived. No further changes may be made.

Full log


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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 28236 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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: Tue, 04 Jun 2019 16:47:56 +0900
[Message part 1 (text/plain, inline)]
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.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp
[cairo-xfont.diff (application/octet-stream, attachment)]

This bug report was last modified 6 years and 63 days ago.

Previous Next


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