bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]