[bug #66980] fallbacks.tmac: refine U+2026 (horizontal ellipsis) fallback

URL: Summary: fallbacks.tmac: refine U+2026 (horizontal ellipsis) fallback Group: GNU roff Submitter: barx Submitted: Thu 03 Apr 2025 04:02:56 AM CDT Category: Macro package -

[bug #63354] [PATCH] [tmac]: refine fallbacks.tmac

Follow-up Comment #47, bug #63354 (group groff): [comment #45 comment #45:] > It is not clear yet how to handle items item 9 and 12, so I'm > deferring them. I'll write a separate comment addressing their issues. Item 9 in comment #28 concerns \[u2026], the ellipsis. The nearly 50 comments here

[bug #63354] [PATCH] [tmac]: refine fallbacks.tmac

Follow-up Comment #48, bug #63354 (group groff): [comment #30 comment #30:] > U+2008 PUNCTUATION SPACE is generally defined as a space > the width of a font's period or comma. In nroff mode, all characters are the same width. So the above suggests that for nroff, U+2008 should translate to an or

[bug #61958] [long-term] document all shipped tmac files somewhere

Update of bug #61958 (group groff): Summary: document all shipped tmac files somewhere => [long-term] document all shipped tmac files somewhere ___ Follow-up Comment #2: Annotating "In Progress" ticket with "[long-term]" t

[bug #66987] [PATCH] [troff] refactor to kill off `ESCAPE_NEWLINE`

URL: Summary: [PATCH] [troff] refactor to kill off `ESCAPE_NEWLINE` Group: GNU roff Submitter: gbranden Submitted: Fri 04 Apr 2025 01:16:59 AM UTC Category: Core

[bug #66980] fallbacks.tmac: refine U+2026 (horizontal ellipsis) fallback

Follow-up Comment #1, bug #66980 (group groff): > Therefore, whether and how to tweak the \[u2026] fallback, to improve devps > and devpdf output without degrading devdvi and devlbp output, is an open > question. We seem to have a fairly well-paved path for this sort of thing; take such fallback

[bug #65697] [long-term] add info to comment headers of font description files that groff tools generate

Update of bug #65697 (group groff): Summary: Add info to comment headers of font description files groff tools generate => [long-term] add info to comment headers of font description files that groff tools generate ___ Foll

[bug #60061] [long-term] narrow the scope of the groff Texinfo manual

Update of bug #60061 (group groff): Summary: narrow the scope of the groff Texinfo manual => [long-term] narrow the scope of the groff Texinfo manual ___ Follow-up Comment #15: Annotating "In Progress" ticket with "[long-t

[bug #66519] [long-term] migrate diagnostic messages "unable to" -> "cannot"

Update of bug #66519 (group groff): Summary: migrate diagnostic messages "unable to" -> "cannot" => [long-term] migrate diagnostic messages "unable to" -> "cannot" ___ Follow-up Comment #4: Annotating "In Progress" ticket

[bug #66518] [long-term] [libgroff] stop doing what gnulib can do for us

Update of bug #66518 (group groff): Summary: [libgroff] stop doing what gnulib can do for us => [long-term] [libgroff] stop doing what gnulib can do for us ___ Follow-up Comment #4: Annotating "In Progress" ticket with "[l

[bug #66981] [troff] use-after-free bug in file name reporting

URL: Summary: [troff] use-after-free bug in file name reporting Group: GNU roff Submitter: gbranden Submitted: Thu 03 Apr 2025 09:48:01 AM UTC Category: Core S

[bug #66981] [troff] use-after-free bug in file name reporting

Update of bug #66981 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 ___ Follow-up Comment #1:

[bug #66919] [troff] behavior change in some .hcode calls when a special character is the first argument

Follow-up Comment #29, bug #66919 (group groff): [comment #27 comment #27:] > [comment #26 comment #26:] >> Here's another clash of terminology we have. I assert that: >> >> .hcode \[~o] õ >> >> ...*is not a reflexive hyphenation code assignment*. > > This, I believe, is the clash at the root