line-height from custom pygments theme being ignored

[asmeurer]

In our custom pygments theme for SymPy, we set the line-height attribute using _pre_style: https://github.com/sympy/sympy/blob/68c37df362e8585d72fc7ef490013bb8eff16e3e/doc/src/_pygments/styles.py#L25-L29

However, this is being ignored by the docs

We need this so that Unicode pretty printed output doesn't add extra space between lines. See for example https://docs.sympy.org/dev/tutorial/printing.html#unicode-pretty-printer and compare to our previous theme which set this attribute correctly https://docs.sympy.org/latest/tutorial/printing.html#unicode-pretty-printer

I can work around this by adding it to the custom.css, but it seems preferable to include it in the pygments theme since pygments allows this.

[pradyunsg]

Hmm... The reason this line exists in the Furo is because the value set by the default/most pygments themes results in extremely "tight" code blocks, when using the system font stack. It works fine if you use monospace or a code font with a lot of vertical space in its glyphs.

However, that is not the case for MacOS, Windows and Ubuntu when using the system font stack (at least, as I remember from the last time I checked). I just tried removed that but looking at the output from that reminded me why I had added this. :)

---

(current, with the line-height override)

---

("respecting" pygments' line-height)

[asmeurer]

I can understand the tighter code is undesirable in most cases. We need it just so that our pretty printing looks good. Maybe we should consider whether that too negatively affects everything else.

I actually forgot about font variability here. Our docs look best with DejaVu Sans Mono, because that's the best font for Unicode pretty printing, but it only uses that if you have it installed.
This reminds me that for the SymPy docs we were planning to make a webfont for DejaVu Sans Mono so that it is guaranteed to be used by everyone on our docs. If we do that, that would remove the font variability from the equation.

If you don't have DejaVu Sans Mono installed, here's screenshots showing why we need this. Personally I don't think the tightness is too bad for everything else, but I guess that's a personal judgement call.

Would be nice if we could get the best of both worlds somehow, but I don't know if that's possible.

[pradyunsg]

Would be nice if we could get the best of both worlds somehow, but I don't know if that's possible.

I'm not sure either TBH.

furo/src/furo/assets/styles/content/_code.sass

Line 40 in 5abeb9f

line-height: 1.5

This line still exists in Furo for now. I've filed #720 for further discussion on this, and for tracking a fix for this.

[kdeldycke]

I can confirm the issue.

I have a dozen of unicode-based tables that are rendered into code blocks, and the wrong line height makes the lines of tables appears to be disjoint.

Here is a screenshot:

For context, this has been produced with the following dependencies:

 + accessible-pygments==0.0.5
 + alabaster==1.0.0
 + babel==2.17.0
 + beautifulsoup4==4.14.2
 + docutils==0.21.2
 + furo==2025.9.25
 + imagesize==1.4.1
 + jinja2==3.1.6
 + markdown-it-py==3.0.0
 + markupsafe==3.0.3
 + mdit-py-plugins==0.5.0
 + mdurl==0.1.2
 + myst-parser==4.0.1
 + packaging==25.0
 + pygments==2.19.2
 + pyyaml==6.0.3
 + roman-numerals-py==3.1.0
 + snowballstemmer==3.0.1
 + soupsieve==2.8
 + sphinx==8.2.3
 + sphinx-autodoc-typehints==3.5.2
 + sphinx-basic-ng==1.0.0b2
 + sphinx-copybutton==0.5.2
 + sphinx-design==0.6.1
 + sphinx-issues==5.0.1
 + sphinxcontrib-applehelp==2.0.0
 + sphinxcontrib-devhelp==2.0.0
 + sphinxcontrib-htmlhelp==2.1.0
 + sphinxcontrib-jsmath==1.0.1
 + sphinxcontrib-mermaid==1.0.0
 + sphinxcontrib-qthelp==2.0.0
 + sphinxcontrib-serializinghtml==2.0.0
 + sphinxext-opengraph==0.13.0
 + typing-extensions==4.15.0