[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28236: 'configure --with-cairo' causes 'emacs -font' to fail
From: |
YAMAMOTO Mitsuharu |
Subject: |
bug#28236: 'configure --with-cairo' causes 'emacs -font' to fail |
Date: |
Sat, 08 Jun 2019 14:13:44 +0900 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
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@math.s.chiba-u.ac.jp