LaTeX: background gray in PDF code-blocks has a lesser contrast for xelatex with non-highlighted tokens

[jfbu]

Describe the bug

Example with 'xelatex' for latex_engine:

Same with default 'pdflatex':

The choice of default background gray was done with testing with pdflatex. If testing with xelatex, it could have been chosen possibly even lighter.

But this issue is mainly applying to the few non highlighted tokens.

It is a font issue, the one used for xelatex/lualatex is thinner than the one used for pdflatex. It may also be compounded with a PDF viewer anti-aliasing effect, for these thin glyphs on colored background.

How to Reproduce

Any project with code-blocks

Environment Information

Sphinx 6.1.3

Sphinx extensions

No response

Additional context

LaTeX installation from TeXLive 2023.

[picnixz]

Instead of trying to figure out which background gray to choose, I suggest changing the font in a tt-like environments and fallback to txtt as used by pdflatex:

\newfontfamily\sphinxttfamily{txtt}
\renewcommand{\ttfamily}{\sphinxttfamily}

% if fontspec implements \setfontfamily
% \setfontfamily\ttfamily{txtt}

Alternatively, we could change the font used by the pdflatex build and get something close to FontMono but I don't know of any similar font (at least with that level of contrast).

[jfbu]

Instead of trying to figure out which background gray to choose, I suggest changing the font in a tt-like environments and fallback to txtt as used by pdflatex

But the code-blocks may contain Unicode code points which may have motivated the Sphinx user to choose xelatex/lualatex. So we can't do that.

Alternatively, we could change the font used by the pdflatex build and get something close to FontMono but I don't know of any similar font (at least with that level of contrast).

I don't either.

While writing this comment I got worried that perhaps the issue was not limited to monospace family: our tables use now per default zebra-striped rows, and perhaps the contrast got less good there compared to pdflatex, as I based the set-up only on pdflatex testing. I now tried with a xelatex build of our document and this screenshot seems to indicate the problem is indeed localized to FreeMono:

We can see serif and sans font there, and they are ok.

Maybe there is some fontspec font feature or attribute we can try to trigger to "embolden" the font. I will look a bit.

edit: to build our document with 'xelatex' I applied this diff

diff --git a/doc/conf.py b/doc/conf.py
index 19b8b2a2e..218638d3a 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -58,16 +58,17 @@ epub_show_urls = 'inline'
 epub_use_index = False
 epub_description = 'Sphinx documentation generator system manual'
 
