# Engine problem? Creating dynamic diacritics using the Brill typeface

I’m trying to recreate the following image from John Hudson’s (principal designer of the Brill typeface) presentation slides:

Source: The Brill Types, p. 22.

The typeface is free for non-commercial use, please see the official Brill website. I got stuck in the image on page 21.

Edit after the comments under Thérèse’s answer. I realized that this was an engine problem. In the following simplified example (containing only the first 4 letters), you may spot the surprising results from both engines.

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Brill}
\ExplSyntaxOn
\NewDocumentCommand \dynamicdiacritics { }
{
Results ~ from ~
\sys_if_engine_luatex:T { LuaLaTeX: ~ }
\sys_if_engine_xetex:T  { XeLaTeX: ~ }
d \char"030C \char"0304 \char"0323 \char"0326
y \char"030D \char"0311 \char"0310 \char"0302 \char"0301 \char"0353 \char"0347
n \char"0306 \char"0308 \char"1DD8 \char"0304 \char"0307 \char"032D \char"0332 \char"032B \char"0323
a \char"0363 \char"0306 \char"0309 \char"0324 \char"0330 \char"032A
}
\ExplSyntaxOff
\begin{document}
\dynamicdiacritics
\end{document}


According to the User Guide of “The Brill” (thanks, Thérèse!), one puts diacritics above before diacritics below. LuaTeX does the stacking gracefully. For XeTeX, the diacritics above “d” is too low, and there is a surprising horizontal shift for the diacritics around “n”. However, both engines have slight problems with vertical kerns.

I have added the engines’ tag to better reflect this question.

Original attempt:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Brill}
\ExplSyntaxOn
\NewDocumentCommand \dynamicdiacritics { }
{
d \char"0323 \char"030C
y \char"030D \char"0311
n \char"0306 \char"032D
a \char"0324 \char"0330
m \char"0310 \char"0318
i \char"0304 \char"1DCA
c \char"0319 \char"030B
~
d \char"0325 \char"0309
i \char"030E \char"1DC7
a \char"1DC8 \char"031E
c \char"0348 \char"0332
r \char"0346 \char"0332
i \char"0313 \char"036F
t \char"032B \char"0306
i \char"1DC5 \char"0307
c \char"0368 \char"0301
s \char"031C \char"1DCC
}
\ExplSyntaxOff
\begin{document}
\dynamicdiacritics
\end{document}


My failed attempt; wrong diacritics might have been used as well.

• +1: Nice question. What is the reason of interest if I may ask? Apr 18, 2019 at 20:52
• @Dr.ManuelKuehner I just found the technology behind “The Brill” fascinating, and that the “dynamic diacritics” image is beautiful to look at. The code could also serve as a test for fonts that claim to support the International Phonetic Alphabet. See, also, Fonts with well-behaved stacking diacritics? Apr 18, 2019 at 21:02
• Have you seen the section ‘How to use combining diacritics’ on page 2 of The Brill Typeface User Guide & Complete List of Characters (a .pdf you can download along with the font)? Apr 19, 2019 at 2:01
• What exactly is the question in this revised posting? How to fix the output from xetex? Apr 20, 2019 at 0:29
• @Thérèse The objective of this question remains the same: I am trying to recreate the image. As I strictly followed your advice of applying the top diacritics before the lower ones, I still find the problem with vertical kerning even under LuaTeX. I have no idea why XeTeX performs so poorly, but LuaTeX does not give me what I want either. :( Apr 20, 2019 at 1:13

The XeTeX behavior is a combination of HarfBuzz “features” and font limitations.

Unicode has something called canonical equivalence. When a certain code point sequence is said to be canonically equivalent with another one, Unicode specify that both sequences should be rendered the same.

One example of this is ḍ (U+1E0D LATIN SMALL LETTER D WITH DOT BELOW) which is canonically equivalent with d + U+0323 COMBINING DOT BELOW. The first is called the composed form, and the later is called the decomposed form, and Unicode has normalization standards that map from one form to the other (NFC for the composed form, and NFD for the decomposed one).

HarfBuzz always prefers the composed form when supported by the font, so d + U+0323 COMBINING DOT BELOW is turned into ḍ if the font supports it.

Another part of Unicode canonical equivalence is the canonical ordering, which specifies how combining marks should be ordered no matter what the input order is. Again HarfBuzz applies the canonical ordering of the marks.

The combination of both cause 1) the order of the the marks in your input is not the same as what HarfBuzz will actually use 2) some base glyph + mark sequences are replaced with the composed form (e.g. the first d in your example ends up as ḍ + the other marks). In an ideal world this shouldn’t be an issue, but with Brill font the ḍ glyph does not have the same anchors for positioning combining marks as the d glyph which results in mark displacement. This is a font bug since it does not handle canonically equivalent sequences of code points the same way.

A work around for this is to insert U+200C ZERO WIDTH NON-JOINER character to prevent the problematic compositions or reordering:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Brill}
\ExplSyntaxOn
\NewDocumentCommand \dynamicdiacritics { }
{
Results ~ from ~
\sys_if_engine_luatex:T { LuaLaTeX: ~ }
\sys_if_engine_xetex:T  { XeLaTeX: ~ }
d\char"200C\char"030C\char"0304\char"200C\char"0323\char"0326
y\char"030D\char"0311\char"0310\char"0302\char"0301\char"0353\char"0347
n\char"0306\char"0308\char"1DD8\char"0304\char"0307\char"200C\char"032D\char"0332\char"032B\char"0323
a\char"0363\char"0306\char"0309\char"0324\char"0330\char"032A
}
\ExplSyntaxOff
\begin{document}
\dynamicdiacritics
\end{document}


You can even just insert it before any combining mark, it won’t hurt:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Brill}
\ExplSyntaxOn
\NewDocumentCommand \dynamicdiacritics { }
{
Results ~ from ~
\sys_if_engine_luatex:T { LuaLaTeX: ~ }
\sys_if_engine_xetex:T  { XeLaTeX: ~ }
d\char"200C\char"030C\char"200C\char"0304\char"200C\char"0323\char"200C\char"0326
y\char"200C\char"030D\char"200C\char"0311\char"200C\char"0310\char"200C\char"0302\char"200C\char"0301\char"200C\char"0353\char"200C\char"0347
n\char"200C\char"0306\char"200C\char"0308\char"200C\char"1DD8\char"200C\char"0304\char"200C\char"0307\char"200C\char"032D\char"200C\char"0332\char"200C\char"032B\char"200C\char"0323
a\char"200C\char"0363\char"200C\char"0306\char"200C\char"0309\char"200C\char"0324\char"200C\char"0330\char"200C\char"032A
}
\ExplSyntaxOff
\begin{document}
\dynamicdiacritics
\end{document}


I don’t have the patience to type more than the first letter, but here’s the principle: enter the letter first, then the diacriticals above it, starting with the one closest to the letter and working out, and after that the diacriticals below it, again starting from the closest and working out.

Here I’ve done it entering the combining diacriticals directly (in Emacs, using C-x 8), and again using \char:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Brill}
\begin{document}
ḍ̦̌̄ \textit{or} d\char"030C\char"0304\char"0323\char"0326% no spaces, or the diacritics will appear after the character
\end{document}


• Are you using LuaLaTeX? I just realized that this is an engine problem. Apr 19, 2019 at 15:04
• Yes, lualatex is almost the only thing I use, and I’ve used it here. Apr 19, 2019 at 15:07
• Just tried with xelatex. The diacriticals under the letter are OK, but those above are too low, so that one of them collides with the letter. Apr 19, 2019 at 15:25
• I really appreciate your constructive answer. However there are two things I want to point out: 1. “The Brill” is supposed to be able to handle stacked diacritics in any order (regardless of above first or below first, as long as the order is from inner-most to outer-most), as my updated example shows (the “y” for XeLaTeX). 2. For LaTeX3 programming (in a \ExplSyntaxOn and \ExplSyntaxOff pair), spaces are ignored, so my original code is fine. That being said, without your answer, I couldn’t possibly realize that the problem lies with the engine. Apr 19, 2019 at 15:46
• Your first claim is contradicted by the User Guide included in the font’s zipped archive. I don’t pretend to know anything about LaTeX3 programming and therefore didn’t try that approach, but I’m curious what the advantage to using it here would be, since this elaborate stacking isn’t something you’d use every day. Apr 19, 2019 at 15:54