[bug #58736] [me] footnote breaks two-column output

Follow-up Comment #40, bug #58736 (project groff): [comment #39 comment #39:] > This does seem to be working now, but in testing I've stumbled > into other -me footnote issues Heh, and by "other" issues, I mean rediscovering the issue as presented in this bug's original submission. The new bug

[bug #63176] [me] After column-count changes, -me might place running text on page below footnote

Follow-up Comment #5, bug #63176 (project groff): [comment #4 comment #4:] > This seems tricky enough that I'm inclined to simply add > another diagnostic message: if there are pending footnotes > when the number of columns is changes, yell about it. There already _is_ an error message, but--as

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #19, bug #62860 (project groff): [comment #18 comment #18:] > Please could you attach the file /usr/local/share/groff/site-fonts/download. I already did; see file #53823 ___ Reply to this item at:

[bug #58930] take baby steps toward Unicode

Follow-up Comment #23, bug #58930 (project groff): A few nits about specific definitions: [comment #21 comment #21:] > +.fchar \[u2000] \h'1n' \" en quad > +.fchar \[u2001] \h'1m' \" em quad > +.fchar \[u2002] \h'1n' \" en space > +.fchar \[u2003] \h'1m' \" em space As the "quad" and "space"

[bug #62983] [troff] want diagnostic if '\o' encountered while formatting for non-overstriking device

Follow-up Comment #5, bug #62983 (project groff): [comment #1 comment #1:] > "grotty can't overstrike" doesn't appear to be an accurate characterization. As Branden notes in bug #63028, it _is_ an accurate characterization of grohtml, so producing a warning there would seem uncontroversial.

[bug #58930] take baby steps toward Unicode

Follow-up Comment #22, bug #58930 (project groff): * The expanded Unicode coverage is great! * fallbacks.tmac does seem like a better place for these definitions. * I'm interested in your thoughts on the trade-off presented in comment #11, because it has bearing on some of your other proposed

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #18, bug #62860 (project groff): Please could you attach the file /usr/local/share/groff/site-fonts/download. ___ Reply to this item at:

[bug #63214] [eqn] reads from uninitialized memory when reporting file name in diagnostics

URL: Summary: [eqn] reads from uninitialized memory when reporting file name in diagnostics Project: GNU troff Submitter: gbranden Submitted: Fri 14 Oct 2022 06:37:15 PM UTC

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #17, bug #62860 (project groff): > Please check your copy of download in the site-font directory to see if it contains the stale paths. All of the paths referenced by `font/devpdf/download` point to font files. Also, concerning environment variables: the directory referenced

[bug #63176] [me] After column-count changes, -me might place running text on page below footnote

Update of bug #63176 (project groff): Status: Confirmed => Need Info ___ Follow-up Comment #4: Hi Dave, This seems tricky enough that I'm inclined to simply add another diagnostic message: if