[bug #61423] allow paths in "name" directive of font description file, restoring historical groff behavior

URL: Summary: allow paths in "name" directive of font description file, restoring historical groff behavior Project: GNU troff Submitted by: barx Submitted on: Wed 03 Nov 2021 11:48:31 PM CDT

[bug #61407] [mom] Remove default error messages from mom-files.

Update of bug #61407 (project groff): Status:None => In Progress Assigned to:None => deri ___ Follow-up Comment #5: [comment #4 comment

[bug #61417] [tbl] core dump when further spanning a first-row (invalid) downward span

Update of bug #61417 (project groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #1: Proposed patch.

[bug #61407] [mom] Remove default error messages from mom-files.

Follow-up Comment #4, bug #61407 (project groff): I believe the transparent node message occurs when pdf.tmac calls .asciify in order to "clean" the text to use in the bookmark text, and it includes nodes which can't be converted back text. Last time I looked this message could not be suppressed

[bug #61422] [ms] .DS means ".DS I" after all, contradicting forthcoming documentation

Follow-up Comment #2, bug #61422 (project groff): Sorry, bad regex. Same result. $ grep -r 'DS[[:space:]]*[.0-9]' . || echo nothing nothing ___ Reply to this item at:

[bug #61422] [ms] .DS means ".DS I" after all, contradicting forthcoming documentation

Follow-up Comment #1, bug #61422 (project groff): I would add that '.DS $indent' does not appear to be an established usage that is worth recognizing for the sake of rendering old AT troff documents with less effort. According to my grep of the Version 7 Unix Volume 2 manual sources (excluding

[bug #61422] [ms] .DS means ".DS I" after all, contradicting forthcoming documentation

URL: Summary: [ms] .DS means ".DS I" after all, contradicting forthcoming documentation Project: GNU troff Submitted by: gbranden Submitted on: Wed 03 Nov 2021 04:43:17 PM UTC

[bug #61407] [mom] Remove default error messages from mom-files.

Follow-up Comment #3, bug #61407 (project groff): "...can't transparently output node at top level" and "...can't translate character code nnn to special character 'c'in transparent throughput" (point 2) are spurious insofar as they have no impact on pdf output, nor the generation of pdf

[bug #58206] [PATCH] fix PDFPIC issue with determining size of pdfs containing images

Follow-up Comment #10, bug #58206 (project groff): Addressing bug #55107 will obviate the need for this particular shell pipeline at all (though tmac/pdfpic.tmac contains several other .sy calls which may still persist). But that's a more substantial change, and the patch proposed in comment #4

[bug #61324] tmac/pdfpic.tmac: make shell pipeline called via .sy more robust

Update of bug #61324 (project groff): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: Turns out bug #58206

[bug #61407] [mom] Remove default error messages from mom-files.

Follow-up Comment #2, bug #61407 (project groff): Are the errors being reported in point 2) legitimate errors? If so, their root causes should be fixed. If not, perhaps the code generating them should be changed to not emit spurious error messages. Suppressing stderr seems like the least