Home | News | Download | Packages | Forum | Wiki | Github

Font issues in Void musl emacs


A really odd issue. On my Void musl machine, in Emacs, if I use a devanagari typeface (‘font’) than conjunct characters fail to compose and other diacritics are misaligned:

On my Arch machine, the same text renders perfectly:

[In the first screenshot, you can see in the first line, for instance, that there are a number of nw-se strokes under the main body which indicate failure for two conjunct characters to compose. Further, comparing the two images, the curvy strokes above the line are misplaced one character to the right in the first screenshot. This is particularly noticeable for instance in line 4, where one of these is displaced to the right-edge of the word (which makes the text gibberish).]

The two instances of Emacs use the same exact config, and I’ve made sure they’re using the same Devanagari typeface (it’s locally installed on my both machines in the ~/.fonts directory): Droid Sans Mono Devanagari.

Further, if I insert the same text in another application like Libreoffice on the Void musl machine, it displays without issue.

I don’t know where this issue is arising from. (I don’t know that it’s specific to musl Void, since I don’t seem to be able to get emacs to run properly from a glib chroot.)

Does anyone have any ideas for why this might be happening or about further diagnostic steps I could take?


Shot in the dark: the font sizes are different. Could that cause it?


I don’t think the font sizes are different - rather the screens are different sizes, so the screenshots look different. (Besides, I don’t think font size affects font compounding/conjoining.)

Is it possible it’s something about the emacs compile settings used for void?


It appears that in order for Indic fonts to work correctly in Emacs, it must be built with M17N, OTF and Xft support. It looks like Void’s emacs isn’t built with these. [Snippet of Void emacs build:]

# Package build options
build_options="jpeg tiff gif png xpm svg xml imagemagick gnutls sound"
desc_option_xpm="Enable support for XPM images"
desc_option_sound="Enable support for sound"
build_options_default="jpeg tiff gif png xpm svg xml gnutls sound"


And it looks like m17n doesn’t exist in Void. I tried rebuilding emacs adding in m17n, otf, and xft options to the build template, and it didn’t behave any differently, unfortunately. Tried again after installing void’s otf package, and still no luck. I’m assuming it really does need m17n to be installed.


Are you planning on making a template and a PR for m17n? Because I had some time today and made one along with some dependencies and would make a PR, but wanted to ask first to not interfere in case you already did. :wink:


I haven’t had a chance to make one, and was waiting to see if someone would say "m17n won’t work in Void because of X". So if you’ve already got a template ready, I’d actually be obliged if you went ahead and made a PR. Cheers!


Ok. I made the PR here. I didn’t include emacs for now. But you just have to add m17n-lib-devel and liboft-devel to makedepends (m17n-lib-devel alone won’t get recognized).


Many thanks for this. So, in addition to the build options in the emacs template, 17n-lib-devel and liboft-devel should be added to the makedepends? What about libXft-devel, I wonder.


Ok, I made some changes: I added m17n-lib’s makedepends to the -devel package and added a (default) build option for m17n to emacs. And because m17n-lib depends on libotf-devel it gets pulled in automatically. I also included emacs in the PR now.

Xft is also a dependency and gets detected automatically.

This is the output of the configure script:

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               cc -mtune=generic -O2 -pipe   
  Should Emacs use the GNU version of malloc?             yes
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK3
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng16
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   no
  Does Emacs use imagemagick?                             no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lglibc (inotify)
  Does Emacs use access control lists?                    yes -lacl
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              yes
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets (requires gtk3)?            yes


Do we know what the failures are in the travis build? Or rather, you seem to suggest it’s an issue on some archs with libdatrie - what is needed to solve this?


I think the problem is that libthai uses the trietool binary from libdatrie to generate a dictionary. So libdatrie has to be built twice: for the host to actually run trietool and for the target because libthai is also linked against libdatrie. The log shows that libdatrie was built twice: first e.g. for aarch64 and the package is ok, the second time for x86_64, but when stripping the file format isn’t recognized. My guess is that something got mixed up apparently. It’s working flawlessly when doing a local build. So I don’t really know what else to do but wait until a maintainer has a look at it. :frowning:


What’s the best way for me to pull your changes directly? (Though I think it’ll still need updating since I believe Emacs updated after your pull request.)


I did update the PR after the latest Emacs update :slight_smile:

I just have basic git knowledge, but you could clone my fork, checkout the branch ‘m17n’ update it with git pull --rebase upstream master and then xbps-src pkg emacs.


Hurrah! It works! (I needed to add upstream and install the build utils too.)

Proper font rendering in Emacs on Void (in musl too!):

[This is actually rather important to my work, as I need to read/write email written in devanagari and typeset it upon occasion as well.]

Many thanks again, bluemoon.


Don’t know if you noticed, but it’s officially in the repo now. :slight_smile:


Yes, very happy to see that! And I hear rumours of a new major version of Emacs coming soon.