+latex_engine = 'xelatex'
 latex_documents = [('index', 'sphinx.tex', 'Sphinx Documentation',
                     'the Sphinx developers', 'manual', 1)]
 latex_logo = '_static/sphinx.png'
 latex_elements = {
-    'fontenc': r'\usepackage[LGR,X2,T1]{fontenc}',
+#    'fontenc': r'\usepackage[LGR,X2,T1]{fontenc}',
     'passoptionstopackages': r'''
 \PassOptionsToPackage{svgnames}{xcolor}
 ''',
     'preamble': r'''
-\DeclareUnicodeCharacter{229E}{\ensuremath{\boxplus}}
+%\DeclareUnicodeCharacter{229E}{\ensuremath{\boxplus}}
 \setcounter{tocdepth}{3}%    depth of what main TOC shows (3=subsubsection)
 \setcounter{secnumdepth}{1}% depth of section numbering
 \setlength{\tymin}{2cm}%     avoid too cramped table columns

[picnixz]

But the code-blocks may contain Unicode code points which may have motivated the Sphinx user to choose xelatex/lualatex. So we can't do that.

Fair enough (I though that txtt is ok but perhaps it does not support sufficiently many glyphs). By the way, why was FreeMono chosen over the default Latin Modern from lmodern which is kind of the default for xelatex (I think it supports the same set of unicode characters)?

Maybe there is some fontspec font feature or attribute we can try to trigger to "embolden" the font. I will look a bit.

I don't think we can do it but it's worth researching. I think fontspec allows to play with the font using stacked \strong, but I don't think this is the correct approach.

[jfbu]

Fair enough (I though that txtt is ok but perhaps it does not support sufficiently many glyphs).

txtt is a traditional TeX font for Knuth non-Unicode TeX which supports only 256 glyphs per encoding and may interface with user in the so-called T1, LY1, OT1, TeX "fontenc" encodings (and some extension via textcomp package and TS1 encoded font files). It does not exist in the "TU" (aka tex unicode) pseudo-encoding suitable for xelatex/lualatex with fontspec.

By the way, why was FreeMono chosen over the default Latin Modern from lmodern which is kind of the default for xelatex (I think it supports the same set of unicode characters)?

It is the LaTeX default by LaTeX upstream maintainers for historical reasons (Latin Modern was developed by Polish TeX user groups, and was widely promoted at time of creation, but Computer Modern Unicode is much much closer to the original Knuth Computer Modern) but Latin Modern as its name indicates supports only Latin scripts. In contrast the GNU FreeFont supports many more scripts (in particular Greek and Cyrillic).

and the crucial fact here is that LaTeX has no built-in support for automatic rescue when a glyph is not supported in a font, and they will not change that because they prefer a PDF with rectangles for missing glyphs than glyphs picked up from fall-back fonts; all fall-back has to be configured manually by user if needed, and 99% of LaTeX users do not know how to do that because the "New" LaTeX font system from perhaps 30 years ago is basically documented only at package author level and we as Sphinx LaTeX maintainers can little about this; besides missing glyphs if they happen will typically be overlooked by Sphinx latex users because except if one does \tracinglostchars3 which is new (perhaps one or two years or three), the PDF build does not raise an error but only warning in the log "there is no character ... in font..."

Maybe there is some fontspec font feature or attribute we can try to trigger to "embolden" the font. I will look a bit.

I don't think we can do it but it's worth researching. I think fontspec allows to play with the font using stacked \strong, but I don't think this is the correct approach.

Yes, I didn't and don't expect now to find a fontspec way, I think it may be possible in lualatex which can manipulate font (I recall seeing some FakeBold somewhere). An extreme option would be to use FreeMono Bold, I did not yet try it out, but this is probably a no-go, as it will make Pygments highlighting partially hampered.

A better way goes like you said: adopt some other font. Match with FreeSerif and FreeSans is not fundamental (after all Sphinx user times+helvetica+courier for long time, until this was modernized and courier replaced by txtt) but the font must have wide Unicode coverage and be available widely. (and come with TeXLive)

[jfbu]

using bold weight always of FreeMono is a no-go, already because it cripples Pygments highlighting output and also because it is really bold:

[picnixz]

but the font must have wide Unicode coverage and be available widely. (and come with TeXLive)

I don't know if this is a suitable choice, but what about Noto? Or more generally, what about choosing specific fonts when a document contains special glyphs not supported by the default font ? Like, we could (on the builder's side) check that the characters being written are within some correct unicode range, and if they are not, we would switch to a font family that supports all characters in the output. The user could also specify the "default" fallback font to check in priority (for instance, if the whole document is in huge code-block in Chinese, it's probably better to directly use a font supporting this range instead of first trying all other fonts).

using bold weight always of FreeMono is a no-go, already because it cripples Pygments highlighting output and also because it is really bold:

Yes, so I think we need to find an alternative.

and the crucial fact here is that LaTeX has no built-in support for automatic rescue when a glyph is not supported in a font

For unsupported characters, we could actually do it on the builder side by checking unicode ranges of the text being written. The idea is to load the font file at the beginning of the process and when writing, we check the user content and emit warnings if needed. Since this might be quite costly for large documents, this could be enabled on demand, or only if we encounter non-UTF8 characters (again, we could enable it depending on the language of the document being produced or depending on other configuration values).

[jfbu]

An option could be NewComputerModern which is a TeXLive provided font. Here we only pick the monospace family:

diff --git a/sphinx/builders/latex/constants.py b/sphinx/builders/latex/constants.py
index ce646d024..1f7252764 100644
--- a/sphinx/builders/latex/constants.py
+++ b/sphinx/builders/latex/constants.py
@@ -49,12 +49,12 @@ XELATEX_DEFAULT_FONTPKG = r'''
   BoldFont       = *Bold,
   BoldItalicFont = *BoldOblique,
 ]
