LaTeX: disable rounded corners for code cells

[mgeier]

Closes #684.

[mgeier]

Thanks as always for your invaluable help!

so you might want to also reset the background colour to white and the border colour to black.

When using the Sphinx master the code cells already have the expected colors.

This is set via VerbatimColor and VerbatimBorderColor:

https://github.com/spatialaudio/nbsphinx/blob/30dd9728ea674a0a97cf1c11d695a25491d58212/src/nbsphinx.py#L345-L346

(this is in a code block that's only for Sphinx 5.1.0+, and only for "fancy" output cells)

There's another part of the code that sets VerbatimColor and VerbatimBorderColor, which I guess is necessary for the non-fancy outputs (i.e. outputs with plain text):

https://github.com/spatialaudio/nbsphinx/blob/30dd9728ea674a0a97cf1c11d695a25491d58212/src/nbsphinx.py#L2224-L2240

Is this the wrong way to do it?

Should I use pre_border-TeXcolor and pre_background-TeXcolor instead? And if yes, would the benefit outweigh the lost backwards-compatibility?

And regarding manipulating latex_elements['sphinxsetup']: would it be possible to avoid this and instead include the following changes in LATEX_PREAMBLE in a way that it only affects Jupyter code cells and not all sphinxVerbatim boxes?

pre_border-radius=0pt,
pre_box-decoration-break=clone,

If you use the legacy alternative names (and for colours stick with old syntax) the change will not be incompatible with Sphinx <5.1.0 except for pre_box-decoration-break which which definitely had no equivalent with Sphinx <5.1.0.

It is unfortunate that the default changed, but I guess I can live with this minor blemish for users who are not able to use Sphinx 5.1.0+, but it should still not cause an error.

So would I have to use ...

\@ifpackagelater{sphinx}{2022/06/30}{...

... for this setting?

[jfbu]

so you might want to also reset the background colour to white and the border colour to black.

When using the Sphinx master the code cells already have the expected colors.

This is set via VerbatimColor and VerbatimBorderColor:

https://github.com/spatialaudio/nbsphinx/blob/30dd9728ea674a0a97cf1c11d695a25491d58212/src/nbsphinx.py#L345-L346

(this is in a code block that's only for Sphinx 5.1.0+, and only for "fancy" output cells)

ah ok, yes. I had forgotten about that and had written my comment before checking latex build with current nbsphinx and sphinx master.

There's another part of the code that sets VerbatimColor and VerbatimBorderColor, which I guess is necessary for the non-fancy outputs (i.e. outputs with plain text):

https://github.com/spatialaudio/nbsphinx/blob/30dd9728ea674a0a97cf1c11d695a25491d58212/src/nbsphinx.py#L2224-L2240

Is this the wrong way to do it?

a priori, this looks like good way of doing it.

Should I use pre_border-TeXcolor and pre_background-TeXcolor instead? And if yes, would the benefit outweigh the lost backwards-compatibility?

no benefit, you should stick with legacy VerbatimColor and VerbatimBorderColor. I have not heard of plans at Sphinx LaTeX committee ;-) to remove them, and if there are comments to this effect hidden in Sphinx codebase, they must have been written under a state of exaltation which should be re-evaluated. They will be kept for backwards compatibility. Sphinx handles the legacy and new denominations as perfect aliases.

with Sphinx 5.3.0+ the colour can be specified with an enlarged syntax, not only stuff such as {named}{nbsphinx-code-bg} you can also use xcolor syntax such as VerbatimColor=red!10, but that will work only for users having xcolor in their LaTeX installation which I guess must be the case of everyone, but many years ago some Linux distros made it more difficult as users had to install xcolor especially.

And regarding manipulating latex_elements['sphinxsetup']: would it be possible to avoid this and instead include the following changes in LATEX_PREAMBLE in a way that it only affects Jupyter code cells and not all sphinxVerbatim boxes?

pre_border-radius=0pt,
pre_box-decoration-break=clone,

(edit: I think I understood better your question a bit further down, so keep reading to the end...) You can add to LaTeX code specific to such and such environment ultimately wrapping sphinxVerbatim usage of \sphinxsetup{...} with the above as argument. But I am not sure I get the situation right. Don't you want to avoid the slice styling of all boxes ultimately using sphinxVerbatim at page-breaks?

If you use the legacy alternative names (and for colours stick with old syntax) the change will not be incompatible with Sphinx <5.1.0 except for pre_box-decoration-break which which definitely had no equivalent with Sphinx <5.1.0.

It is unfortunate that the default changed, but I guess I can live with this minor blemish for users who are not able to use Sphinx 5.1.0+, but it should still not cause an error.

So would I have to use ...

\@ifpackagelater{sphinx}{2022/06/30}{...

... for this setting?

Yes, inside such conditional true branch you can add

\sphinxsetup{pre_border-radius=0pt, pre_box-decoration-break=clone}

but don't use it in the false branch which will be executed for Sphinx <5.1.0. You can use \sphinxsetup multiple times. The only thing is to make sure it does not get executed before \usepackage{sphinx}.

You can use as above \sphinxsetup inside LATEX_PREAMBLE, because it ends up injected in the latex document after \usepackage{sphinx}. You don't have to put the keys=values inside the latex_elements['sphinxsetup'], they can be put in latex_elements['preamble'] if wrapped in \sphinxsetup{...} LaTeX "command".

[mgeier]

Thanks a lot for your help!

In ceaab818f020ddf3531dc6bcc3db106923896ecb, I removed the sphinxsetup config manipulation and added the Sphinx version check. I think this works well.

But I hate rounded corners so much! So I decided to make the settings not only for Jupyter code cells, but for all code blocks: 129c2e30ed2912fcf28946c13834852cdd81ffa7. I think it's better if all of the code blocks look the same by default, without users having to worry about this.

What do you think about these changes?

[jfbu]

What do you think about these changes?

Looks good to me to make (edit: to have made) the settings for all kinds of code blocks...

[mgeier]

Thanks a lot for your help, @jfbu!