[bug #64624] [grotty] some pic actions make following text illegible

URL: Summary: [grotty] some pic actions make following text illegible Group: GNU roff Submitter: barx Submitted: Tue 05 Sep 2023 07:35:32 AM CDT Category: Driver grotty

[bug #61455] [PATCH] doc/pic.ms: Avoid a yellow background for text when the device uses "tty.tmac"

Follow-up Comment #4, bug #61455 (project groff): The attached patch still applies, and seems to solve the problem Bjarni identified. [comment #3 comment #3:] > I think for now the thing to do is ensure that the fill color > escape sequence is being used idiomatically. It turns out that one of t

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

Follow-up Comment #22, bug #64421 (project groff): I rebuilt the Arch Linux groff package at version 1.23.0-3 from source and that resolved the issue. - The "black" label does not show up with that compiled version. The precompiled package for the exact same package version still has the bug thou

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

Update of bug #64421 (project groff): Status:None => Need Info ___ Follow-up Comment #23: Hi Günter, Thank you very much for following up. [comment #22 comment #22:] > I rebuilt the Arc

[bug #64624] [grotty] some pic actions make following text illegible

Follow-up Comment #1, bug #64624 (project groff): Try "groff -Tlatin1 -mtty-char -Z test.pic" and compare the output with the attached file, which is my Z-file. Test "grotty ". (file #55113) ___ Additional Item Attachment: File name

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

Follow-up Comment #8, bug #64576 (project groff): > Incidentally, and to motivate my frustration with the `pdfhref` approach, the following works terribly. The hotspots don't know where to end, going nuts and electrifying everything after them even without a page break to screw them up by not ca

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

Follow-up Comment #24, bug #64421 (project groff): Hello! With the help from the package maintainer Tobias Powalowski, I was able to reproduce the broken build locally. When I build with the `makepkg` tool, the resulting binary *does not* have the bug. When I build with the "reproducible build"

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

Follow-up Comment #25, bug #64421 (project groff): Ah I ran into the upload size limit - I uploaded the file to https://blog.gnoack.org/good-and-bad-groff.tar ___ Reply to this item at: _

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

Follow-up Comment #26, bug #64421 (project groff): OK I found an option in /etc/makepkg.conf which lets me control link time optimization. *When turning on that LTO flag, the bug appears* -- so it *is* the -flto=auto flag which makes the issue appear. *I updated the good-and-bad-groff.tar file*

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

Follow-up Comment #27, bug #64421 (project groff): Thanks, Gunther. Thanks for the uploads. These are full installation trees of the groff builds, which may end up coming in handy. My comparative disassembly idea swiftly hit the rocks. Even with that slight change of compiler options, adding

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

Follow-up Comment #28, bug #64421 (project groff): Let me try that quoted disassembly again, since I didn't indicate which was which, and screwed up the verbatim tags. $ diff -u goodtroff.objump badtroff.objump | cat -n 167739 Disassembly of section .text: 167740 167741 00034020 <

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

Follow-up Comment #29, bug #64421 (project groff): Whoops. I didn't see your comment #26 before writing comments #27 and #28. Looks like we had similar ideas. I'll try to absorb comment #26 now. ___ Reply to this item at:

[bug #64624] [grotty] some pic actions make following text illegible

Follow-up Comment #2, bug #64624 (project groff): [comment #1 comment #1:] > Try "groff -Tlatin1 -mtty-char -Z test.pic" and compare the output > with the attached file, which is my Z-file. I needed to add the "-p" option to your command line to get meaningful results. (For this test file, the t

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

Update of bug #64421 (project groff): Status: Need Info => Confirmed ___ Follow-up Comment #30: Reproduced! `-flto=auto` is a poison pill, even on my system with a significantly older toolchai

[bug #64624] [grotty] some pic actions make following text illegible

Follow-up Comment #3, bug #64624 (project groff): I used "test-nroff" (uses "test-groff" instead of "groff" in "nroff") which does not provide the file name. Using "naked" diff does not provide the surroundings to pinpoint the place where the difference occurs. So you have an extra line wi

[bug #63354] Refine fallbacks.tmac

Follow-up Comment #30, bug #63354 (project groff): To help support mission creep, I'm adding one item to the comment #28 to-do list. 13. \[u2008]: refine for accuracy U+2008 PUNCTUATION SPACE is generally defined as a space the width of a font's period or comma. Currently fallbacks.tmac aliases

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

Follow-up Comment #31, bug #64421 (project groff): Hi Peter, I instrumented _mom_ with the following diff. diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac index b0fd1ef55..2a34ba0f2 100644 --- a/contrib/mom/om.tmac +++ b/contrib/mom/om.tmac @@ -1871,11 +1871,13 @@ end \# as a macro.

[bug #64421] [troff] link-time optimization changes `.m` register initialization

Update of bug #64421 (project groff): Summary: [mom] the word "black" spuriously appears in output => [troff] link-time optimization changes `.m` register initialization ___ Follow-up Comment #32: Oddly enough this bug see

[bug #64421] [troff] link-time optimization changes `.m` register initialization

Follow-up Comment #33, bug #64421 (project groff): Link-time optimization is doing something clever that I don't understand. The problem, not surprisingly, is the reading of an uninitialized variable. Our problematic friend is an object named `default_color`. It belongs to the `color` class. h