[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #7, bug #66323 (group groff): [comment #2 comment #2:] > Forgot to mention, the problem ultimately could very well lie in the formatter, or even in _grops_, but it would be helpful to me if we could narrow down what snipped of mom the formatter is handling badly, or what sequenc

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #5, bug #66323 (group groff): The pipeline is well-considered (and, AFAIR, one of the ones the -mom manual blesses). Maybe I'll reconsider it when -Tpdf learns to lay out text as well as -Tps | ps2pdf can (and when I figure out how to make it read the fonts I need), but that's ne

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #6, bug #66323 (group groff): [comment #4 comment #4:] > The author of the pdfmark macro and pdfroff no longer contributes to groff Bug #63827 discusses their removal from groff. ___ Reply to this item at:

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #4, bug #66323 (group groff): Using -T ps with pdfmom results in a call to pdfroff with the extra parameters "-mom -mpdfmark --no-toc". This can be verified by running:- pdfroff -Tps -mom -mpdfmark -Kutf8 bad.mom > bad.pdf And receive the same results. The author of the pdfmark

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #3, bug #66323 (group groff): Also, pdfmom may not be crashing so much as politely passing along the rudeness that killed a program in the pipeline it runs. And that's good thing, because [https://git.savannah.gnu.org/cgit/groff.git/commit/?id=b62f0605427caa156f23c81280f345496dd

[bug #66322] [mom]: groff HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Update of bug #66322 (group groff): Assigned to:None => PTPi Summary: groff HEAD mom doesn't have any bottom margins(?) and doesn't output page numbers anymore => [mom]: groff HEAD doesn't have any bottom margins(?) and doesn't o

[bug #65894] [troff] certain man(7) input leads MTSM into deranged state, mismanaging memory

Follow-up Comment #4, bug #65894 (group groff): Also observed downstream in [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082520 Debian #1082520]. ___ Reply to this item at:

[bug #66323] groff HEAD mom produces invalid postscript (that also crashes pdfmom)

URL: Summary: groff HEAD mom produces invalid postscript (that also crashes pdfmom) Group: GNU roff Submitter: None Submitted: Fri 11 Oct 2024 01:49:25 PM UTC Category: Macro

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Update of bug #66323 (group groff): Assigned to:None => PTPi Summary: groff HEAD mom produces invalid postscript (that also crashes pdfmom) => [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

[bug #66323] [mom]: groff HEAD produces invalid postscript (that also crashes pdfmom)

Follow-up Comment #2, bug #66323 (group groff): Forgot to mention, the problem ultimately could very well lie in the formatter, or even in _grops_, but it would be helpful to me if we could narrow down what snipped of mom the formatter is handling badly, or what sequence of nodes in the output lis

[bug #66322] groff HEAD mom doesn't have any bottom margins(?) and doesn't output page numbers anymore

URL: Summary: groff HEAD mom doesn't have any bottom margins(?) and doesn't output page numbers anymore Group: GNU roff Submitter: None Submitted: Fri 11 Oct 2024 01:45:02 PM UTC

[bug #66322] [mom]: groff HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #2, bug #66322 (group groff): It's a bug in DRV. All the graphical objects macros, in fact. The fix will be in my next commit, probably in the next couple of days. ___ Reply to this item at: