Follow-up Comment #2, bug #60665 (project groff): [comment #1 comment #1:] > Maybe troff devices always have a horizontal resolution greater than > one-twelfth of an em, and that is the smallest amount of distributable > inter-word space we can manipulate with the .ss request.
That's slightly off in the details (.ss's units are 1/12 of the font's space width, which itself is typically 1/4 em in modern fonts, giving .ss a 1/48 em granularity) but basically sound reasoning (1/48 em still dwarfs the basic unit in PostScript and PDF; I'm admittedly unfamiliar with other output devices, though). > I think you're right--uneven space distribution consequent to adjustment > is something that's only going to be visible in the nroff context. I want > to say that without lying to people about what's happening, though. Fair enough, but I don't think omitting implementation details and talking only about visible results is a lie; on the contrary, it's the purpose of end-user documentation, whose readers don't generally care how the code works (else they'd be reading that rather than a manual). This kind of detail seems more appropriate for developer documentation, if such a thing existed, or code comments, if such things existed. > Urp. Will fix that in the near term. I see commit c431cbc0 <http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c431cbc0> has done this. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?60665> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
