Hi Branden, On Sun Feb 16, 2025 at 5:22 AM CET, G. Branden Robinson wrote: > At 2025-02-10T18:23:14+0100, onf wrote: > > Speaking of ignoring scale indicators, I wonder why `cs` still > > ignores them in groff? > > I think for the same reason that they're ignored in the arguments to the > `ss` request. > > These requests (uniquely?) interpret their arguments in bespoke units > not used elsewhere.
For cs, this applies only to the second argument, not to the third. > groff(7): > .cs f Disable constant‐width glyph spacing mode for font f. > .cs f n Enable constant‐width glyph spacing mode for font f at > n/36 ems. > .cs f n p Enable constant‐width glyph spacing mode for font at > n/36 ems, as if one em equals p scaled points. Looking back at it now, though, I realize that this is due to the argument p being treated similarly to an argument to ps. Intuitively I expected it to be treated differently since it doesn't set point size and mentions ems. In particular, I was expecting the following to work: .cs CR 36 1m but it gives: warning: 'm' scaling unit invalid in context; convert to 'z' or 'u' > Another reason applicable to `cs` in particular is that, like the `\S` > and `\H` escape sequences for applying crude transforms to a font's > glyphs, one seldom sees it used. Possibly track kerning `tkf` is > thought more appealing for modern digital fonts. Fair enough. I was just wondering if there is a particular reason why the above is not supported besides implementation costs. > Veterans of the typewriter era and those who grew up with early micros > with ultra-crude graphic capabilities might recall the use of "constant > spacings" larger than 36 36ths of an em for special effects.[1] > > $ nroff EXPERIMENTS/star-trek-cs.roff > S T A R T R E K > [...] > > nroff could spare a person some tedious computations. Aha, so cs can be used instead of tkf in constant-width mode for this sort of effect? That's interesting, I haven't thought about that. ~ onf
