Revision history [back]

I don't have your font. But I can reproduce your problem while using the "Inconsolata" mono font.

OTOH, I obtain correct results by using minted instead of listings (up to the specialization of the font: see below). Which I do routinely anyway, since listings doesn't support easily anything else than US "english", which is an excruciating pain in the *$$ for about 96% of this planet's population...

(while I'm sure that they exist, I didn't take the time to look up the necessary idioms to set the font options you desire for your listings. I'll do that if/when I have the time...).

So:

It is possibly a bug of listings when used IN/triggered by Sagetex.
Using a modern alternative (i. e. listings) solves the problem.

It might be worthy to open an issue on the Sagetex Github page...

I don't have your font. But I can reproduce your problem while using the "Inconsolata" mono font.

(while I'm sure that they exist, I didn't take the time to look up the necessary idioms to set the font options you desire for your listings. I'll do that if/when I have the time...).

So:

It is possibly a bug of listings when used ~~IN/triggered~~ in/triggered by Sagetex.
Using a modern alternative (i. e. listings) solves the ~~problem.~~problem (with the obvious drawback to have to allow -shell-escape, which is a nice security hole...).

It might be worthy to open an issue on the Sagetex Github page...

As for fixing that up yourself, well... First look if listings used alone (i. e. by typesetting a Sage snippet with \lstinputlisting, IIRC) gives you correct results or not.

If so, the problem is in SageTeX, in which case you have now a reasonable chance to get your patch in a future version of SageTeX, now that the Sage core team can act on it.

If not, the problem is in listings. Then ... good luck to get a fix: the authors of listings seem to be unreacheable, and about 15 years of pleas to get support for no-US-ASCII have been ignored...