I am trying to come up with a universal-ish boilerplate that will let me use as many weird Unicode symbols as I like in my plaintext documents, and handle font fallback on those symbols gracefully when exporting to PDF (using Pandoc with XeLaTeX). Here is a sample document:

Some arrows such as ←, ⇔, ↗. Is the main font back on?

Some symbols such as 🤷, 🤦, 🎉, 🎊, 📧, 📱. Is the main font back on?

Some mathematical operators such as ≥, ≡, ≈. Is the main font back on?

Some letters and numerals such as 𝒞, 𝔸, 𝔽 and Ⅴ. Is the main font back on?

Quid des caractères accentués ? Is the main font back on?

Here is what I expect from the boilerplate:

  • fit in a file I can include with pandoc's --include-in-header
  • switch between two fonts: the "main" one for Latin/punctuation, the "default" one for symbols

So far, here is my most successful attempt*:


\newfontfamily{\mymainfont}{DejaVu Sans}


(NB: I run Pandoc with -V mainfont="DejaVu Sans", which sticks \setmainfont[]{DejaVu Sans} somewhere in the TeX source)

I say "most successful", because I still get "glitches" here and there:

Almost there


  • commas after 🤷 (U+1F937 SHRUG) and 🤦 (U+1F926 FACE PALM) are displayed with Symbola rather than DejaVu Sans;
  • Latin letters following accented characters are displayed with Symbola rather than DejaVu Sans.

In addition to the obvious question ("How do I get my boilerplate to do what it's supposed to?"), I would like to add another one: is there an "easy" way** to get the name of the block a character belongs to?

* This is the result of several iterations, in which I tried to solve a bunch of issues such as:

  • XeLaTeX silently dropping some characters
  • DejaVu Sans trying to display characters it does not have (yielding white boxes)

** I.e. as automated as possible; I figured I could write a C program to get the answer from libicu, but the library only defines an enumeration without human-readable strings. The "cleanest" approach I could find consisted in downloading and parsing http://unicode.org/Public/UNIDATA/Blocks.txt, which is not exactly straightforward. So far I am left with "Ask fileformat.info".


  • Debian Jessie
  • XeTeX 3.14159265-2.6-0.99992 (TeX Live 2015/dev/Debian)
  • ucharclasses 2012/09/25 v2.0x

NB: I have just noticed that ucharclasses only supports Unicode up to version 8.0. SHRUG and FACE PALM appear to have been introduced by Unicode 9.0 (according to fileformat.info). I guess this is tied to the commas not reverting to DejaVu Sans, but how exactly? And what can be done about this?

EDIT: Replacing the \setTransitionsForPunctuation and \setTransitionsForLatin to \setTransitionTo{XXX} solves the issue following accented characters, but causes DejaVu Sans to be used for SHRUG and FACE PALM (yielding white boxes). I am suspecting an ucharclasses issue when transitionning between one subset of an informal group to another (here, from LatinSupplement, which contains "è", to regular Latin).

2 Answers 2


OK, so SHRUG and FACE PALM appear to have been added to Unicode 9's Supplemental Symbols and Pictographs block. The latest version of ucharclasses does support this block; I chose to patch my local installation like so:

@@ -212,6 +212,8 @@
+  \do{SupplementalSymbolsAndPictographs}{129280}{129535}
 % ----------------------------------------------------------------------------
 %  Option handling lets the user turn off "load all" and selectively enable only those blocks 
@@ -396,6 +398,7 @@
+  \do{SupplementalSymbolsAndPictographs}


I also had to tweak my header file; here is the final version:


\newfontfamily{\mymainfont}{DejaVu Sans}


Comment is too small, so posting as answer, and not about ucharclasses at all, just unicode.


Unicode is huge.

as many weird Unicode symbols as I like -- the magnitude of "many" may be limited by system constraints.

Using an empty edit window, pasting in a string of characters (one character from each of the first 120 unicode blocks), takes >5 min, <10min to complete (I went away and did something else). Compiling is OK (with one font):


Pasting in the next 110 crashed the editor (Texworks in Miktek on Windows).

Similarly, 3 min to open the tex file later. I expect it's buffer-related in some way.

In the other dimension, there seems to be a threshold limit of about 60 font families definable per session, after which Xelatex fails.

But all operational matters are fixable.



abc All of this is one font -- Code2003: The first ~120 unicode blocks (with some scattered spaces to activate line-wrapping): 

!¡Āƀɐʰ́ ͰБԀԱאعݐބߒࠅࡁࢢऄঅਅઅଅஅ అಕഅඅกກ༂က  ႠᄁሁᎀᎠ ᐂᚄᚠᜀᜠᝀᝠក᠀ᢰᤀᥐᦀ ᧠ᨀ ᨢ᪰ᬒᮃᯂᰂ᱒ᲀ᳀᳑ᴁᶀ᷁ḁἁ\-•⁵₤⃔ℂ ⅒→∂⌂␂⑂①━▂▢☀✅⟁⟱ ⠗⤃⦃⨂⬂ⰂⱢ Ⲁⴂⴳⶁⷡ ⸙⺒⼒⿲〖あアㄅㄳ㆕ㆣ ㇃ㇲ ㈃㌂㐂䷂万ꀂ꒓ꔂꙂꚣ꜃Ꜳꠃꡂꢃꢑ

% ꣴ꤁ꤰꥠꦅꧡꨁꩤꪃꫢꬁꬱꭱꯀ가ힰ更ffiﭒ︙︻︴ﺃ#𐀁𐂂𐄓𐅒𐆒𐇐𐊃𐊣𐋢𐌇𐌸𐍒𐎄𐎠𐐂𐑔𐒄𐒲𐔀𐔰𐘷𐠃𐡄𐡣𐢃𐣣𐤄𐤤𐦄𐦥𐨒𐩣𐪀𐫂𐬃𐭄𐭤𐰇𐲃𐹢𑀆𑃑𑅓𑆀𑇤𑈃𑊳𑌃𑐂𑒂𑖂𑘂𑙢𑚃𑢤𑫄𑰄𑱳𒀣𒐃𒒂𔐂𖠂𖩂𖫒𖬂𖼃𗀂𘠂𛰂𝀄𝀔𝈃𝌃𝍣𝐄𝠃𞀃𞠂𞤄𞸑🀃🂥🂥🄆🌅😄🙓🚂🜃🞃🠄🤔𠀓𪜃𫝃𫠣再󠀤

For multi-block character matters and single words or so across many scripts, ucharclasses is useful. Or for a few scripts per document, for long texts (the general case, I imagine).

For multi-lingual and/or multi-script long-texts, polyglossia or babel, because of hyphenation, translations and other language-level and layout-related things (combined with biblatex/biber for bibliographies).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .