Re: New Chapter within an MM document
On Sat, Dec 19, 2020 at 02:20:57PM +1100, Damian McGuckin wrote:
>
> Within an MM document, a level 1 heading like
>
> .H 1 "Heading"
>
> is rendered as
>
> 4. Heading
>
> Often, it is forced to a new page using
>
> .nr Ej 1
>
> I would like also to currently force it to
>
> Step Down N lines
> Move Right M spaces
> Prefex everything by some text such as Chapter
>
> so it says something like
>
> Chapter 4. Heading
>
> Has anybody done something similar? I tried to use heading customization
> macros but have gone nowhere fast.
I have attached an example.
The macros are a strip-version of the ones I used for my phd-thesis in 2009.
> Just thought I would ask the group before I jump back into the fray in case
> somebody has already solved the problem.
The generator worked again.
> Using another Macro set is impractical.
Indeed.
greetings,
Bob
.ds chapter "Chapter
.de HX
.if \\$1=1 \{
. if e .bp +1
\&
. SP 0.5i
. ad r
. S +12
\\*[chapter] \\n[H1]
. S -12
.\}
..
.de HY
.if \\$1=1 \{
. ds hd*mark
. ad r
. SP 0.5i
.\}
..
.de HZ
.if \\$2=1 \{
. SP 0.6i
\\l'\\n[.ll]u'
. br
. SP 0.25i
. ad b
.\}
..
.H 1 "Header 1"
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
.H 2 "Header 2"
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
.SK
.H 1 "Header 1"
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text
testheaders.pdf
Description: Adobe PDF document
Re: [mdoc]: Emit diagnostic if .Mt given no arguments.
Hi Branden, G. Branden Robinson wrote on Sun, Dec 20, 2020 at 03:38:56AM -0500: > gbranden pushed a commit to branch master > in repository groff. > > commit 854fec5025af62c6ba6b72f9075bc71317d83a60 > Author: G. Branden Robinson > AuthorDate: Sun Dec 20 18:57:05 2020 +1100 > > [mdoc]: Emit diagnostic if .Mt given no arguments. > > * tmac/doc.tmac-u (Mt): Emit a usage diagnostic and return if called > with no arguments. This introduces an incompatiblility with > mandoc(1), That's not a serious problem, mandoc(1) is easy to adjust in this case after the behaviour of groff is improved. > but the existing behavior (print an italicized tilde, > because Mt is implemented as a wrapper around Pa, which prints > pathnames) made no sense. I do not object to that opinion. > mandoc(1) prints a _non_-italicized tilde in this scenario. You are mistaken, mandoc(1) is fully compatible with groff(1) in this respect. The output is byte-by-byte identical, and in fact mandoc(1) was made bug-compatible with groff(1) in this respect, on purpose: $ echo .Mt | mandoc -mdoc | hexdump -C [...] 0050 5f 08 7e 0a 0a 0a|_.~...| That _is_ underscore - backspace - tilde, i.e., an italicized tilde, exactly like in groff. [...] > diff --git a/tmac/doc.tmac-u b/tmac/doc.tmac-u > index a5fd82d..eab0c27 100644 > --- a/tmac/doc.tmac-u > +++ b/tmac/doc.tmac-u > @@ -6444,8 +6444,10 @@ > .\" NS mailto (for conversion to HTML) > . > .de Mt > -. \" XXX: error handling missing > -. Pa \$@ > +. ie !\n[.$] \ > +.tm mdoc usage error: .Mt email-address (#\n[.c]) > +. el \ > +.Pa \$@ > .. I do not object to your general ideas of requiring an argument nor of emitting a warning if the argument is missing. Maybe even your decision of not printing anything if the argument is missing is acceptable. But unfortunately, your implementation is incorrect. The following still prints the tilde: .Mt . The reason is that many mdoc(7) macros implement generic handling for trailing punctuation, which you apparently failed to consider. So even the multiple-argument macro .Mt . , : ; ) ] ? ! ) \. ) ) \*(Ba ) ) still needs to be regarded as empty. Implementing that correctly is no doubt possible. On first sight, i'm not sure how difficult that might be and whether it's worth doing. Either way, i don't think your commit can remain as it is. Yours, Ingo
Re: groff_mdoc(7): Document .Lk and .Mt macros.
Hi Branden, G. Branden Robinson wrote on Sun, Dec 20, 2020 at 03:38:54AM -0500: > gbranden pushed a commit to branch master > in repository groff. > > commit 11301d8bd374bf1d4db3ac43c9e8e9ca45836a45 > Author: G. Branden Robinson > AuthorDate: Sun Dec 20 14:29:21 2020 +1100 > > groff_mdoc(7): Document .Lk and .Mt macros. > > ...tersely. > --- > tmac/groff_mdoc.7.man | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/tmac/groff_mdoc.7.man b/tmac/groff_mdoc.7.man > index bd4132c..dedc65a 100644 > --- a/tmac/groff_mdoc.7.man > +++ b/tmac/groff_mdoc.7.man > @@ -4054,7 +4054,12 @@ followed by the file name, then the contents of > It is neither callable nor parsed. > . > .It Li .Lk > -To be written. > +Embed hyperlink. > +. > +. > +.Pp > +.Dl Usage: .Lk Ao url link-text Ac I think this is incorrect. Empty .Lk prints nothing and mandoc even warns about it: mandoc: tmp.mdoc:9:2: WARNING: skipping empty macro: Lk So i think the first argument isn't optional. But the second argument definitely is optional. Correct markup would be: .D1 Usage: Pf . Ic \&Lk Ar uri Op Ar link-text I know the groff_mdoc(7) manual violates mdoc markup conventions throughout in very ugly ways, and at some point, that should be fixed. The use of .Ao is disgusting in particular and clashes with the semantic markup paradigm that is fundamental to mdoc. But at least the manual should not mislead as to which arguments are mandatory and which are optional. > +. > . > .It Li .Me > Exact usage unknown. > @@ -4066,7 +4071,12 @@ source file describes it as a macro for > Its default width is 6n. > . > .It Li .Mt > -To be written. > +Embed email address. > +. > +. > +.Pp > +.Dl Usage: .Mt email-address > +. Except for the missing markup, the content of this part seems correct. Yours, Ingo
Re: End-of-sentence spacing
I'm not completely sure it's true for all modern applications, but I hope you're right that it doesn't hurt in general to explicitly type two spaces after a sentence. As a dinosaur, that's what I used to do, but trained myself out of it after reading a high-profile tirade scolding me (at least it felt like I was being individually targeted, so I promptly wilted). I mean of course the famous https://slate.com/technology/2011/01/two-spaces-after-a-period-why-you-should-never-ever-do-it.html It was neither the only, first, last, or most vituperous critique of Two Spaces: There has been a rising tide of condemnation of the practice in the media, as shown by Googling "two spaces after period". I am yet to see any similarly full-throated defense of it. But now that I know what's possible, it doesn't matter so much and I don't really need to re-train, or re-re-train, myself. I've been able to configure my text editor so it will insert the extra space if I missed it, but only for groff input. And, no, it's not too difficult to develop a heuristic for when to insert that second space. In Vim, for instance, %s/\([.?!][’”'")\]]*\) \ wrote: On 12/19/20, Dorai Sitaram wrote: > groff pretty much forces one to use two spaces after sentence-ending > punctuation, unless it's at the end of a source line. Is there a way to > avoid this, so that the space is uniform regardless of whether the ending > punctuation occurs mid- or end-line? Using 0 as the second parameter of the .ss request results in the same space being put between words and between sentences. > (I could resign myself to always type > 2 spaces after every sentence, but convention has moved away from this type > of unergonomic typing, and it's difficult to do it just for groff.) I'd turn this around, and ask what other applications misbehave if you type two spaces between sentences? I type that way across the board with no noticeable down side. Developing the habit of typing everything with two spaces between sentences aids the writing process, because it's easy to do searches to find sentence boundaries (and some text editors have keystrokes that recognizes such sentence boundaries automatically). If your final copy requires that sentences be separated by only one space, it's easy to squeeze out the extra space with a simple search and replace (whereas the opposite is impossible to do with an algorithm, because so many different punctuation combinations can end sentences, and algorithms can't always distinguish between a period ending a sentence and a period indicating an abbreviation). But you'll probably find that leaving the extra spaces in doesn't cause any problems, no matter what the application is. Anything displayed in HTML will squeeze it out anyway on display. Other applications will show it, but what is the down side to that? In informal contexts such as email and online chat tools, there almost certainly is none. In material that needs to be typeset to modern convention, where sentences don't get extra space, whatever typesetter you're using will almost certainly handle this.
Re: groff_mdoc(7): Add link to mandoc project.
Hi Branden, G. Branden Robinson wrote on Sun, Dec 20, 2020 at 03:38:54AM -0500: > gbranden pushed a commit to branch master > in repository groff. > > commit ca0dfa5ff724eaf21a8b79f4ee825979ef3294fc > Author: G. Branden Robinson > AuthorDate: Sun Dec 20 14:10:09 2020 +1100 > > groff_mdoc(7): Add link to mandoc project. > --- > tmac/groff_mdoc.7.man | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/tmac/groff_mdoc.7.man b/tmac/groff_mdoc.7.man > index e383fe3..bd4132c 100644 > --- a/tmac/groff_mdoc.7.man > +++ b/tmac/groff_mdoc.7.man > @@ -4356,6 +4356,16 @@ Multiple man pages (in either format) can be handled. > . > .Sh "See also" > . > +The > +.Lk https://mandoc.bsd.lv/ mandoc > +project maintains an independent implementation of the Thanks, so now the mdoc(7) manual page in the mandoc package and the groff_mdoc(7) manual page in the groff package point at each other. I think that's good and may occasionally help users because different people may like different styles of documentation and because some particular details may be easier to understand in one page, some in the other. > +.Xr mdoc That's an mdoc(7) syntax error, .Xr requires two arguments. I think this should be ".Xr mdoc 7". > +language and a renderer that directly parses its markup as well as that > +of > +.Xr man . dto.: .Xr man 7 . Yours, Ingo
Re: End-of-sentence spacing
> I'm not completely sure it's true for all modern applications, but I > hope you're right that it doesn't hurt in general to explicitly type > two spaces after a sentence. As a dinosaur, that's what I used to > do, but trained myself out of it after reading a high-profile tirade > scolding me (at least it felt like I was being individually > targeted, so I promptly wilted). [...] I always use two spaces after a full sentence – for *input*. Main reason are editors like Emacs that use this to identify the end of sentences, allowing you to move the cursor around sentence-wise. For output it's really up to the selected typography style. On the other hand, there are programs like MS Word that output two spaces if you enter two spaces, regardless where they are. I've seen soo many documents that have uneven spacing within sentences. Honestly, this bad usage of the program due to incompetent users completely dwarfs the two-spaces-after-a-full-stop problem... Werner
Re: End-of-sentence spacing
On Sat, Dec 19, 2020, Dave Kemper wrote: > I think you're confusing starting every sentence on its own line with > using newlines nowhere *except* between sentences. You are right. My distaste for hitting return instead of space after a period clouded my reading of the advice. :) > > Furthermore, since groff treats end of sentence characters followed > > by one space, two spaces, or newlines identically when sentence > > spacing is disabled (as it is by default), > > That *should* be true, but isn't > (http://savannah.gnu.org/bugs/?58500). Some non-English-language tmac > files disable wider sentence spacing, and perhaps some macro packages, > but by default groff itself does not. Perhaps I should have been more verbose and written: According to the info(1) manual, initially both the WORD_SPACE_SIZE and SENTENCE_SPACE_SIZE are 12; since this prevents SS from being larger than WS, it effectively disables sentence spacing. It just seemed easier to write "disabled by default." -- Peter Schaffter https://www.schaffter.ca
Re: End-of-sentence spacing
On Sun, Dec 20, 2020, Dorai Sitaram via wrote: > I'm not completely sure it's true for all modern applications, > but I hope you're right that it doesn't hurt in general to > explicitly type two spaces after a sentence. As a dinosaur, > that's what I used to do, but trained myself out of it after > reading a high-profile tirade scolding me (at least it felt like > I was being individually targeted, so I promptly wilted). I mean > of course the famous > > https://slate.com/technology/2011/01/two-spaces-after-a-period-why-you-should-never-ever-do-it.html The article addresses itself to the use of two spaces after a sentence *in typeset copy*, i.e. copy that uses proportional fonts, which is indeed frowned upon. How one enters monospaced text at the screen or on a typewriter--yes, people still use typewriters and the ribbon is still sold--is not covered at all, except to point out an error that results from conflating the two (putting two spaces in typeset copy). In typewriter-style copy, e.g. email, "two spaces between sentences" has been considered standard for a really long time. In my experience, it does make monospaced text easier to digest. I reflexively reformat received emails to introduce the extra space if it's not there. YMMV. That said, there is no reason not to introduce a tiny amount of extra space between sentences in typeset copy. It depends on the font. Those with tall caps in relation to the x-height usually don't need it, but those with caps that blend into the overall grey are often improved. It's a judgment call that requires a practised eye. -- Peter Schaffter https://www.schaffter.ca
Re: "mom": addition of ellipsis causes an over-strike
On Sun, Dec 20, 2020, Steve Ross via wrote:
> In the resulting PDF output file, the ellipsis appears on page 10,
> as expected. However, on the same line, about six characters
> further to the right, I also see about three characters being
> over-struck, which is unexpected.
>
> I have attached both the input "mom" file
> ("sample_docs-steve.mom"), and the output PDF file
> ("sample_docs-steve.pdf").
>
> The "groff" version is 1.22.3.The "mom" version is 2.4-4_c.
There is no overstriking when your file is processed with groff
1.22.4 (and later). From the age of your originally-installed mom
and groff, it looks as if your distro hasn't kept up with groff
development.
--
Peter Schaffter
https://www.schaffter.ca
Re: Is .rd implemented at all?
On 12/20/20, G. Branden Robinson wrote: > At 2020-12-16T20:30:33-0600, Dave Kemper wrote: >> Ubuntu is a Debian-derived distro, and the concurrent "local timezone" >> thread here points out Debian's proclivity to customize groff in >> incompatible ways. > > I don't think that statement is quite fair--I've known Colin for a long > time and he is a diligent developer and package maintainer. Different > projects face different pressures. It's true, I shouldn't have generalized one example to a "proclivity." But my comment wasn't meant as an indictment of Debian's decision or Colin's work, merely an observation that it changed functionality from stock groff, and I apologize if it came across otherwise.