-\setmonofont{FreeMono}[
-  Extension      = .otf,
-  UprightFont    = *,
-  ItalicFont     = *Oblique,
-  BoldFont       = *Bold,
-  BoldItalicFont = *BoldOblique,
+\setmonofont{NewCMMono10}[
+  Path,
+  UprightFont    = *-Regular,
+  ItalicFont     = *-Italic,
+  BoldFont       = *-Bold,
+  BoldItalicFont = *-BoldOblique,
 ]
 '''

(in the above I use Path to tell xetex to look also for fonts in the LaTeX distribution, and look not only in system fonts)

as it gives


which seems ok. (maybe we need to modify then

sphinx/sphinx/builders/latex/constants.py

Line 145 in e2f66ce

'fvset': '\\fvset{fontsize=\\small}',

to use fontsize=auto, not tested). edit I tested and it is definitely better with fontsize=auto.

but I got

Latexmk: ====List of undefined refs and citations:
  Missing character: There is no ⊞ (U+229E) in font [NewCMMono10-Regular]/OT:script=latn;language=dflt;!
  Missing character: There is no ⊞ (U+229E) in font [NewCMMono10-Regular]/OT:script=latn;language=dflt;!

for our document so I needed

diff --git a/doc/conf.py b/doc/conf.py
index 19b8b2a2e..b9b81c2d7 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -58,16 +58,18 @@ epub_show_urls = 'inline'
 epub_use_index = False
 epub_description = 'Sphinx documentation generator system manual'
 
+latex_engine = 'xelatex'
 latex_documents = [('index', 'sphinx.tex', 'Sphinx Documentation',
                     'the Sphinx developers', 'manual', 1)]
 latex_logo = '_static/sphinx.png'
 latex_elements = {
-    'fontenc': r'\usepackage[LGR,X2,T1]{fontenc}',
+#    'fontenc': r'\usepackage[LGR,X2,T1]{fontenc}',
     'passoptionstopackages': r'''
 \PassOptionsToPackage{svgnames}{xcolor}
 ''',
     'preamble': r'''
-\DeclareUnicodeCharacter{229E}{\ensuremath{\boxplus}}
+%\DeclareUnicodeCharacter{229E}{\ensuremath{\boxplus}}
+\catcode`⊞\active\protected\def⊞{\ensuremath{\boxplus}}
 \setcounter{tocdepth}{3}%    depth of what main TOC shows (3=subsubsection)
 \setcounter{secnumdepth}{1}% depth of section numbering
 \setlength{\tymin}{2cm}%     avoid too cramped table columns

which is specific to our document but maybe indicative of less extensive Unicode coverage compared to FreeMono.

Looking at Ubuntu packages I got this i.e. it is (at least for kinetic ok also in focal but not in bionic). It is not in bionic which is 18.04LTS which I think we support (not checked).

Anyway it is only one of possible Unicode monospace font to adopt if we decide.

But so far nobody had complained about the lightness of FreeMono (which is inherited from Courier from which it seems to take inspiration).

[jfbu]

but the font must have wide Unicode coverage and be available widely. (and come with TeXLive)

I don't know if this is a suitable choice, but what about Noto?

Why not. If it is distributed by TeXLive I guess it qualifies as opensource compatible font. And it has very extensive coverage of course.

Or more generally, what about choosing specific fonts when a document contains special glyphs not supported by the default font ?

I was going to tag this issue "help wanted" and will definitely do so now ;-). I think this is ambitious goal

Like, we could (on the builder's side) check that the characters being written are within some correct unicode range, and if they are not, we would switch to a font family that supports all characters in the output.

Help wanted! Lots of maintenance there!

The user could also specify the "default" fallback font to check in priority (for instance, if the whole document is in huge code-block in Chinese, it's probably better to directly use a font supporting this range instead of first trying all other fonts).

Chinese users I think have their own ways using xeCJK package probably... Help wanted!

and the crucial fact here is that LaTeX has no built-in support for automatic rescue when a glyph is not supported in a font

For unsupported characters, we could actually do it on the builder side by checking unicode ranges of the text being written. The idea is to load the font file at the beginning of the process and when writing, we check the user content and emit warnings if needed. Since this might be quite costly for large documents, this could be enabled on demand, or only if we encounter non-UTF8 characters (again, we could enable it depending on the language of the document being produced or depending on other configuration values).

Unfortunately I think even if we embark upon this ambitious goal we will not have a smooth sailing. I will link to an issue that the translate-to-Japanese team of Python docs encountered:python/python-docs-ja#35 . They ended up using luatex-ja.

(the above link is a bit confusing here, sorry, because their starting point was not xelatex, but platex or rather probably uplatex which is used by Sphinx for Japanese; sorry about that but leaving the link anyhow as it contains some aspects of complex font problems in LaTeX)

[jfbu]

@picnixz thanks for feedback and ideas 👍 I forgot to say I currently have been using for some time Source Code Pro in my Emacs and even in Firefox. (but it is wide)

[jfbu]

@picnixz I may be wrong but it appears NotoSansMono from TeXLive has no Italic or BoldItalic variant. The documentation from texdoc noto seems to confirm that.

[picnixz]

I may be wrong but it appears NotoSansMono from TeXLive has no Italic or BoldItalic variant. The documentation from texdoc noto seems to confirm that.

Oh, didn't think that it would be the case. It appears that it is a feature request but probably not under consideration (notofonts/latin-greek-cyrillic#203)...

[jfbu]

For people willing to help: we need a monospace Unicode font supporting at least Latin Greek and Cyrillic (CJK goes via separate pathways a priori but it would be a plus to have simplified Chinese) as well as for example Unicode code points involved in output of Linux tree command, ideally does not require texlive-fonts-extra for Ubuntu and if it does was already included there with 18.04LTS, is also available via TeXLive, has been tested with fontspec \setmonofont with Path and no extension specified so that it will work whether font is opentype or TrueType and whether it is system font or in LaTeX installation font tree both with xelatex and lualatex. And it has to look good on gray background.

[picnixz]

I asked one of my friend and he recommended me MesloLGS NF. It appears that this font is monospace and supports sufficiently many glyphs (according to https://en.likefont.com/font/10896927/).

The issue is that it is not provided by TeXlive. One possibility is to ask for the NF maintainers to do this, or alternatively, shipout the font in the Sphinx installation directly. Or make it an optional dependency when installing Sphinx via pip for instance / add a command-line option that installs it automatically where it should be (I think it we could install it using pip install sphinx[font] for instance. If a user doesn't want that, we would fallback to what we already have but they would need to stick with the bad contrast)

[jfbu]

Thanks for info @picnixz.

As a complement I report here on searching in my TeXLive tree for suitable fonts. For this I used the albatross tool (which must be at release 0.5.0 or newer as formerly the tacit "and" for searched characters acted as "or"). This is command line tool but unfortunately it is not completely suited for piping its output into grep for example which complicates a bit things. Details:

• Invocation has been albatross -b1 -d φ ύ σ с в и д я ─ │ └ ├ : I request some Greek, some Cyrillic and some BOX DRAWINGS characters (for tree output).
• I do not use the -t toggle to search the TeXLive trees because this includes .pfb fonts for PDFLaTeX, and I don't know how to reduce to only the OpenType and TrueType and then output is voluminous,
• I did this on a mac os and I have symlinks from my $HOME/Library/Fonts to the TeXLive OpenType and TrueType, so in effect albatross could see the TeXLive fonts without -t option,
• I manually removed from the output the System fonts,
• and I manually reduced to fonts which I confirmed to be Monospace Fonts.
• and I checked the fonts were listed in macos FontBook as having Bold, Italic, and Bold Italic variants (possibly called Oblique etc...), and these variants still supported Greek and Cyrillic...

Here is result. But I don't think I have a complete TeXLive installation so I may be lacking some fonts.

(there is no albatross option for a github markdown flavor table syntax... but as shown here it supports reST grid tables...)

I also manually added after Font name the number of glyphs it has according to FontBook on macos (only the regular variant).

And finally, as I had exceeded my time quote I went the extra mile and added screenshots of a test. And I added the magic incantation to be sure it works on all systems via font filenames.

• Cascadia Cod3 was a candidate but has no italic variant,
• Noto Sans Mono also was a candidate but no italic variant,
• Go Mono, Nimbus Mono have seemingly less complete Cyrillic coverage than some others (I mean by that some fancy cyrillic letters with diacritics appear to be missing)
• Only DejaVu Sans Mono and FreeMono have the SQUARED PLUS ⊞ as used by our document. But FreeMono does not have the italic or bold glyphs for it.
• Some fonts (DejaVu Sans Mono for example) will need to keep our \fvset{fontsize=\small} because they are Courier-like in (excessive) width but others such as NewComputerModern Unicode are better used with \fvset{fontsize=auto}.

Regarding the ⊞ which our own documentation uses twice there is a simple work-around commented above if we wanted to have it, assuming here we were to build our docs with xelatex.

+----------+------------------------------------------------------------------+
| Name     | Anonymous Pro    (624 glyphs)                                    |
+----------+------------------------------------------------------------------+
| Type     | TrueType                                                         |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/truetype/public/anonymouspro/Anony  |
|          |  mousPro-Regular.ttf                                             |
+----------+------------------------------------------------------------------+

use with fontsize=auto in \fvset and

\setmonofont{AnonymousPro}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-Italic,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldItalic,
]

---

+----------+------------------------------------------------------------------+
| Name     | CMU Typewriter Text Regular   (1866 glyphs)                      |
+----------+------------------------------------------------------------------+
| Type     | CFF                                                              |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/public/cm-unicode/cmuntt.  |
|          |  otf                                                             |
+----------+------------------------------------------------------------------+

use with fontsize = auto in \fvset and

\setmonofont{cmuntt}[
  Path,
  UprightFont    = *,
  ItalicFont     = cmunit,
  BoldFont       = cmuntb,
  BoldItalicFont = cmuntx,
]

---

+----------+------------------------------------------------------------------+
| Name     | DejaVu Sans Mono    (3310 glyphs)                                |
+----------+------------------------------------------------------------------+
| Type     | TrueType                                                         |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/truetype/public/dejavu/DejaVuSansM  |
|          |  ono.ttf                                                         |
+----------+------------------------------------------------------------------+

use with fontsize = \small in \fvset and

\setmonofont{DejaVuSansMono}[
  Path,
  UprightFont    = *,
  ItalicFont     = *-Oblique,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldOblique,
]

---

+----------+------------------------------------------------------------------+
| Name     | Fira Mono    (1485 glyphs)                                       |
+----------+------------------------------------------------------------------+
| Type     | CFF                                                              |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/public/fira/FiraMono-Regu  |
|          |  lar.otf                                                         |
|          | ---------------------------------------------------------------- |
|          |  /some/path/to/texlive/fonts/opentype/public/fira/FiraMono-Obli  |
|          |  que.otf                                                         |
+----------+------------------------------------------------------------------+

use with fontsize = \small in \fvset and

\setmonofont{FiraMono}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-Oblique,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldOblique,
]

---

+----------+------------------------------------------------------------------+
| Name     | FreeMono    (4177 glyphs)                                        |
+----------+------------------------------------------------------------------+
| Type     | CFF, TrueType                                                    |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/public/gnu-freefont/FreeM  |
|          |  ono.otf                                                         |
|          | ---------------------------------------------------------------- |
|          |  /some/path/to/texlive/fonts/truetype/public/gnu-freefont/FreeM  |
|          |  ono.ttf                                                         |
+----------+------------------------------------------------------------------+

use with \small and

\setmonofont{FreeMono}[
  Path,
  UprightFont    = *,
  ItalicFont     = *Oblique,
  BoldFont       = *Bold,
  BoldItalicFont = *BoldOblique,
]

---

+----------+------------------------------------------------------------------+
| Name     | Go Mono    (666 glyphs)                                          |
+----------+------------------------------------------------------------------+
| Type     | TrueType                                                         |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/truetype/bh/gofonts/GoMono-Regular  |
|          |  .ttf                                                            |
+----------+------------------------------------------------------------------+

use with \small  and

\setmonofont{GoMono}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-Regular-Italic,
  BoldFont       = *-Bold,
  BoldItalicFont = *-Bold-Italic,
]

---

+----------+------------------------------------------------------------------+
| Name     | NewComputerModernMono10-Regular    (2564 glyphs)                 |
+----------+------------------------------------------------------------------+
| Type     | CFF                                                              |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/public/newcomputermodern/  |
|          |  NewCMMono10-Regular.otf                                         |
+----------+------------------------------------------------------------------+

use with auto and

\setmonofont{NewCMMono10}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-Italic,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldOblique,
]

---

+----------+------------------------------------------------------------------+
| Name     | Nimbus Mono,NimbusMono-Regular    (763 glyphs)                   |
+----------+------------------------------------------------------------------+
| Type     | CFF                                                              |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/public/nimbus15/zco-Light  |
|          |  .otf                                                            |
|          | ---------------------------------------------------------------- |
|          |  /some/path/to/texlive/fonts/opentype/public/nimbus15/zco-Regul  |
|          |  ar.otf                                                          |
|          | ---------------------------------------------------------------- |
|          |  /some/path/to/texlive/fonts/opentype/public/nimbus15/zcoN-Regu  |
|          |  lar.otf                                                         |
|          | ---------------------------------------------------------------- |
|          |  /some/path/to/texlive/fonts/opentype/public/nimbus15/zcoN-Obli  |
|          |  que.otf                                                         |
+----------+------------------------------------------------------------------+

use with auto and

\setmonofont{zco}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-Oblique,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldOblique,
]

---

+----------+------------------------------------------------------------------+
| Name     | Source Code Pro    (1585 glyphs)                                 |
+----------+------------------------------------------------------------------+
| Type     | CFF                                                              |
+----------+------------------------------------------------------------------+
| Files    |  /some/path/to/texlive/fonts/opentype/adobe/sourcecodepro/Sourc  |
|          |  eCodePro-Regular.otf                                            |
+----------+------------------------------------------------------------------+

use with \small and

\setmonofont{SourceCodePro}[
  Path,
  UprightFont    = *-Regular,
  ItalicFont     = *-RegularIt,
  BoldFont       = *-Bold,
  BoldItalicFont = *-BoldIt,
]

Actually I encountered a problem with SourceCodePro when a long code line wraps, as happens in example above when not using \small. Strange:

See the red crosses above. The LaTeX log contains:

Missing character: There is no ␣ (U+2423) in font [SourceCodePro-Regular]/OT:sc
ript=latn;language=dflt;!

This is is the OPEN BOX glyph and I have to check why XeLaTeX wants to use it as visible space (some one, two, or three years ago, LaTeX changed something in this context). Because it is definitely not Sphinx which tells it to. Ah yes Sphinx has

\DeclareStringOption[\textcolor{red}{\textvisiblespace}]{verbatimvisiblespace}

so the \textvisiblespace gives a missing glyph with Source Code Pro which is both a pain and a pity. I will have to track who is mapping \textvisiblespace to the OPEN BOX U+2423: it is LaTeX with Unicode engines which does

\DeclareUnicodeSymbol{\textvisiblespace}    {"2423}

Really a pity that Source Code Pro does not have the glyph! (I have read somewhere that Adobe supplied fonts usable for free have often problems with things such as placement of apostrophe, but I am not sure).

So now I have to check that all above other fonts have the glyph...

• Fira Mono does not have it!
• Go Mono does not have it!
• Source Code Pro does not haveit!

Hence the list appears to be reduced to (except if we do not use \textvisiblespace and replace by something else).

• Anonymous Pro,
• CMU Typewriter Text Regular,
• DejaVu Sans Mono,
• NewComputerModernMono10-Regular,
• Nimbus Mono.

DejaVu Sans Mono has the highest number of glyphs and has high contrast. It has to be used with \fvset{fonsize=\small like FreeMono.

[jfbu]

NewComputerModernMono10-Regular (2564 glyphs) which I reported already earlier as a candidate looks very legible. It has also a companion font NewComputerModern Math with extensive math support (for use with unicode-math), and the demo documents I saw with it with Greek, Cyrillic and Math are very nice. It is a strong candidate but it is too recent for us to use per default: as it was first uploaded to CTAN in November 2019, so it is not included in distros using TL2018 or earlier, or an early TL2019.

[jfbu]

Regarding DejaVu Sans Mono on Ubuntu bionic (18.04LTS) it appears this means dependency fonts-dejavu-core and also fonts-dejavu-extra for Oblique and BoldOblique. This would have to be added to our CI, but only needs to be indicated in our docs sufficiently clearly, if we decide to use it. Currently we say in https://github.com/sphinx-doc/sphinx/blob/master/doc/usage/builders/index.rst

   Additional packages are needed in some circumstances:

   * ``texlive-lang-cyrillic`` for Cyrillic (and also then
     ``cm-super`` if using the default fonts),
   * ``texlive-lang-greek`` for Greek (and also then
     ``cm-super`` if using the default fonts),
   * ``texlive-xetex`` if :confval:`latex_engine` is ``'xelatex'``,
   * ``texlive-luatex`` if :confval:`latex_engine` is ``'lualatex'``,
   * ``fonts-freefont-otf`` if :confval:`latex_engine` is either
     ``'xelatex'`` or ``'lualatex'``.

so it is only a matter of adding the info. General philosophy here is that people willing to use modernistic engines xelatex or lualatex have to make sure their LaTeX installations is complete enough for that.

---

If we decide to use DejaVu Sans Mono for code-blocks the question then arises whether to aslo use DejaVu Serif and DejaVu Sans for the serif and sans typefaces respectively.

[picnixz]

I personally use DejaVu because some years ago, installing some free font entirely broke my desktop environment (I honestly don't know what happened and I still don't know what I did. I just know that it worked again if I removed the package I installed). So I would be in favor of using DejaVu family. NewComputerModernMono10 looks nicer to me because DejaVu seems more compact, but since it's too recent we might wait for another 5 years until we use it as a default font ?

Concerning DejaVu Sans and Serif, I think it's good to have a uniform font (and that's also what I personally use). Still need other opinions though.