Follow-up Comment #10, bug #67544 (group groff): At 2026-01-28T13:38:14-0500, Dave wrote: > Follow-up Comment #9, bug #67544 (group groff): > > I love all the research. But for now I'd like to propose two specific > actions. I'll put them in separate comments so they're easier to > refer to and reply to individually. > > First, > [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=280724f9d commit > 280724f9d], > the inciting commit for this ticket and referenced in the original > submission, should be reverted before 1.24.
That commit is a one-line change to the gdiffmk(1) man page. _That's_ what you want reverted? It wouldn't bust the C/C++ code freeze, but it seems like a weird request. It's a troff-mode-only cosmetic change to a man page. Regarding freeze-busting, please see <https://lists.gnu.org/archive/html/groff/2026-01/msg00149.html>. > It is the wrong solution to a legitimate problem. From an engineering > standpoint, it fixes one instance of the problem rather than the > general problem, which is suboptimal but not fatal. The fatal flaw is > that the fix is applied unconditionally: the added space does not know > whether the underlying kerning problem exists, meaning that a user > viewing this version of the man page with a properly kerned > font--perhaps even the TR font from a subsequent groff release--will > get bad rendering in the opposite direction. This isn't a helpful comment, but my understanding of typography is poor enough that I still don't understand how spaces can participate in kerning in the first place. *roff doesn't have "space characters", and I don't think TeX does either. A glyph that has no glyphs adjacent should require no kerning at all--it's isolated. Dave's probably explained how I'm misinformed already, but I must not have understood his explanation because it didn't sink in. I also don't grasp how "kerning with spaces" applies to the problem observed (and kludged around) in commit 280724f9d. > I'll address the general problem next. With 1.24 fairly imminent, its > fix may not make it in there. But the bit of ugliness that commit > 280724f9d addressed was already in 1.23 (and perhaps much further back > than that), and we've lived with it this long. Reverting 280724f9d > would at least prevent a _new_ ugliness from creeping into future > releases. I don't see reversion of 280724f9d as having any urgency. I'm not deeply opposed, but given that I've churned the living hell out of groff's man pages relative to previous release on every occasion since 2017, I don't think the man pages make a stable platform for demonstrating defects or improvements in our microtypography. For that, I propose that we probably want a dedicated article--to coax Dave's involvement, I'd probably select me(7) for it--that illustrates relevant issues. People on the Web claim that _groff_ can't do microtypography at all, because we don't support OTF or TTF fonts, or because we're not Heirloom Doctools, or because we're not TeX, or because we're evil copyleftists who do nothing worthwhile. So _they_ wouldn't be convinced by such an article, but we might employ it to disseminate some facts and features that lunkheads like me can, with time, absorb. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67544> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
