[bug #64440] [docs] minor corrections and updates

Follow-up Comment #4, bug #64440 (project groff): [comment #3 comment #3:] > [comment #1 comment #1:] > > The excitement's not done here. The unit _is_ twelfths of an em after all! > > > > ...for _nroff_ mode devices. > > I confess I don't understand what distinction you're drawing here. "1/12

[bug #64440] [docs] minor corrections and updates

Update of bug #64440 (project groff): Status: Need Info => In Progress Assigned to:barx => gbranden ___ Reply to this item at:

[bug #64453] [grohtml] man+IP+UR with empty link text sends state machine into wilderness

URL: Summary: [grohtml] man+IP+UR with empty link text sends state machine into wilderness Group: GNU roff Submitter: gbranden Submitted: Fri 21 Jul 2023 09:37:30 AM UTC Categ

[bug #64454] [tbl] 'u' column modifier ("stagger") does not affect text block

URL: Summary: [tbl] 'u' column modifier ("stagger") does not affect text block Group: GNU roff Submitter: gbranden Submitted: Fri 21 Jul 2023 09:53:12 AM UTC Category: Preproc

[bug #64439] .chop does not treat a .char definition atomically(?)

Update of bug #64439 (project groff): Status:None => Need Info Assigned to:None => barx Summary: .chop does not treat a .char definition atomically => .chop does not treat a .ch

[bug #64455] [ms] want support for 4.2BSD `CT` and `TM` extensions

URL: Summary: [ms] want support for 4.2BSD `CT` and `TM` extensions Group: GNU roff Submitter: gbranden Submitted: Fri 21 Jul 2023 10:20:25 AM UTC Category: Macro ms

[bug #64421] [mom] the word "black" spuriously appears in output

Update of bug #64421 (project groff): Summary: [mom] the word "black" appears in output => [mom] the word "black" spuriously appears in output ___ Reply to this item at: _

[bug #64439] .chop does not treat a .char definition atomically(?)

Follow-up Comment #2, bug #64439 (project groff): Slightly reordering: [comment #1 comment #1:] > ...it seems clear to be that `chop` (and other string-processing > operations) should not be penetrating the boundary of the > character definition, and correctly treat it as a > character/glyph. I

[bug #64440] [docs] minor corrections and updates

Follow-up Comment #5, bug #64440 (project groff): [comment #4 comment #4:] Hm, your working copy changes: "Set the sizes of spaces... in twelfths of font's space width" to "Set the sizes of spaces... in twelfths of an em in @code{nroff} mode and 36ths of an em in @code{troff} mode." But the or

[bug #58450] additional inter-sentence spaces should be stretched in fully justified text

Follow-up Comment #2, bug #58450 (project groff): It turns out the behavior isn't limited to additional inter-sentence space. Consider: what would you expect the following to produce? echo 'x xx\p' | groff The quoted string contains 5 spaces: 1 between the first two x's, and 4 between the

[bug #59750] italic correction sometimes fails when the same glyphs are invoked with different input

Follow-up Comment #2, bug #59750 (project groff): The manual contains no example usage of the italic-correction escape (\/), so it's unclear whether it should canonically appear before or after the font-change escape. In practice it seems not to matter. _

[bug #64439] .chop cannot surmount the barrier of a .char definition

Update of bug #64439 (project groff): Status: Need Info => None Assigned to:barx => None Summary: .chop does not treat a .char definition atomically(?) => .chop cannot surmount t