[bug #63163] [me] long footnote gets truncated

Follow-up Comment #1, bug #63163 (project groff): Not that this case should fail, but that strikes me as an unusual way to use .(f and .)f. More typically, a document author will let -me place footnotes. The macro package tries to keep (at least the start of) a footnote on the same page as the t

[bug #58447] [me] footnote overflow can create infinite trap recursion

Follow-up Comment #9, bug #58447 (project groff): [comment #6 comment #6:] > there is different breakage when rendering the same document > with nroff--there's no infinite trap recursion, but the text > of the footnote is truncated and the document ends prematurely. Filed as bug #63163. ___

[bug #62860] [build] audit for inappropriate use of system groff resources

Follow-up Comment #5, bug #62860 (project groff): Here's the originally reported problem. gropdf:contrib/mom/examples/typesetting.mom: fatal error: failed to open '/usr/share/ghostscript/9.52/Resource/Font/C059-Roman' gropdf:src/utils/addftinfo/addftinfo.1: fatal error: failed to open '/usr/

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

Update of bug #62918 (project groff): Category: Font - others/general => Driver gropdf Status: Need Info => Duplicate Open/Closed:Open => Closed Planned Release:

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

Update of bug #62860 (project groff): Category: General => Driver gropdf Summary: [build] audit for inappropriate use of system groff resources => [gropdf] trying to access URW fonts from wrong directory __

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

URL: Summary: [me] After column-count changes, -me might place running text on page below footnote Project: GNU troff Submitter: barx Submitted: Fri 07 Oct 2022 04:17:48 AM CDT

[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly

Follow-up Comment #17, bug #62923 (project groff): Whilst you are correct the original submission matched the title, this was fixed in comment #1.All further comments then onwards are an entirely different issue which affects grops as well as gropdf. It seems odd to have an open ticket asigned to

[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly

Follow-up Comment #18, bug #62923 (project groff): [comment #17 comment #17:] > Whilst you are correct the original submission matched the title, this was fixed in comment #1. All further comments then onwards are an entirely different issue which affects grops as well as gropdf. It seems odd to

[bug #63179] sqrtex and radicalex are really weird glyphs, man

Follow-up Comment #1, bug #63179 (project groff): So the radical and square root extensions are overbars for...the next glyph to the right. WTF? (file #53812) ___ Additional Item Attachment: File name: radical_extension.png Size

[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly

Follow-up Comment #19, bug #62923 (project groff): Hi Deri, I opened bug #63179 and got a big surprise... ___ Reply to this item at: ___ Message sent v

[bug #63179] sqrtex and radicalex are really weird glyphs, man

URL: Summary: sqrtex and radicalex are really weird glyphs, man Project: GNU troff Submitter: gbranden Submitted: Fri 07 Oct 2022 12:17:16 PM UTC Category: Font - others/general

[bug #63179] sqrtex and radicalex are really weird glyphs, man

Follow-up Comment #2, bug #63179 (project groff): You should not be so surprised!! If you have a look at the file s.pdf attached to bug #62923, and my long comments in that bug you will see that I demonstrated the same thing. The equivalent glyph in font XITSMR does not behave this way, it is jus

[bug #62955] [PATCH] [grops] \(va fallback character overrides glyph available in S font

Follow-up Comment #7, bug #62955 (project groff): [comment #4 comment #4:] > In principle, one could argue that the trade mark sign and h-bar should be styled as the surrounding text is. I can't remember now where I read it, but apparently there is some precedent, _not_ in Unicode, for digital f

[bug #63028] document nroff \o limitations in modern terminal emulators

Follow-up Comment #2, bug #63028 (project groff): True and then some: unlike grotty, which outputs overstruck characters that terminals probably won't render, grohtml appears to output only the final character of an \o sequence. $ printf '\o"x+o"\n' | groff -Thtml | grep -o '.*' | od -c

[bug #24051] [mm] clean up refer support

Follow-up Comment #5, bug #24051 (project groff): [comment #4 comment #4:] > It's there, with the rest of mm, in contrib. Yes, yes it is. *facepalm* ___ Reply to this item at: __

[bug #61020] [me] centers pic(1) pictures, Heirloom doesn't

Follow-up Comment #2, bug #61020 (project groff): The Summary cites a difference in groff vs Heirloom pic handling, but comment #1 justifies the bug's closing based on Heirloom's lack of grn, a different preprocessor. Since both roffs include pic, if there's a difference in how they handle it, th

[bug #63142] [troff] deprecate newlines as escape argument delimiters

Follow-up Comment #3, bug #63142 (project groff): CSTR#54's section 5.2 makes the general observation "In \x'...' and other functions [sic] having a pair of delimiters around their parameter, the delimiter choice (here ') is arbitrary...", a nicely ambiguous term that could be interpreted as anyth

[bug #59738] mdoc: .Lk suppresses end-of-sentence recognition

Update of bug #59738 (project groff): Dependency Removed: => bugs #60571 ___ Reply to this item at: ___ Messag

[bug #62945] [www] detangle www.tmac from html device

Follow-up Comment #2, bug #62945 (project groff): Removing the autoloading of www.tmac for -Thtml runs also has a small back-compatibility concern: this autoloading has been documented since 2000's commit e092fba4 , when the man page

[bug #63179] sqrtex and radicalex are really weird glyphs, man

Follow-up Comment #3, bug #63179 (project groff): To comment 1: The radicalex is shifted to the right. Try current stable groff and check your version of 'gv' (I have 3.7.4) ___ Reply to this item at: