[bug #64624] [pic] doesn't restore fill color after writing output

Update of bug #64624 (project groff): Status: Confirmed => In Progress ___ Follow-up Comment #16: Looks like I should have set this ticket to "Need Info" status, but now that's obviated by Dave's

[bug #64624] [pic] doesn't restore fill color after writing output

Follow-up Comment #17, bug #64624 (project groff): Uh, according to Savannah's date stamps on these last few comments, I've just achieved time travel. Dave, I command you to respond to comment #13 within two hours! Muahahahaha...MOOOAHAHAHAHA! _

[bug #64624] [pic] doesn't restore fill color after writing output

Follow-up Comment #18, bug #64624 (project groff): Oh--don't mind me, I read right over the bizarre use of AM/PM with UTC. I've gotten really used to loggy/trackery stuff using a 24-hour clock. I haven't been drinking. Maybe I should start.

[bug #64628] [pic] generated `lf` requests no longer set file name

Update of bug #64628 (project groff): Status: Confirmed => In Progress ___ Follow-up Comment #4: Thanks, Bjarni--good catch. The backwards test of `strcmp`'s return value is indeed the culprit.

[bug #64624] [pic] doesn't restore fill color after writing output

Follow-up Comment #19, bug #64624 (project groff): [comment #16 comment #16:] > Looks like I should have set this ticket to "Need Info" status, You did. I set it back when I supplied the requested info (pending clearer instructions in response to the "semi-off topic" aside in bug #63332). [comm

[bug #64628] [pic] generated `lf` requests no longer set file name

Follow-up Comment #5, bug #64628 (project groff): Actually that wasn't quite enough. Those `&&`s need to be come `||`s as well. ___ Reply to this item at:

[bug #64628] [pic] generated `lf` requests no longer set file name

Follow-up Comment #6, bug #64628 (project groff): Yeah, no, this is actually thornier than I thought. Also, I was leaking memory from `strdup()`. So I'll fix that. ___ Reply to this item at: ___

[bug #64619] [mdoc] allow distros to maintain mdoc strings

Follow-up Comment #1, bug #64619 (project groff): One could certainly say there is community interest in this feature. https://reviews.freebsd.org/D41858 ___ Reply to this item at: __

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #2, bug #64592 (project groff): Hi Deri, Any thoughts on this issue, and my remarks in comment #1? ___ Reply to this item at: ___ Mes

[bug #64312] [mmroff] throws spurious Perl warnings if INITR/PIC used

Update of bug #64312 (project groff): Status:None => Fixed Assigned to:None => gbranden Open/Closed:Open => Closed Planned Release:

[bug #64624] [pic] doesn't restore fill color after writing output

Update of bug #64624 (project groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0

[bug #64628] [pic] generated `lf` requests no longer set file name

Update of bug #64628 (project groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #3, bug #64592 (project groff): Hi Branden, Just a few thoughts really, I agree the registers are behaving as currently documented, the question is whether the current behaviour makes sense. Groff currently has no concept of opacity, gropdf allows pdfs included by pdfpic to hav