[bug #64597] [mom] spurious newline after image label

Follow-up Comment #6, bug #64597 (project groff): Hey Peter, I tried to look at this myself during the last day. I was in way over my head, _but_ I found this sentence in the gnu troff reference manual [1] under "interpolating registers" along the way: > If the register is undefined, it is creat

[bug #64597] [mom] spurious newline after image label

Follow-up Comment #7, bug #64597 (project groff): Hi Sven, The difference here, perhaps a subtle one, is that the 'r' conditional operator doesn't *interpolate* a register. I have the following change pending in my Git working copy. commit b99fa24b508c8ca20356bde37de686986965177f Author: G. Br

[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

Follow-up Comment #7, bug #64576 (project groff): Apologies, the t.pdf file had a problem. It worked fine with okular and evince, but some other viewers did not make the links clickable. I have fixed the issue and t-new.pdf should be working with all viewers. (file #55090) __

[bug #64602] [troff] `fl` request behavior difficult to rationalize

URL: Summary: [troff] `fl` request behavior difficult to rationalize Group: GNU roff Submitter: gbranden Submitted: Sun 27 Aug 2023 08:05:01 PM UTC Category: Core

[bug #64602] [troff] `fl` request behavior difficult to rationalize

Follow-up Comment #1, bug #64602 (project groff): The only output I see in the ps-file is "foobar". How is the code supposed to alter the output? Comments to explain the code are missing. ___ Reply to this item at:

[bug #64597] [mom] spurious newline after image label

Follow-up Comment #8, bug #64597 (project groff): [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=11016d37 Commit 11016d37] (pushed to the repo) fixed the originally reported bug. The commit cited in comment #7 (not yet pushed) seeks to make it less likely such bugs will arise. _

[bug #64484] [troff] .device and \X don't behave the same

Follow-up Comment #4, bug #64484 (project groff): [comment #2 comment #2:] > I don't know whether the pdfmark macros rely on the asciifying > behaviour of \X or not. While pdfmark is now maintained externally, Keith should still be able to post to savannah bugs, so I'm cc:ing him for his input on

[bug #63360] kern U+2011 (nonbreaking hyphen) the same as U+2010 (hyphen)

Follow-up Comment #2, bug #63360 (project groff): [comment #0 original submission:] > \[u2011] was (ultimately) defined in [http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/fallbacks.tmac tmac/fallbacks.tmac]. > Bug #63354 suggests some tweaks to that file. One of those tweaks, ultimately app