Monospace fonts should disable stretchy spaces

[alerque]

Ignoring for the moment the egregiously long space stretch happening here because parfillskip didn't kick in, the monospaced \code bit of this line shouldn't have allowed spaces to stretch:

I know how to disable this myself, but it seems like their should be a less verbose way to do it. Either monospace fonts should be detected and this should happen automatically or there should me a much simpler way to set this as part of \font or something.

[ctrlcctrlv]

@alerque How do I disable it?

[alerque]

There are two possible mechanisms depending on how your document is setup. The legacy one can be disabled like this:

SILE.settings.set("document.spaceskip", SILE.length("1spc"))

Since not specifying any stretch or shrink on a SILE length defaults them to zero this will suppress that behavior. The newer one can be suppressed like this:

SILE.settings.set("shaper.spacestretchfactor",  0)
SILE.settings.set("shaper.spaceshrinkfactor",  0)

The obvious problem (and hence this issue) is that it's scoped to the document (or shaper), not the duration of the font, so you need to retrieve the value, stash it, then disable it, then restore it when your thing goes out of scope.

[Omikhleia]

For well-made Latin OpenType fonts, the fact it's intended to be a "monospace" font can be deduced from one of the PANOSE properties in the OS/2 table. We could therefore easily detect this and consider using a fixed inter-word space in this case...

Here is a quick demonstration monospace.diff.txt (diff against SILE 0.15.5).

But playing with it, in situation where the surrounding context gets all sorts of space stretching or shrinking for justification, you would quickly realize that it's not probably what you expected for nice typography....

• There might be cases when you wouldn't want this behavior, so it would require another set of settings for enabling/disabling it.
• In a context of mixed normal and monospace text (as in your example, typically a documentation with running text interspersed with code snippets, one could expect the space from the surrounding context to be automatically inherited (as if the elementary words only where switched to the monospace font). That would be the real killer feature, and it would also kind of be doable, looking at the shaped nodes in sequence (e.g. possibly in the typesetter's shapeAllNodes in a similar way as the italic correction) -- but it would soon get intricate too (e.g. what if the running text starts with monospace to latter switch to variable space? EDIT: and how to explain hbox'd content that gets shape on its own at a different time than the surrounding nnodes, etc. Lots of pitfalls to check and address)...

That is to say, this 4-year old enhancement idea is very interesting, but likely needs a more thoughtful specification.