bug#28236: 'configure --with-cairo' causes 'emacs -font' to fail

[YAMAMOTO Mitsuharu]

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@math.s.chiba-u.ac.jp

cairo-xfont.diff
Description: Binary data