[oi-dev] Emacs has a bad font
Udo Grabowski (IMK)
udo.grabowski at kit.edu
Tue Jun 18 13:16:01 UTC 2024
On 18/06/2024 15:00, Udo Grabowski (IMK) wrote:
> This could be a clue:
> 08887: 1: ld.so.1: emacs-gtk-29.3: fatal: gtk_progress_get_type: can't find symbol
>
> gtk_progress_get_type is a symbol from gtk2 (deprecated), not in gtk3.
>
> But as far as I can deduce from the dbx library load list and LD_DEBUG=libs,
> none of that is calling libgtk2*, so that symbol must be somewhere in the
> code (...of a loaded library?).
>
The gtk3 equivalent would be gtk_progress_BAR_get_type .
> On 18/06/2024 14:09, Udo Grabowski (IMK) wrote:
>> On 18/06/2024 12:51, Udo Grabowski (IMK) wrote:
>>> emacs -nw -q --batch --eval '(message system-configuration-options)' shows
>>>
>>> CC=/usr/gcc/13/bin/gcc CXX=/usr/gcc/13/bin/g++ F77=/usr/gcc/13/bin/gfortran
>>> FC=/usr/gcc/13/bin/gfortran ’CFLAGS=-m64 -O3 -I/usr/include/libjpeg8-turbo
>>> -Wl,-L/usr/lib/libjpeg8-turbo/lib/amd64 -Wl,-R/usr/lib/libjpeg8-turbo/lib/amd64
>>> -I/usr/include/lcms2’ ’CXXFLAGS=-m64 -O3 -I/usr/include/libjpeg8-turbo
>>> -Wl,-L/usr/lib/libjpeg8-turbo/lib/amd64 -Wl,-R/usr/lib/libjpeg8-turbo/lib/amd64’
>>> ’FFLAGS= -m64 -O3 ’ ’FCFLAGS=-m64 -O3 ’ ’LDFLAGS=-m64
>>> -L/usr/lib/libjpeg8-turbo/lib/amd64 -R/usr/lib/libjpeg8-turbo/lib/amd64
>>> -L/usr/gnu/lib/amd64 -R/usr/gnu/lib/amd64’
>>> PKG_CONFIG_PATH=/usr/openssl/3.1/lib/64/pkgconfig:/usr/mariadb/10.6/lib/amd64/pkgconfig:/usr/lib/amd64/pkgconfig:/usr/lib/pkgconfig
>>>
>>>
>>> --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib/amd64
>>> --libexecdir=/usr/libexec --sbindir=/usr/sbin --infodir=/usr/share/info
>>> --datarootdir=/usr/share --libexecdir=/usr/lib --with-gif=yes --with-xaw3d=no
>>> --with-mailutils --with-modules --with-imagemagick --with-threads --with-png
>>> --with-rsvg --with-sqlite3 --with-tiff --with-toolkit-scroll-bars --with-webp
>>> --with-treesitter --with-sound=oss
>>> ac_cv_sys_long_file_names=yes --with-x-toolkit=gtk3 --with-xwidgets
>>> ^^^^^^^^^^^^^^
>>> xwidgets usually means libwx*, which is build with gtk-2; but libwx is not shown
>>> in the ldd output of emacs-gtk.
>>
>> No, in fact, it's webkit2gtk:
>>
>> libwebkit2gtk-4.1.so.0 => /usr/lib/64/libwebkit2gtk-4.1.so.0
>>
>> which correctly links to gtk-3:
>>
>> libgtk-3.so.0 => /usr/lib/64/libgtk-3.so.0
>>
>>> On 17/06/2024 23:18, Gordon Ross wrote:
>>>> I opened a bug for this:
>>>> https://www.illumos.org/issues/16613
>>>> emacs-gtk vers 29.3 crashes on startup
>>>>
>>>> On Mon, Jun 17, 2024 at 4:32 PM Gordon Ross <gordon.w.ross at gmail.com> wrote:
>>>>>
>>>>> Before beginning an exploration of which versions expose the font
>>>>> problem and which don't, I decided to start with updating the
>>>>> installation. Now emacs-gtk doesn't work at all. Suggestions?
>>>>> Output below:
>>>>>
>>>>> (emacs-gtk:1193): Gtk-ERROR **: 16:25:16.093: GTK+ 2.x symbols
>>>>> detected. Using GTK+ 2.x and GTK+ 3 in the same process is not
>>>>> supported
>>>>> Fatal error 5: Trace/breakpoint trap
>>>>> Backtrace:
>>>>> /usr/bin/emacs-gtk'emacs_backtrace+0x46 [0x66cb46]
>>>>> /usr/bin/emacs-gtk'terminate_due_to_signal+0x73 [0x63fb1c]
>>>>> /usr/bin/emacs-gtk'deliver_fatal_signal.cold+0x0 [0x66e99c]
>>>>> /lib/amd64/libc.so.1'__sighndlr+0x6 [0x7fffaf3f46d6]
>>>>> /lib/amd64/libc.so.1'call_user_handler+0x1d1 [0x7fffaf3e7371]
>>>>> /lib/amd64/libc.so.1'sigacthandler+0xee [0x7fffaf3e766e]
>>>>> [0xffffffffffffffff]
>>>>> /usr/lib/amd64/libglib-2.0.so.0.7600.4'g_log_structured_array+0x84
>>>>> [0x7fffae926874]
>>>>> /usr/lib/amd64/libglib-2.0.so.0.7600.4'g_log_structured_standard+0x1a6
>>>>> [0x7fffae9275c6]
>>>>> /usr/lib/amd64/libgtk-3.so.0.2409.32'pre_parse_hook+0x61 [0x7fffaac3ce01]
>>>>> /usr/lib/amd64/libglib-2.0.so.0.7600.4'g_option_context_parse+0x87
>>>>> [0x7fffae931c07]
>>>>> /usr/lib/amd64/libgtk-3.so.0.2409.32'gtk_parse_args+0xbf [0x7fffaac3d6ff]
>>>>> /usr/lib/amd64/libgtk-3.so.0.2409.32'gtk_init_check+0xe [0x7fffaac3d76e]
>>>>> /usr/lib/amd64/libgtk-3.so.0.2409.32'gtk_init+0x9 [0x7fffaac3d7b9]
>>>>> /usr/bin/emacs-gtk'x_term_init+0x1a3 [0x60f643]
>>>>> /usr/bin/emacs-gtk'Fx_open_connection+0x50 [0x615a60]
>>>>> /usr/bin/emacs-gtk'exec_byte_code+0x3e6 [0x756f36]
>>>>> /usr/bin/emacs-gtk'Ffuncall+0xff [0x6f506f]
>>>>> /usr/bin/emacs-gtk'Fapply+0x2b8 [0x6f5458]
>>>>> /usr/bin/emacs-gtk'exec_byte_code+0x3e6 [0x756f36]
>>>>> /usr/bin/emacs-gtk'apply_lambda+0xcc [0x6fb12c]
>>>>> /usr/bin/emacs-gtk'eval_sub+0x404 [0x6f9314]
>>>>> /usr/bin/emacs-gtk'Feval+0x47 [0x6fbdd7]
>>>>> /usr/bin/emacs-gtk'internal_condition_case+0x66 [0x6f2be6]
>>>>> /usr/bin/emacs-gtk'top_level_1+0x22 [0x6431c2]
>>>>> /usr/bin/emacs-gtk'internal_catch+0x3b [0x6f2b4b]
>>>>> /usr/bin/emacs-gtk'command_loop+0x7b [0x641e4b]
>>>>> /usr/bin/emacs-gtk'recursive_edit_1+0x86 [0x649b76]
>>>>> /usr/bin/emacs-gtk'Frecursive_edit+0xd6 [0x649ec6]
>>>>> /usr/bin/emacs-gtk'main+0x1c49 [0x6417a9]
>>>>> /usr/bin/emacs-gtk'_start_crt+0x87 [0x4dc307]
>>>>> /usr/bin/emacs-gtk'_start+0x18 [0x4dc268]
>>>>> Trace/Breakpoint Trap
>>>>>
>>>>> On Mon, Jun 10, 2024 at 9:09 PM Gordon Ross <gordon.w.ross at gmail.com> wrote:
>>>>>>
>>>>>> Looking into this again. I definitely have this font selected:
>>>>>>
>>>>>> $ fc-match "Deja Vu Sans Mono"
>>>>>> DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
>>>>>> $ fc-match "Deja Vu Sans Mono-12"
>>>>>> DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
>>>>>>
>>>>>> It exists, and is a TrueType font.
>>>>>> If I use that font in a mate-terminal profile
>>>>>> (un-check "use system font" and specify that)
>>>>>> it renders with font smoothing as expected.
>>>>>>
>>>>>> Selecting that same font in emacs give the jagged edges.
>>>>>> Any ideas what else could be disabling font smoothing?
>>>>>>
>>>>>> On Tue, Nov 21, 2023 at 7:58 PM Alan Coopersmith
>>>>>> <alan.coopersmith at oracle.com> wrote:
>>>>>>>
>>>>>>> Yes, the "bad" one is not antialiased, possibly a bitmap font,
>>>>>>> while the "good" one is definitely antialiased, possibly TrueType or
>>>>>>> OpenType.
>>>>>>>
>>>>>>> -alan-
>>>>>>>
>>>>>>> On 11/21/23 07:25, Gordon Ross wrote:
>>>>>>>> Thanks. I've confirmed that emacs is using the system font in both builds.
>>>>>>>> Here are two screen shots (bad, good) that one can zoom in.
>>>>>>>> The bad one has visible stair step diagonals etc. so I guess
>>>>>>>> the good one has "anti-aliasing" and the bad does not?
>>>>>>>> Does that clue help in tracking this down?
>>>>>>>>
>>>>>>>> On Mon, Nov 20, 2023 at 2:20 PM Alan Coopersmith
>>>>>>>> <alan.coopersmith at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> GTK & Pango use fonts from fontconfig, not from X11, so it's not expected
>>>>>>>>> to match xfontsel (which uses X11 fonts). Among other things, Pango 1.44
>>>>>>>>> dropped support for Type 1 & bitmap fonts, which X11/xfontsel still
>>>>>>>>> support,
>>>>>>>>> leaving TrueType & OpenType font support. One easy to spot difference,
>>>>>>>>> fontconfig uses more natural names, like "DejaVu Sans Mono", while X11
>>>>>>>>> uses
>>>>>>>>> the older naming format with the 14 dashes separating fields. Visually,
>>>>>>>>> if the font is anti-aliased or LCD optimized, it must be fontconfig, as
>>>>>>>>> the X11 font system doesn't support either technology.
>>>>>>>>>
>>>>>>>>> https://www.x.org/releases/current/doc/xorg-docs/fonts/fonts.html
>>>>>>>>> describes the difference (using "Xft" for the fontconfig system),
>>>>>>>>> but it's about a decade behind the latest changes now.
>>>>>>>>>
>>>>>>>>> -alan-
>>>>>>>>>
>>>>>>>>> On 11/20/23 11:10, Gordon Ross wrote:
>>>>>>>>>> As far as I can tell, the "system" font for mate terminal and such is:
>>>>>>>>>> "DejaVu Sans Mono", or
>>>>>>>>>> -misc-dejavu sans mono-medium-o-normal--0-0-0-0-p-0-ascii-0
>>>>>>>>>>
>>>>>>>>>> Based on what I see with xfontsel, it looks like emacs may be using:
>>>>>>>>>> -misc-dejavu sans light-extralight-r-normal--0-0-0-0-p-0-ascii-0
>>>>>>>>>>
>>>>>>>>>> I tried playing with the options/Set Default Font in emacs.
>>>>>>>>>> I'm not sure why, but emacs shows a lot less than xlsfonts does.
>>>>>>>>>>
>>>>>>>>>> Here's what I have (from "save options") in both builds.
>>>>>>>>>> (custom-set-faces
>>>>>>>>>> ;; custom-set-faces was added by Custom.
>>>>>>>>>> ;; If you edit it by hand, you could mess it up, so be careful.
>>>>>>>>>> ;; Your init file should contain only one such instance.
>>>>>>>>>> ;; If there is more than one, they won't work right.
>>>>>>>>>> '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant
>>>>>>>>>> normal :weight normal :width normal :height 113)))))
>>>>>>>>>>
>>>>>>>>>> There seems to be a change in either the fonts or the rendering, from
>>>>>>>>>> the older OI build to recent ones.
>>>>>>>>>> The examples shown by "xfontsel" look too light in some cases too.
>>>>>>>>>> I'd appreciate tips on how to track down this problem.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 8, 2023 at 4:27 PM Gary Mills <gary_mills at fastmail.fm> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 08, 2023 at 05:44:42PM +0100, Andreas Wacknitz wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If you are using the gtk variant of emacs
>>>>>>>>>>>
>>>>>>>>>>> That's the one I'm using.
>>>>>>>>>>>
>>>>>>>>>>>> then it relies on pango for
>>>>>>>>>>>> font rendering and layout which in case has dropped support for older
>>>>>>>>>>>> font types a couple of months ago.
>>>>>>>>>>>> So your problem might be that you are trying to use an unsupported (by
>>>>>>>>>>>> pango) font type and thus rendering results look ugly.
>>>>>>>>>>>> You might solve this be choosing a font of a supported font type, eg. a
>>>>>>>>>>>> truetype font.
>>>>>>>>>>>
>>>>>>>>>>> There's no indication of truetype in the list of fonts that emacs
>>>>>>>>>>> displays. In fact, emacs will often tell me that a font does not
>>>>>>>>>>> exist when I select that font from its list.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -Gary Mills- -refurb- -Winnipeg, Manitoba,
>>>>>>>>>>> Canada-
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> oi-dev mailing list
>>>>>>>>>>> oi-dev at openindiana.org
>>>>>>>>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> oi-dev mailing list
>>>>>>>>>> oi-dev at openindiana.org
>>>>>>>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -Alan Coopersmith- alan.coopersmith at oracle.com
>>>>>>> Oracle Solaris Engineering - https://blogs.oracle.com/solaris
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> oi-dev mailing list
>>>> oi-dev at openindiana.org
>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> oi-dev mailing list
>>> oi-dev at openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>
>>
>>
>>
>>
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>>
>
>
--
Dr.Udo Grabowski Inst.of Meteorology & Climate Research IMK-ASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5804 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20240618/19f9742d/attachment.bin>
More information about the oi-dev
mailing list