Re: [Groff] Compliments----

[Peter Schaffter]

On Thu, Jul 05, 2007, John Rupley wrote:
 May I complement you and your colleagues and thank you all for the  
 GNU troff suite.  It is obviously excellently done.

Thanks, John, for taking the time to make your appreciation known.  I
can't speak for others on the list, but I always welcome 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

[Peter Schaffter]

Update of bug #44903 (project groff):

  Status:None => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

[bug #44903] mom 2 column output is misplaced

[Peter Schaffter]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 \n[PDFHREF.VIEW.LEADING] 
\# 
\# ==
 
_That seems like it's asking for trouble; if anything ever dereferences the
PDFHREF.VIEW.LEADING or PDHREF.VIEW.LEADING.H registers before redefining
them, and if they do what their names suggest, the resulting text will be "set
solid" with no interline spacing. Won't it?_

PDFHREF.VIEW.LEADING controls the distance from the top of the PDF viewer
window to the baseline of link targets.  It has no effect on the formatting of
the .pdf file itself.  The register is set in pdf.tmac; the default is 5
points (5000u).  There's no need for


.if !r PDFHREF.VIEW.LEADING


There's no need to define the "undefined" macros/registers either since, after
loading pdf.tmac and om.tmac, they are, in fact, defined.  The assumption that
pdf.tmac (Deri's re-write of Keith's pdfmark.tmac) is loaded is correct since
pdf.tmac is loaded from troffrc when groff is called with -Tpdf.

The error "can't transparently output node at top level" may safely be
ignored, which is documented.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 and BREAK_QUOTE are the result of
aliases preceding the definition of the macros being aliased.

END is not a macro, but rather a macro closure argument (second argument to
MAC, which is an alias of .de) used throughout.  groff shouldn't be treating
it as an undefined macro.  Since it is, defining it as a blank macro is the
only way to remove the warning.

BREAK_QUOTE is not used any more.

The undefined register #EN_Q_AUTOLEAD is the result of a missing backslash.

Rather than apply your patch, I've moved alias definitions to their correct
locations, removed the aliases of BREAK_QUOTE, fixed the missing backslash,
and defined END near the top of the file.  I'll push the changes later today
(2017-11-03) and mark this bug Fixed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 right, the files are installed without processing.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 develop mom actively, with fairly frequent releases. 
Changes in the repo can mess up my commits.

When submitting proposed patches, make sure they're against the latest version
of om.tmac. The om.tmac in a packaged groff, the one installed from a former
build, and the official release in the repo are always out of sync, a side
effect of developing mom separately from groff, so to speak.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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.  
 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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
Sans, then the decision is being made upstream.

I propose moving this discussion to the mailing list since it isn't a groff or
mom bug but does affect their users.  The degree sign issue in slides-demo has
been dealt with.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 end.

(file #45522, file #45523)
___

Additional Item Attachment:

File name: not-adjusted.png   Size:3 KB
File name: adjusted.png   Size:3 KB


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

Update of bug #54759 (project groff):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

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 differences in font rendering across pdf viewers
has come up before, I'm wondering if we should make a note of it somewhere
that recommends the -P-e solution. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

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

[Peter Schaffter]

Update of bug #57436 (project groff):

  Status:None => Fixed  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 around.  I'm inclined to think zero-width is not
redundant, since a non-printing character could have a width.  Zero-width,
non-printing clarifies this.  I'd rather risk overstating than leaving room
for doubt. I suspect that was O's reasoning, too. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 if START has been invoked (full document processing), are
never set.  This has allowed PDF_IMAGE conveniently to process all pdf images
inside the FLOAT mechanism, which necessarily .ch's the aforementioned traps
if they exist and does nothing if they do not, as is the case with
typesetting.mom.

It is simple enough to amend the PDF_IMAGE macro to invoke FLOAT only if START
has been invoked, thus eliminating the .ch operations on non-existent traps,
but before I do, I'd like to know the rationale behind the change to what,
from my perspective as a macro developer, breaks established groff behaviour.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 from the repo and my most recent groff build
(1.22.4.7-72b4), there is no error.  What's more, the error clearly refers to
the second arg, but RULE_WEIGHT only takes one arg.  Whatever the problem is,
I can't see how it's coming from om.tmac.

Altering the RULE_WEIGHT error msg to say the it comes from RULE_WEIGHT might
be useful for developer debugging, but would be useless to a user, who needs
only know the name and location of the calling macro since that is where any
invalid argument would have been entered.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 nothing after it, it
already means "the foregoing space is significant."  Adding the comment
afterwards would be tautological.

Not sure what you mean by "2) Show all arguments in a diagnostic message."  Do
you mean every argument that was passed to the macro?  What would be the
advantage?  A user needs only know the offending calling macro, its position
in the file, which arg is bad ("first," "second"... or "arg to https://savannah.gnu.org/bugs/?59608>

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 pic.ps.

Kernighan's "flyback" is incompatible with mom's handling of pic diagrams,
which are managed as floats ("keeps" in ms-speak), so it won't be supported by
the mom macroset.  At most, I can add a note to the mom docs telling users not
to use it. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

In hyphenation mode 0, soft hyphens get interpreted. Since this long-standing
behaviour is counter-intuitive, it needs to be documented in the info manual.










___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #60332 (project groff):

 Assigned to:None => gbranden   


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 Progress.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 Progress.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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 slide-demo.mom, .PS should have been given the LEFT
arg because the pic is in a left-quadded tab.  (Good thing it wasn't or the
negative indent warning might not have been spotted.)
3 - In the docs, the LEFT arg isn't listed in the args to PS.
4 - The tabs look better with their headings centred, so I've changed them.

All this will be fixed and reflected in the next full release of mom.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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% come to me directly from users.  I'm currently working on
adding Deri's PDF boxes to the mom macros and preparing a 2.5 version release.
 For now, I'm lumping all bug fixes into that release, which I hope to have
completed by the end of August 2021, so I'm marking this as "In Progress".

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #61012 (project groff):

  Status: In Progress => Fixed  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #61011 (project groff):

  Status: In Progress => Fixed  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61407] [mom] Remove default error messages from mom-files.

[Peter Schaffter]

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 outlines.  The warnings are emitted by troff when the gropdf
driver is being used.  So far, no one has come up with a solution to getting
rid of them.  I suspect it isn't possible except by suppressing stderr, which
is no solution at all.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Peter Schaffter]

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  What puzzles me more is the `COLOR` macro itself.
> 
> The following patch seems to make it do what it is documented to do.

> diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
> index b0fd1ef55..039bcfe48 100644
> --- a/contrib/mom/om.tmac
> +++ b/contrib/mom/om.tmac
> @@ -1873,9 +1873,9 @@ end
>  .MAC COLOR END
>  .ie \\n[.u]=1 \{\
>  \c
> -\\*[\\$1]\c
> +\m[\\*[\\$1]]\c
>  .\}
> -.el \\*[\\$1]
> +.el \m[\\*[\\$1]]
>  .END
>  \#
>  \# NEWCOLOR

Colours in mom have to be "initialized" with NEWCOLOR or XCOLOR.  Either of
these creates a string of the form "\m[color]" allowing the user to change
colour with the string "\*[color]".  Because "\\*[\\$1]" expands to
"\m[color]" (arg1 is a pre-initialize color name), the patch expands to
"\m[\m[color]]", which is incorrect.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 graphical
objects macro, but it's not essential.  This patch to DRH should clear up any
concerns Bjarni envisages.  The same change will be applied to the remaining
graphical object macros if it passes muster.

--- om.tmac.working.copy.bak02  2023-09-08 21:01:23.606662237 -0400
+++ om.tmac 2023-09-11 13:58:17.269063693 -0400
@@ -1934,7 +1934,6 @@
 .ds BLACK   \m[black]
 .ds white   \m[white]
 .ds WHITE   \m[white]
-.ds default black
 \#
 \# =
 \#
@@ -2844,17 +2843,12 @@
 .ds $RL_WEIGHT \\$1
 .ds $RL_INDENT \\$2
 .ds $RL_LENGTH \\$3
-.ie !'\\$4'' .ds $RL_COLOR  \\$4
-.el \{\
-.   ie '\\n[.m]'' .ds $RL_COLOR \\*[default]
-.   el .ds $RL_COLOR \\n[.m]
-.\}
 .nr #SAVED_WEIGHT \\n[#RULE_WEIGHT]
 .nr #SAVED_WEIGHT_ADJ \\n[#RULE_WEIGHT_ADJ]
 .di NULL
 .   if \\n[#NUM_ARGS]>=1 .RULE_WEIGHT \\*[$RL_WEIGHT]
 .di
-.COLOR \\*[$RL_COLOR]
+.if !'\\$4'' .gcolor \\$4
 .ie \\n[#NUM_ARGS]=0 \{\
 .   ie \\n[#INDENT_ACTIVE] \{\
 .  nr #RESTORE_L_LENGTH \\n[.l]
@@ -2899,7 +2893,7 @@
 .   if \\n[#NOFILL_MODE]=3 .CENTER
 .   if \\n[#NOFILL_MODE]=5 .RIGHT
 .\}
-.gcolor
+.gcolor default
 .nr #RULE_WEIGHT \\n[#SAVED_WEIGHT]
 .nr #RULE_WEIGHT_ADJ \\n[#SAVED_WEIGHT_ADJ]
 .rr #SAVED_WEIGHT


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 after START with no intervening PP.

Marking as Fixed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 2.5, when shaded backgrounds
and frames were added.  I used '.if \n[pdfbx-running]' to test for the
presence of a shaded background/frame in PDF_IMAGE, which initialized the
register so that later, when
'.if r pdfbx-running' was called, it returned true even though the nominal
value was zero. 

I've pushed the fix and updated the tarball on the mom website.

This isn't the first time I've been bitten by the slight difference between
'.if \n[foo]' and '.if r foo' when 'foo' does not exist.  Both return 'false'
but the first initializes the register where the second does not.  I looked in
the info docs for mention of this but can't find it.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 obvious to me.

Two bugs: in the CODE macro, the accidental use of a register that should have
been a string; in mom-pdf.mom, a missing parameter to the \*[SIZE] inline
macro.  Both fixed.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 environment in the
pdfmomclean macro (see the attached patch).

It's not entirely clear what you mean by "characters that are not defined in
default fonts."  Please attach a sample input file demonstrating the problem.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 not defined in default fonts).
> 
> I've attached a sample file. Note that the _TM_ font is an installed font
that contains Cyrillic symbols.

Without the TM font, I can't check what's going on.

Processing your sample file with the U-TR font in font/devpdf spits out a few
"can't find special character" warnings, but the text renders correctly, as
nearly as I can tell.  The missing special characters are the title, and where
they're missing from is the pdf outline (not the text), which presently does
not accept Cyrillic.

When I process the file with your patch applied, it produces the same result
(missing characters) but adds several more of the unavoidable "can't
transparently output node at top level" warnings.

Can you provide copies of your TM fonts (roman and bold) so I can see if the
results differ from my tests with U-TR?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 (the
warnings are still printed). I don't understand the internals of MOM well
enough to figure out what's wrong, so I think it would be better if you come
up with your solution.
> 
> I get the same behavior with my fonts as you get with yours: the text is
rendered correctly but some warnings are still printed (which seems to happen
because of the PDF outline, indeed). So I believe that using different fonts
doesn't affect anything.

The problem is with groff itself, not mom, so I can't be of further help.  The
same issue came up just a few days ago and the groff developers are aware of
it.  From discussions on the list, it won't be addressed until after the next
groff release.

If you don't need a pdf outline, you can safely ignore the warnings.

Marking this item as Closed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Follow-up Comment #7, bug #63581 (project groff):

Sorry for the delay in getting to this.  A recent upgrade to Ubuntu 22.04
proved catastrophic and I can't boot into my system.  Still working on it.

> >   The 'mom' package is for typesetting, not for typewriting (terminals
> > and line 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 indeed wants to foreclose its use on terminal devices, this
is really easily done.
> 
> .if n .ab sorry, mom doesn't support terminals

> I'd prefer to hear from him directly on this question.

Bjarni got it right.  The mom macros are meant for PDF or PostScript output. 
Snippet from mom's documentation:

"Mom does not try to be all things to all people. In contrast to the normal
groff philosophy, she does not try to produce output that looks good no matter
where it’s displayed. She’s designed for primarily for PDF or PostScript
output, although with PRINTSTYLE TYPEWRITE she produces acceptable terminal
copy. No attempt is made to be compatible with older versions of troff."

Aborting on .if n seems too restrictive.  Perhaps just updating the
groff_mom(7) Description to read: "mom is a macro set for groff, designed
primarily to prepare documents for PDF and PostScript output.  mom is not
intended for formatting documents displayed at the terminal."


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63581>

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 freeze in cases where it doesn't render? 
This would certainly be desirable from my perspective.  I'm guessing this
would be difficult though or it would already have been done?

AFAIK, there's no way to plant a groff exit code inside a macro.  At most,
groff can be told to abort on testable conditions prior to the execution of
subsequent requests.  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 solution.  (Perhaps if he'd seen the warning in conjunction with
nroff-ed docs that worked, he wouldn't have been surprised to encounter a
problem.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 spent hours
investigating this prior to posting in this forum (obvs including reading the
relevant man files).  To say that something is "not intended for" is different
to saying we know this will break something.  If we know it causes an issue
that should be stated up front, rather than obliquely - e.g. "... and may
cause the terminal to become unresponsive".  Knowing this would save time for
everyone.

The addition of your "...and may..." will help.  The issue is this: some mom
documents can be rendered at the terminal and some can't.  We need to steer
users away from nroff--support for it has never been in mom's mandate--while
not saying "Don't ever use it."  Telling users it might freeze their terminal
is a polite way of saying "Use at your own risk," which is an accurate
assesment.

I'll await further comments before changing the manpage and closing this bug. 



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #63593 (project groff):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #63581 (project groff):

  Status:   Confirmed => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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", 'nroff -mom' or 'groff -Tutf8' render the document
successfully, if somewhat inelegantly, at the terminal.

I'm thinking that the best way of dealing with this, rather than putting a
caveat in groff_mom(7), is to abort at PRINTSTYLE if nroff is called on a
PRINTSTYLE TYPESET document.  The abort message will tell the user to switch
to PRINTSTYLE TYPEWRITE.

If no one has objections, the change will go into my next commit and I'll
close this bug at that time.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 downloading the standalone mom package.  I hesitate to
mark this as closed until we can figure out why Arch Linux's 1.23 groff has a
buggy om.tmac


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 an Arch issue, but I've asked the filer to send me a copy of the
om.tmac that ships with Arch's groff 1.23 anyway.  Perhaps I'll see something
there.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 Free Software
> > Foundation as well.  I don't keep up with the legalities, I'm afraid.
> 
> Nor I; someone more conversant with licensing will have to address this.  I
only brought it up as part of a list of potential obstacles I could see to
getting it into the package.

I've put a copyright notice (2024--I can't remember when I wrote the damned
thing) and GPL licence on the script and uploaded it to
https://www.schaffter.ca/mom/bin/install-font.sh

Whoever wants to can grab it from there.  I believe Bertrand, as groff
maintainer, has to initiate the copyright assignment process.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 do.

Nothing.  Starting with the 2.6 release, mom explicitly calls '.gcolor
default' whenever a color argument is not given to macros that optionally take
one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 copy. 
But he may be willing to make the git code the authoritative version, and
simply mirror that on his site (until, presumably, it's part of an official
groff release).

I'd be happy to have someone else maintain the script, so yes, pillage and
plunder, add it to groff and make that version authoritative.
 
> I also don't know what license covers the script (neither the page that
hosts the script (linked in comment #0), nor the source code itself, mentions
one), but my presumption is that it would be licensed the same as -mom
herself, which is GPLed.

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 Free Software Foundation as well.  I don't keep up
with the legalities, I'm afraid.

FWIW, a manpage is already written as a heredoc in the  script.  All it needs
is to be marked up.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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.

Sorry, no test cases, just the 500+ fonts I've installed successfully with the
script.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60930>

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 dozens of partial families, and plenty with just .sty's taken
from mom's offerings


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 annoy me
[and other users] when tab-completing "groff")
> 
> My suggestion for a name is *fforg*.

Too many letters in common with fontforge, of which it looks like an
abbreviation.  Also, the name gives no indication of the script's function or
domain of operation.  Cute idea, though.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Follow-up Comment #19, bug #60930 (group groff):

How about just gfont?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

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 ticket
doesn't concern
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/mom.am
contrib/mom/mom.am] itself, but merely uses that file's build options as a
template for what ought to appear in
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/README.txt
contrib/mom/examples/README.txt] (and its
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/README-fr.txt
README-fr.txt] counterpart).  That is, it's suggesting changes akin to:

> diff --git a/contrib/mom/examples/README.txt
b/contrib/mom/examples/README.txt
> index 851a9a27a..34e06153c 100644
> --- a/contrib/mom/examples/README.txt
> +++ b/contrib/mom/examples/README.txt
> @@ -21,9 +21,9 @@ files with pdfmom(1).
>  pdfmom mom-pdf.mom > mom-pdf.pdf
>  pdfmom sample_docs.mom > sample_docs.pdf
>  pdfmom slide-demo.mom > slide-demo.pdf
> -pdfmom -k letter.mom > letter.pdf
> -pdfmom -k mon_premier_doc.mom > mon_premier_doc.pdf
> -pdfmom -k typesetting.mom > typesetting.pdf
> +pdfmom -K utf8 letter.mom > letter.pdf
> +pdfmom -K utf8 mon_premier_doc.mom > mon_premier_doc.pdf
> +pdfmom -K utf8 typesetting.mom > typesetting.pdf
>  
>  The files themselves
>  
> @@ -78,8 +78,8 @@ all PDF readers.
>  
>  The file, mon_premier_doc.mom, is a simple example in French showing
>  the use of common elements: section headings, paragraphs, lists, table
> -of contents and clickable links.  It should be generated with option -k
> -as there are some accented letters.
> +of contents and clickable links.  It should be generated with option
> +"-K utf8" as there are some accented letters.
>  
>  A few settings were also changed for this French document:
>  ATTRIBUTE_STRING is used to replace "by" by "par" in the document


> To my eyes, this appears to be a legitimate refinement, as -K is more
reliable than -k for known encodings.  But Peter is in charge of the content
of these files, so I'm reassigning this to him so he can make that call.

I've pushed the changes.  Closing this ticket.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Follow-up Comment #26, bug #64155 (group groff):

I guess I wasn't clear enough when I advised not implementing .fam checking as
proposed by Branden, as I have just discovered the change has been committed,
with the expected consequence: partial families in my library that have only R
and I fonts choke on .fam.

  printf ".fam Technical\n.ft R" | groff -z 
  troff::1: error: 'Technical' is not a valid font family

This is a regression.  Please revert the commit that introduced it,
39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.  I don't see any need for .fam
checking in the first place, but that discussion should be left for after the
commit is reverted.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Peter Schaffter]

Update of bug #64155 (group groff):

  Status:   Confirmed => Need Info  

___

Follow-up Comment #32:


[comment #28 comment #28:]
> [comment #27 comment #27:]
> > Hi Peter,
> 
> I should have spent a little longer on that comment since I tossed the ball
back into your court, even if just for advice.
> 
> > Please confirm my understanding of the foregoing and I will proceed with
the reversion right away.
> 
> Specifically, am I correct to claim either of the following?
> 
> A.  "[G]iven that mom has her own system of managing fonts, and part of her
contract with the user [...] is that [the] user will not go behind her back
and start invoking *roff requests." is a false statement.  (Possibly an
exaggeration.)

Oversimplification, possibly my fault.  You got the idea from this bit of the
documentation:

"In some cases, mom’s typesetting macros merely imitate groff primitives. In
others, they approach typesetting concerns in conceptually new ways (for
groff, at least). This should present no problem for newcomers to groff who
are learning mom. Old groff hands should be careful. Just because it looks
like a duck and walks like a duck does not, in this instance, mean that it is
a duck. When using mom, stay away from groff primitives if mom provides a
macro that accomplishes the same thing."

That's not a contract, it's a recommendation.  I don't want users imagining.
for example, that they can use either .ps or .PT_SIZE interchangeably (or
.ft/.FT) and expect the same results.  E.g. if AUTOLEAD is enabled, .PT_SIZE
changes the pointsize and updates the leading.  Plain .ps only changes the
size, hence the recommendation to stay away from groff primitives *if mom
provides a macro that accomplishes the same thing.*  There a number of macros
where the documentation explicitly states that using a primitive instead of a
macro is fine.

I'm not comfortable with the statement "mom has her own system of managing
fonts."  Other than that .FAM and .FT perform checks and set registers needed
by other macros, and the inclusion of pre-defined supplementary styles (none
loaded in positions 1-4), there is nothing unique about mom's font
management.
 
> B.  The statement "By issuing appropriate formatter instructions, you can
override these defaults before your document writes its first glyph." in our
manual should be dropped, or revised to stipulate that some macro packages
(namely _mom_), will assume that that before a document requests a glyph to be
formatted, mounting position 1 will be assigned to a style named 'R'.

I'm confused.  The docs currently say, "The default mounting position, and
therefore style, is always '1' ('R')"  Why would this suddenly only apply to
"some" macro packages?  I don't think the B. statement should be dropped, but
I would change "these defaults" because the only formatter flag pertinent to
that section of the documentation is -f .



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/