Re: [Groff] Compliments----

the lift a compliment gives. -- Peter Schaffter ___ bug-groff mailing list bug-groff@gnu.org http://lists.gnu.org/mailman/listinfo/bug-groff

[bug #44903] mom 2 column output is misplaced

Update of bug #44903 (project groff): Status:None => Fixed ___ Reply to this item at: ___

[bug #44903] mom 2 column output is misplaced

Follow-up Comment #3, bug #44903 (project groff): I've been moving and didn't see this item till today. Yes, the bug is fixed. ___ Reply to this item at:

[bug #51608] [PATCH] om.tmac-u: Fix some mistakes, fix one bug

Follow-up Comment #2, bug #51608 (project groff): @@ -221,6 +221,9 @@ end .ds PDFHREF.TEXTCOL.DEFAULT 0.0 0.3 0.9 .nr PDFHREF.VIEW.LEADING.C 3i .nr PDFHREF.VIEW.LEADING.T 1i +.if !r PDFHREF.VIEW.LEADING \{\ +. nr PDFHREF.VIEW.LEADING 0 +.\} .nr PDFHREF.VIEW.LEADING.H

[bug #51608] [PATCH] om.tmac-u: Fix some mistakes, fix one bug

Update of bug #51608 (project groff): Status: Need Info => Fixed ___ Follow-up Comment #7: Thanks, Bjarni. I see what's causing the warnings. All the undefnined macro warnings except END

[bug #51608] [PATCH] om.tmac-u: Fix some mistakes, fix one bug

Follow-up Comment #4, bug #51608 (project groff): Which warnings are you seeing? Also, I'm not sure what you mean by "import the mom macros by hand." Can you attach a file and give the command line invocation you're using? ___ Reply to

[bug #52524] contrib/mom/examples: Some mom-files are encoded in UTF-8

Follow-up Comment #2, bug #52524 (project groff): Yes, typsetting.mom also requires -k. I'll fix that in README.txt. There are no reports that the absence of Coding Tags causes the files to process incorrectly, but in the spirit of crossing i's and dotting t's, I'll add them anyway. And you're

[bug #52524] contrib/mom/examples: Some mom-files are encoded in UTF-8

Follow-up Comment #4, bug #52524 (project groff): Correction to what I wrote: mom example files are, in fact, processed during the build. I responded too quickly last night and was thinking only of how the independent mom.tar.gz archives are set up.

[bug #54537] [PATCH] om.tmac: Add block brackets to avoid a warning about unbalanced .ie

Follow-up Comment #4, bug #54537 (project groff): Blocks are advantageous, no doubt, but at 23000+ lines, om.tmac benefits from the reduced clutter. In the present instance, I agree the braces help. With respect to patches to om.tmac, I prefer to inspect them myself before they're applied. I

[bug #54759] slide-demo.mom: Wrong kerning for "(°C"

Follow-up Comment #6, bug #54759 (project groff): All the patch does is re-introduce the problematic degree sign I just took out. We want a good example of tbl, not an example of a good table. The material could just as well be greeked for all its relevance to the purpose.

[bug #54759] slide-demo.mom: Wrong kerning for "(°C"

Follow-up Comment #10, bug #54759 (project groff): Deri -- 'fc-match Helvetica' on my system returns n019003l.pfb: "Nimbus Sans L" "Regular" as expected. Is this a distro-related issue? I'm presently running Kubuntu 16.04 LTS (Xenial) and this is the default. If your default is Liberation

[bug #54759] slide-demo.mom: Wrong kerning for "(°C"

Follow-up Comment #1, bug #54759 (project groff): Not seeing the problem. Unadjusted (°C looks terrible: far too much space after the left parens and the degree-sign crashes into the letter "C". Adjusted version corrects both errors. Have attached pngs demonstrating both as they appear at my

[bug #54759] slide-demo.mom: Wrong kerning for "(°C"

Update of bug #54759 (project groff): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #54759] slide-demo.mom: Wrong kerning for "(°C"

Follow-up Comment #4, bug #54759 (project groff): For the present issue, the simplest solution is to replace the table header with something that renders neatly without kerning. It is, after all, just an example. I'll take care of it and mark this bug closed. Since the matter of slight

[bug #57436] groff_mom.7.man: The term "exit multi-columns" is missing

Update of bug #57436 (project groff): Status:None => Fixed ___ Reply to this item at: ___

[bug #58933] [PATCH] doc/groff.texi, man/groff.7.man: clarify description of \

Follow-up Comment #3, bug #58933 (project groff): > It's Peter's term; I'm just a fanboy. I agree that "zero-width" seems redundant, but maybe he can think of something additional it communicates. It's the definition used by Ossana and Kernighan in the cstr54, not mine, though they switch it

[bug #59573] typesetting.mom: traps are not initialised (set, planted)

Follow-up Comment #2, bug #59573 (project groff): Until now, the exhibited behaviour of groff, if not the intended behaviour, was to ignore .ch requests for non-existent traps. The file typesetting.mom demonstrates bare-metal typesetting, so the FOOTER and FN_OVERFLOW traps, which are only used

[bug #59608] sample_docs.mom: error: an argument has a 'p' unit attached

Follow-up Comment #2, bug #59608 (project groff): > .DOC_COVER_TITLE_STYLE \ > SIZE +8 \ > SMALLCAPS \ > UNDERLINE 1 3p < line 86 This is correct. The first arg (weight) should not have a unit of measure attached; the second (distance from baseline) should. Using the latest om.tmac

[bug #59608] sample_docs.mom: error: an argument has a 'p' unit attached

Follow-up Comment #5, bug #59608 (project groff): 1) Mark significant trailing space as such, that is not just "...abc \" but "...abc \"significant trailing space Marking significant trailing space with just the slash-quote follows the recommendation made by Werner some years ago. With

[bug #60559] -mom macros should support pic's .PF

Update of bug #60559 (project groff): Open/Closed:Open => Closed ___ Follow-up Comment #2: Wow. Talk about something easy to miss. I have never noticed the scant mention of .PF in

[bug #60332] Document behaviour of soft hyphens in hyphenation mode 0

URL: Summary: Document behaviour of soft hyphens in hyphenation mode 0 Project: GNU troff Submitted by: PTPi Submitted on: Sat 03 Apr 2021 04:28:11 PM UTC Category: None

[bug #60332] Document behaviour of soft hyphens in hyphenation mode 0

Update of bug #60332 (project groff): Assigned to:None => gbranden ___ Reply to this item at: ___

[bug #61011] [mom] om.tmac: empty parentheses cause a warning

Update of bug #61011 (project groff): Status:None => In Progress ___ Follow-up Comment #1: The fix will be in the git repo when I upload the next full mom release, hence marking as In

[bug #61012] [mom] om.tmac: an empty argument to ".substring" produces a warning

Update of bug #61012 (project groff): Status:None => In Progress ___ Follow-up Comment #1: The fix will be in the git repo when I upload the next full mom release, hence marking as In

[bug #61013] [mom] slide-demo.mom: negative indent

Update of bug #61013 (project groff): Status:None => In Progress ___ Follow-up Comment #1: Several issues surrounding the warning: 1 - Missing parens around an argument to .in 2 - In

[bug #61004] [mom]: typo in "om.tmac"

Update of bug #61004 (project groff): Status:None => In Progress ___ Follow-up Comment #2: Dave, thanks for bringing this to my attention. I rarely check savannah for bug reports; 99%

[bug #61012] [mom] om.tmac: an empty argument to ".substring" produces a warning

Update of bug #61012 (project groff): Status: In Progress => Fixed ___ Reply to this item at: ___

[bug #61011] [mom] om.tmac: empty parentheses cause a warning

Update of bug #61011 (project groff): Status: In Progress => Fixed ___ Reply to this item at: ___

[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 #64639] [mom] odd output with #64421 reproducer

Follow-up Comment #3, bug #64639 (project groff): [comment #2 comment #2:] > The issue with the input in comment #1 appears to be that _mom_ assumes that a color named "default" exists (for me, it certainly defines a string _named_ `default` with the _contents_ `default`). cat

[bug #64639] [mom] odd output with #64421 reproducer

Follow-up Comment #5, bug #64639 (project groff): [comment #4 comment #4:] > Nevertheless Bjarni seems to have found a footgun. (Perhaps he has a big gun...or big feet.) > > Could we use more input validation in `DRH`? Not necessary, really. I preferred to use mom's COLOR macro in the

[bug #64561] [mom] using BOX inside QUOTE messes up inline CODE macro

Follow-up Comment #7, bug #64561 (project groff): I can reproduce the bug. It is definitely in mom. I'm looking into it. ___ Reply to this item at:

[bug #64561] [mom] using BOX inside QUOTE messes up inline CODE macro

Update of bug #64561 (project groff): Status:None => Fixed ___ Follow-up Comment #8: I've pushed a fix to the repo. Part of the problem was the unusualness of QUOTE coming right

[bug #64597] [mom] spurious newline after image label

Follow-up Comment #4, bug #64597 (project groff): >> I just took a look at the PDF_IMAGE source code in mom, but I >> think it would take me a week of intense meditation to make heads >> and tails of it. :) > > I haven't even dared to try. :D Can't say I blame you. The bug was introduced in

[bug #62996] [gropdf] mom-pdf: type size weirdness in text

Update of bug #62996 (project groff): Status:None => Fixed ___ Follow-up Comment #3: > At the bottom of page four the type size seems to get mysteriously smaller for no reason

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

Follow-up Comment #2, bug #63074 (project groff): [comment #0 original submission:] > I get warnings that "special characters are not defined" when using characters that are not defined in default fonts. I've managed to fix it by adding setting font family to _$FAMILY_ after changing an

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

Follow-up Comment #4, bug #63074 (project groff): [comment #3 comment #3:] > [comment #2 comment #2:] > > It's not entirely clear what you mean by "characters that are not defined in default fonts." > > Oh, I mistyped there. I meant that I get warnings when using Cyrillic characters (that are

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

Update of bug #63074 (project groff): Open/Closed:Open => Closed ___ Follow-up Comment #6: [comment #5 comment #5:] > I've tested my patch again and now it doesn't work to some reason

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

ine printers) and utf8 devices are for typewriting (see the file > > DESC in the directory "font/devutf8" (postpro grotty). See > > groff_mom(7) (and grotty(1)). > > I've never heard Peter Schaffter assert such a narrow horizon for his macro package, and if he indee

[bug #63593] [mom] spelling mistakes that "codespell" found

Follow-up Comment #2, bug #63593 (project groff): [comment #1 comment #1:] > Dropping severity and ssigning to Peter to deal with at his discretion. I'll take care of this once my system is back up and running. :) ___ Reply to this item

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Follow-up Comment #11, bug #63581 (project groff): [comment #10 comment #10:] > [comment #9 comment #9:] > I don't know how possible this would be (and I suspect maybe more a groff issue than relating to an individual macro?); but would an error exit code be possible as opposed to a terminal

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Follow-up Comment #13, bug #63581 (project groff): You're right about the manpage. I doubt many read it. Still, it should include mentioning the nroff "sort of incompatibility". As to sticking a .tm into om.tmac, it won't help in the case of the OP's terminal freeze, but it is the best

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Follow-up Comment #9, bug #63581 (project groff): [comment #8 comment #8:] > Although I appreciate I'm new here, I think the suggested text should be strengthened. Typically when something doesn't work (i.e. the terminal hangs) I assume the fault lies in code I have written. Resultingly I

[bug #63593] [mom] spelling mistakes that "codespell" found

Update of bug #63593 (project groff): Status:None => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Update of bug #63581 (project groff): Status: Confirmed => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Follow-up Comment #21, bug #63581 (project groff): When the PRINTSTYLE of sample-docs.mom is changed to TYPEWRITE, conformant with the note in the momdocs that mom is "designed for primarily for PDF or PostScript output, although with PRINTSTYLE TYPEWRITE she produces acceptable terminal copy",

[bug #64421] [mom] the word "black" appears in output

Follow-up Comment #3, bug #64421 (project groff): I can't reproduce this using the most recent om.tmac from the repo main branch, which doesn't surprise me because the bug was fixed prior to the official 1.23 release. Not sure what's going on. I've contacted the original bug filer and suggested

[bug #64421] [mom] the word "black" appears in output

Follow-up Comment #10, bug #64421 (project groff): Nothing yet. The om.tmac that ships with Arch's groff 1.23 isn't the culprit. We're going to have to wait on this to see if it crops up elsewhere. ___ Reply to this item at:

[bug #64421] [mom] the word "black" appears in output

Follow-up Comment #8, bug #64421 (project groff): Still can't find where this is coming from. The om.tmac that ships with groff 1.23 is 2-5_d, which elsewhere is not exhibiting the bug. I checked Debian's 1.23 package, in Sid, and it, too, doesn't have the bug. I can't imagine how this can be

[bug #60930] Integrate Peter Schaffter's font installer script into groff

Follow-up Comment #13, bug#60930 (group groff): [comment #12 comment #12:] > [comment #11 comment #11:] > > There's no copyright affixed to the script, but I can add one and > > slap on a GPL notice if that would help. Let me know. There'll > > probably have to be a copyright assignment to the

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

Follow-up Comment #13, bug#64592 (group groff): [comment #12 comment #12:] > If no one objects to my proposed change in comment #10, please set this ticket's status to "Confirmed" and I'll take care of it. > > Or someone else can. It's a one-liner! But I don't know what _mom_(7) will need to

[bug #60930] Integrate Peter Schaffter's font installer script into groff

Follow-up Comment #11, bug#60930 (group groff): [comment #10 comment #10:] > The potential downside depends on whether Peter wants to continue to maintain his script separately, which would make the groff git version a fork that will then not automatically pick up any changes Peter makes to his

[bug #60930] Integrate Peter Schaffter's font installer script into groff

Follow-up Comment #8, bug#60930 (group groff): [comment #6 comment #6:] > > * Write some test cases to ensure it works as expected > > It's possible Peter Schaffter, the script's developer, has some he's used privately and would be willing to share. Putting him on cc as well. So

[bug #64155] specifying -fZD on command line generates warnings

Follow-up Comment #24, bug #64155 (group groff): The restriction does conflict with mom's supplementary styles, however the conflict is not unique to mom. Any user-installed family may not have all of R/I/B/BI and, if a user gets creative with .sty, may not, in fact, have any of them. I have

[bug #60930] Integrate Peter Schaffter's font installer script into groff

Follow-up Comment #17, bug #60930 (group groff): [comment #16 comment #16:] > > Branden mentioned two more to-do items in the email cited in comment #5: > > * giving it a less name-space-stomperific name ("groff-font-install" or "groff-install-font" would be clear enough, but I think either would

[bug #60930] Integrate Peter Schaffter's font installer script into groff

Follow-up Comment #19, bug #60930 (group groff): How about just gfont? ___ Reply to this item at: ___ Message sent via Savannah

[bug #65198] mom/examples/*.txt: change '-k' to '-K utf8'

Update of bug #65198 (group groff): Status:None => Fixed ___ Follow-up Comment #6: [comment #4 comment #4:] > Comment #3 appears to misunderstand the point of comment #2: this