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

Update of bug #64454 (project groff): Status: In Progress => Need Info ___ Follow-up Comment #9: Hi наб, I think the problem is more that I made a dumbass mistake and forgot to make the downward

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

Follow-up Comment #8, bug #64454 (project groff): I think this is because it may be folding differently for you – if I shorten it to end at "defined" it's also aligned properly for me. If I make it very long, it's /also/ at the right vertical height I naively want to say that this happens due to

[bug #63332] recent fallbacks.tmac change degrades ASCII output

Follow-up Comment #12, bug #63332 (project groff): [comment #2 comment #2:] > It is definitely a deviation from how Heirloom troff processes > the same input. (Functionally equivalent input, anyway: I munged the names of all the characters so they wouldn't collide with anything Heirloom might alr

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

Follow-up Comment #7, bug #64454 (project groff): Well, I should have known it wouldn't be that simple. :-| However, I can't _quite_ reproduce your results. For me, the entry starting "underling" is aligned with the two cells to its left. But, I'm running Git HEAD plus my working copy changes.

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

Follow-up Comment #6, bug #64454 (project groff): Okay, I re-ran this against my original table – base64, sorry: LlRTCmwyIGwyYiBsYgpsICBseCAgbHgKbHUgbHV4IGx1eApsdSBsdXggbHV4CmwgIGx4ICBseCAuCgl0aGVyZQloZXJlCj0KZGVhbGluZyB3aXRoIHBpcGVzCVR7CnNpemUgaXMgc29tZWhvdyB0aGUgc2l6ZSBvZiB0aGUgZGF0YSBpbiB0aGUgZ

[bug #64486] [troff] node.cpp: "if (*p == spec)" said to be ambiguous (C++20)

Update of bug #64486 (project groff): Status: Need Info => Invalid Assigned to:None => gbranden Open/Closed:Open => Closed

[bug #64486] [troff] node.cpp: "if (*p == spec)" said to be ambiguous (C++20)

Follow-up Comment #3, bug #64486 (project groff): I must have sent my answer with an e-mail, and not on the web site. This is my copy: Date: Sat, 29 Jul 2023 15:20:06 + From: Bjarni Ingi Gislason <...> To: "G. Branden Robinson" <...> Cc: bug-groff@gnu.org Subject: Re: [bug #64486] node.cpp:

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

Follow-up Comment #5, bug #64454 (project groff): Here's my updated version of the reproducer for real this time. $ cat EXPERIMENTS/tbl-staggered-text-blocks.roff .\" based on a test case from наб The capital letters should appear struck-through due to row staggering. .sp .TS tab(@); L L C

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

Follow-up Comment #4, bug #64454 (project groff): Here's my updated version of the reproducer. Because there's a different member function for each of the four column classifiers[1], I wanted to make sure all do. All seem to. Now the tricky bit is to decide how I want to write a regression test

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

Follow-up Comment #3, bug #64454 (project groff): Affects _groff_ 1.22.4 and 1.23.0. Probably goes back forever. ___ Reply to this item at: ___ Message

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

Follow-up Comment #2, bug #64454 (project groff): Applied to Debian 1.23.0-2, ./debian/build/tbl tblest | groff over the block below gets me what I wanted to do in Debian#1038391 (half-line spacing between the rows), and appears to work just as well when B is long. .TS l l l lu lu lu lu lu lu

[bug #62916] [hdtbl] consider deprecating

Follow-up Comment #4, bug #62916 (project groff): [comment #3 comment #3:] > besides hdtbl there are deprecation proposals in at least bug > #63142, bug #64337, bug #64353, and... bug #59425. and now bug #64515. ___ Reply to this item at:

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

Update of bug #64454 (project groff): Status: Confirmed => In Progress Assigned to:None => gbranden ___ Follow-up Comment #1: I believe I have a fi

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

Follow-up Comment #3, bug #58450 (project groff): Given the comment #2 input, Heirloom troff (and thus, probably, AT&T troff) behaves in the same manner in this regard as modern groff: echo 'x xx\p' | troff -x0 | dpost This behavior is not made clear in CSTR#54: An input text line ending wi

[bug #64466] [ms] poorly diagnosed diversion error

Follow-up Comment #1, bug #64466 (project groff): [comment #0 original submission:] > There was no follow-up on the list, and while the error text has improved a bit since 1.20.1, the second error is still not as helpful as the first, and it seems (says someone who has never looked at the ms code)

[bug #64469] [grops] -o with out-of-range number produces incomprehensible error

Update of bug #64469 (project groff): Summary: -o with out-of-range number produces incomprehensible error => [grops] -o with out-of-range number produces incomprehensible error ___ Reply to this item at:

[bug #64469] -o with out-of-range number produces incomprehensible error

Update of bug #64469 (project groff): Status:None => Confirmed ___ Follow-up Comment #1: Can reproduce with _groff_ 1.23.0 final. This might be a good time to adopt _neatroff_'s `.%` reg

[bug #64486] [troff] node.cpp: "if (*p == spec)" said to be ambiguous (C++20)

Follow-up Comment #2, bug #64486 (project groff): [comment #1 comment #1:] > Do you have `-std=c++98` in your CXXFLAGS when building, or not? Ping. I will close this as invalid if I don't get a response. ___ Reply to this item at:

[bug #64494] explain practical usage of 'm' and 'n' scaling units better

Update of bug #64494 (project groff): Status:None => Confirmed Assigned to:None => gbranden Summary: [PATCH] groff_mdoc(7): units 'm' and 'n' are named after the upper case letters

[bug #64501] grohtml(1): confusing sentence in "Bugs" section

Follow-up Comment #7, bug #64501 (project groff): [comment #6 comment #6:] > [comment #5 comment #5:] > > [comment #4 comment #4:] > > > the user might want lines in the HTML source broken in > > > reasonable places for easier handling in a text editor. > > > > But that's not the source form of

[bug #64501] grohtml(1): confusing sentence in "Bugs" section

Follow-up Comment #6, bug #64501 (project groff): [comment #5 comment #5:] > [comment #4 comment #4:] > > the user might want lines in the HTML source broken in > > reasonable places for easier handling in a text editor. > > But that's not the source form of the document, so why > would they both

[bug #64515] [man]: deprecate `SB` macro

Update of bug #64515 (project groff): Item Group: Feature change => Documentation ___ Follow-up Comment #1: Fix item group. This is not a feature change since formatting behavior will not change. The docu

[bug #64515] [man]: deprecate `SB` macro

URL: Summary: [man]: deprecate `SB` macro Group: GNU roff Submitter: gbranden Submitted: Fri 04 Aug 2023 01:17:48 PM UTC Category: Macro man Severity: 1 - Wish