Add LaTeX Support for ligatures

[breandan]

Fira Code supports contextual substitutions for rendering ligatures in LaTeX documents using the verbatim environment. Although the font renders correctly, ligatures do not appear to work out of the box with JetBrains Mono (or at least using the same configuration described by Fira Code).

Tested on the following versions:

XeTeX 3.14159265-2.6-0.99998 (TeX Live 2017/Debian)
kpathsea version 6.2.3
Copyright 2017 SIL International, Jonathan Kew and Khaled Hosny.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the XeTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the XeTeX source.
Primary author of XeTeX: Jonathan Kew.
Compiled with ICU version 60.2; using 60.2
Compiled with zlib version 1.2.11; using 1.2.11
Compiled with FreeType2 version 2.8.1; using 2.8.1
Compiled with Graphite2 version 1.3.11; using 1.3.11
Compiled with HarfBuzz version 1.7.2; using 1.7.2
Compiled with libpng version 1.6.34; using 1.6.34
Compiled with poppler version 0.62.0
Compiled with fontconfig version 2.12.6; using 2.12.6

[breandan]

@tonsky Do you know if Fira Code needed to implement any special OTF features to get contextual glyphs to work with the fontspec package? Maybe supporting this is as simple as publishing an OTF version? I tried several variations of Contextuals=Alternate, Ligatures=TeX, Ligatures=Common, etc. but none of these options seem to work.

[tonsky]

I have no idea but Fira Code repo has this wiki page https://github.com/tonsky/FiraCode/wiki/LaTeX-instructions. Maybe it can be useful

[MTCoster]

I know this is a slightly old issue, but I’ve just stumbled on it after finding a solution on my own. I’ve been using this in my preamble:

\usepackage{fontspec}

\makeatletter
\def\verbatim@nolig@list{}
\makeatother

\newfontfamily\jbmono{jetbrainsmono}[Path, Extension=.ttf, Contextuals={Alternate},
    NFSSFamily=jbmono,% Required for minted; see fontspec§4.2
    UprightFont = fonts/*-regular,
    ItalicFont = fonts/*-italic,
    BoldFont = fonts/*-bold,
    BoldItalicFont = fonts/*-bolditalic,
    FontFace = {sb}{n}{fonts/*-medium},
    FontFace = {sb}{it}{fonts/*-mediumitalic},
    FontFace = {eb}{n}{fonts/*-extrabold},
    FontFace = {eb}{it}{fonts/*-extrabolditalic}]

With files named jetbrainsmono-regular.ttf etc. in a folder called fonts.

---

[ningit]

Ligatures are working out of the box for JetBrains Mono in TeX Live 2021. The ligatures in the following LaTeX file correctly appear in the PDFs produced by xelatex and lualatex.

\documentclass{standalone}
\usepackage{fontspec}
\setmainfont{JetBrains Mono}

\begin{document}
	=> #? <=
\end{document}

They also work within lstlistings and other environments if they have been set up as explained in the Fira Code instructions.

However, copy-pasting and searching text with ligatures from the PDF does not properly work. For example, copying the arrow => yields the text ^> instead of =>. This problem does not appear with Fira Code, as shown by the following example.

\documentclass{standalone}
\usepackage{fontspec}

\begin{document}
\begin{tabular}{ll}
	JetBrains Mono & \fontspec{JetBrains Mono} => \\
	Fira Code & \fontspec{Fira Code} =>
\end{tabular}
\end{document}

Here is the generated PDF. I am using the latest stable version of JetBrains Mono (v2.242).

PD: This copy-paste problem can be solved with \XeTeXgenerateactualtext=1 in XeLaTeX, but this increases the size of the generated document and there should be no need.

[ningit]

At least for completeness, I write some findings about the copy and search issue:

• When copying from a PDF, the translation from the glyph that has been typeset to the sequence of Unicode characters it represents is based on the ToUnicode table attached to this font in the document.

• Fira Code maps => to two composable glyphs, one for the equal sign and another for the arrow head, that look like a single one together. On the contrary, JetBrains Mono maps => to a space glyph followed by another one containing the full arrow and occupying also the space of the first space. Every ligature in the font is implemented using the same space glyph.

• The PDF generators used by lualatex and xelatex infer the ToUnicode table by inverting (somehow heuristically) the mapping from characters to glyphs that follows from the ligature substitution rules. Since the same space glyph SPC is used in the translation of many sequences of characters, it is not clear which sequence of Unicode characters corresponds to SPC (it not the empty one) and it is mapped to ^ everywhere.

• Everything would work fine if the font mapped => directly to the second glyph that contains the full arrow without SPC (see Ligature substitution rules without SPC #486), but I do not know if this may cause issues elsewhere.

This might be however not a problem of the font but of the LaTeX engines. In LuaLaTeX, if the JetBrains Mono font is loaded with the Renderer=HarfBuzz option, the text is properly copyable and searchable, although uneeded ActualText annotations are added to the PDF.

[breandan]

I can confirm that ligatures now work as expected. I am using LuaLaTeX and the following snippet in the preamble:

\setmonofont{JetBrainsMono}[
  Contextuals={Alternate},
  Path=./JetBrainsMono/,
  Extension = .ttf,
  UprightFont=*-Regular,
  BoldFont=*-Bold,
  ItalicFont=*-Italic,
  BoldItalicFont=*-BoldItalic
]

For anyone writing Kotlin, I prefer listings with @cansik/kotlin-latex-listing. It seems to work well better than minted.