"SGT. Garcia" wrote:
> sorry for being too short. in the following (abbreviated) .UR can not be
> used out side of the T{...T} block. or else it's interpreted literally:
What is the problem of the T{...T} block? It works--so why don't you want to
use this solution?
"SGT. Garcia" wrote:
> latter, i want URL to appear in the table, using .UR.
Why can't
T{
.UR ...
.UE
T}
be used to output the URL?
Hello,
in groff_char.7 it is specified that U+0303 is output for \(a~ but actually
U+007E is output. Why does the output (of nroff -Tutf8) differ from the
specification?
Carsten
Hi Ingo,
> It seems to me that you misread the documentation. It reads:
[...]
> The combining (non-spacing) variant shown before the parenthesis
> only applies in the context of the .composite request.
Indeed. Thank you!
Hello,
the build of the git repository fails on NetBSD 6.1.5:
$ make
make all-am
g++ -g -O2-o grn src/preproc/grn/hdb.o src/preproc/grn/hpoint.o
src/preproc/grn/hgraph.o src/preproc/grn/main.o lib/libgnu.a libgroff.a -lm
libgroff.a(libgroff_a-font.o): In function `font::get_width(glyp
Hello,
how can HTML be output by using the traditional troff pipe, i.e. not by
calling"only" "grohtml ..." or "groff ..."?
Carsten
Hi Ralph,
> > how can HTML be output by using the traditional troff pipe, i.e. not
> > by calling"only" "grohtml ..." or "groff ..."?
>
> See groff's -V option to have it print the troff pipeline and not
> execute it. You can pick apart the pieces from that.
That's a good hint. Thank you!
Chee
Hi Dorai,
> Thanks Ralph. I guess +x would have the same "accumulating" behavior as -x.
> Curious there seems to be no way to represent a negative literal number the
> way one can specify a nonnegative one, i.e., a negative number just for
> itself, not as a decrement.
> I was able to solve my p
Hello,
at http://www.gnu.org/software/groff/manual/html_node/Drawing-Requests.html it
is documented, that the output position of text following a \L request is the
end of the line. If there is the code
This is a \L'3v'test.
Second line.
then "Second line." is expectedly drawn after "test.".
> I think this shows the issue.
>
> $ nroff
> .pl 5
> This is a \L'3v'test.
> Second line.
> ^D
> This is a
> ?
> ?
> ?test. Second line.
>
> $ nroff
> .nf
> .pl 5
> This is a \L'3v'test.
> Second line.
> ^
> Yes. \L is like local motion (i.e., like \v, and also \D) --
> it is restricted to the current output line, and beginning a
> new output line "forgets" it has happened. Try this:
That would explain it. But is it documented? I did not find it in the groff
documentation and CSTR54 does only doc
> Hmmm, actually I don't know. I guess a long time ago I just
> noticed the similarity and simply attributed it to being the
> result of a corresponding similar implementation.
It is likely that the implementation is correct. IMHO it would be better if
there had been a note in the documentation
Hello,
I did ask a similar question some time ago ... maybe the man page groff_char.7
is not optimal ;-)
The man page says that \(bu has unicode U+2022, but nroff puts out U+00b7. Is
this a "bug" (... or did I once again got the documentation wrong ;-)?
--Carsten
Blake McBride wrote:
> I'd prefer it to be changed to work as expected rather than have to employ
> secret internal steps.
IMHO it is not expected that .ll is compatible with the -mm macros. These
macros often set .ll from register W or other internal registers. It looks to
me that -mm doesn
Hi Ralph,
> groff_mm(7):
>
> PGFORM [linelength [pagelength [pageoffset [1
thank you!
If one *uses* heirlooms -mm macros and *really* needs that feature it could be
added. Otherwise I would agree with Tadziu that initially setting W should be
sufficient. The -ms macros had register
> 1. I do use Heirloom troff and I often use MM.
This is a statement. So heirloom MM will be changed now.
> 2. The current behavior is wrong, period. The fact that changes are being
> made to Heirloom at all proves that it isn't a think of absolute perfection
> - not to be touched. If this i
> Adding .PGFORM is fine, but I would prefer just having .ll work like it
> does on groff. This way the original docs work and produce as expected.
.PGFORM is already implemented but not committed yet.
Do you know how .ll works in groff's MM? It is not documented. You know how
it works for y
> .DS 1
> .EQ LABEL
> equation
> .EN
> .DE
For my tests LABEL is aligned with the normal right margin (outside .DS).
Could you please send an example document?
But I notice an other problem: If I use .DS 1 1 (enable fill mode) without .EQ
for this test, the right margin is shifted to the righ
As a guess the problem with .DS 1 seems to be that the text is written with .i
= 0 into a diversion with .l from before .DS, then the diversion is output in
.nf mode with .i > 0 ... Of course then the right margin is shifted. So for
.DS 1 .l in the diversion should be reduced by \n(Siu (m.tmac
The example does work for me with the the patch:
diff --git a/contrib/mm/m.tmac b/contrib/mm/m.tmac
index 4b76039..09cc03b 100644
--- a/contrib/mm/m.tmac
+++ b/contrib/mm/m.tmac
@@ -2083,7 +2083,9 @@ in=\\n[.i] fi=\\n[.u] .d=\\n[.d] nl=\\n[nl] pg=\\n[%]
'in 0
.di ds*div!\\n[ds*snr]
.\"
-.ds@set
Hi Damian,
> To where should I send my examples.
I would say if you attach only the document in .gz format (or .tgz if there is
more than one file) it is ok. Many don't like attachments but they have the
advantage that the mailer can't change white space etc. The PS output is IMHO
not require
Hi Damian,
with groff from git and
tbl bug.txt | eqn | troff -mm -Tps | grops >bug.ps
I don't see the labels beyond the margin (like in your file), they are exactly
aligned. Could you please send the command with which you generate bug.ps?
--Carsten
PS: Nethertheless there is a bug in -mm wh
No, please delete the line
.ds@set-new-ev \\n[ds*old-ll]
and insert
.nr ds*div-ll \\n[ds*old-ll]
.if \\n[ds*format]=1 .nr ds*div-ll -\\n(Sin
.ds@set-new-ev \\n[ds*div-ll]
at exactly the possition where that line had been. Please don't change @ into
something else.
Hello,
in a manual page I found the commands
.ie '\*[.T]'utf8'
. ds Un \[cu]
.el
. ds Un U
.
The .ie and .el lines don't end with a backslash. Nethertheless this works
with groff. Is this documented? If not this is a misleading "feature" since
it doesn't tell the author that this code has
Hello,
reffort@github (https://github.com/reffort) did notice a major issue in one of
the key features of Heirloom roff which is paragraph-at-once formatting.
Gunnar very likely did implement this algorithm based on the 1981 Knuth-Plass
paper (KP-81 in the following text) and had maybe not bee
Hello,
compared to TeX Heirloom's paragraph formatting is unacceptable and will
change. It is likely that parameters of the new behavior will be adjustable
(since it depends on the typographs taste and the actual document, what is
best), even the algorithm will be selectable (so e.g. current T
Anton Shterenlikht wrote:
> I'm making a document with multiple lists
> of references. Each list comes under its own
> header, so I don't need "References" written
> at the top of each list. I'm using ms.
> How can I disable the printing of string "References".
>
> In case it matters, I process ea
To put
.rm REFERENCES
at the begin of z.1 is not recommended since it only removes the string
"REFERENCES" but there is some additional space caused by the macro using that
string.
But
.rm ref*biblio-start-hook
does work for me with your example.
$ cat z.1
.rm ref*biblio-start-hook
Hello,
in lack of a Heirloom roff mailing list from time to time I use the groff list
for Heirloom discussions hoping that some Heirloom users are on this list.
It had IMHO been an unfortunate decision to to give \A at Heirloom a different
meaning than that of groff's \A. Now I need this funct
Blake McBride wrote:
> I have a table that spans several pages. I would like the tbl column
> titles to repeat at the top of each page (*independently *of the page
> title). Can tbl do this?
At least with -ms or -mm you can write something like
.TS H
box;
cb cb cb
l l l.
Column 1Column 2
.TH
> Didn't know about TS with H and TH. Where is that best documented? (The
> man page mentions them in the bugs section but it is incomplete.)
As Nigel mentioned this is e.g. documented in "Unix Text Processing", Dale
Dougherty & Tim
O'Reilly page 224 (available at http://www.oreilly.com/openboo
Hi Ralph,
> It may pre-date your time on this list, but some of us here re-entered
> the book as troff source from the scan after I got Tim O'Reilly's
> permission. http://home.windstream.net/kollar/utp/
yes, I know that and long time ago I mirrored that sources to my HDD. But up
to now did u
Hello Doug,
> Examples of figurate text appear in Knuth's paper on
> the placement of line breaks. How would the changing indent
> and length parameters be expressed in TeX?
this is in general described in the TeXbook on page 101 for the \parshape
command.
There one can set \parshape=n i1 l1 i2
Hello,
build of groff on NetBSD fails with
make all-am
make[1]: don't know how to make contrib/chem/chem.1. Stop
It did work at least until 10th of August. There had been a change to
contrib/chem/chem.am
since then:
diff --git a/contrib/chem/chem.am b/contrib/chem/chem.am
index a8ca170..b6f
Hi Ralph,
> If you use -k then is chem.1.man the only man page that fails to build?
> Or does a whole slew of them suffer the same problem?
There are quite some man pages failing, may all be the same problem:
make[1]: don't know how to make contrib/chem/chem.1 (continuing)
make[1]: don't know h
Hi Anton,
> Probably does not help you,
> but since you are talking about BSD make,
> groff 1.22.2_3 builds fine on FreeBSD.
> (3 is the FreeBSD port revision for this groff version).
current groff git does also work on an older OpenBSD-"CURRENT" (from May)...
I'm am surprised that NetBSD diffe
Hi Anton,
thank you!
It seems that version 1.22.2 is used here.
I now checked out the git version from August 9th--it does compile. So the
problem may be a groff change since then.
--Carsten
Hi Ralph,
> If you're not yet familiar with git-bisect(1), now might be a good time.
> :-)
The issue occurs between the adjacent commits
b7441aee00f26cb2f68094d24eae9cc72eb0c678
and
9d885c6b342f71594af5d45f37ce65c121641e25
The log message by Bernd had simply been "Add new tmac file pdfpic.tma
Hi Ralph,
> I think the changes might be from Bertrand Garrigues and Bernd included
> them in his commit by accident, thus the description not matching;
> http://lists.gnu.org/archive/html/groff/2015-09/msg0.html
thank you! Bertrand is the groff build system expert now anyway :)
... Bertra
Hi Bertrand,
> Do you have another (non-GNU) troff installed on your system? In such
> case the build is slightly more complex and for the man pages we go
> through (in Makefile.am) the commands after:
I have non-GNU troffs installed, but their man pages are in non-standard paths
so groff's con
Consider that groff itself is somehow like plainTeX. You may need a macro
package for creating documents. But traditional macro packages do (AFAIK) not
provide TOC, index, cross references *compared to LaTeX*. Up to now I did not
test the MOM macros (http://www.schaffter.ca/mom/mom-01.html) b
Henry McGilton wrote:
> I also tried \[char a74], which should show a white square with a black
> drop-shadow.
I just downloaded the TTF font Zapf_Dingbats_BT.ttf and tested the folowing
lines with Heirloom:
.do xflag 3
.fp 0 TTFZD Zapf_Dingbats_BT.ttf ttf
.ft ZD
\[a74]
.ft TTFZD
\[a74]
This
Hello,
I'm now in a similar situation as Steffen had been some time ago. Heirloom
doesn't format groff's manpages correctly. One of the reasons are macros added
to groff's -man (.SY, .OP, .YS) which are of course unknown to other roff
variants. I thought implementing these shoud be simple bu
Werner LEMBERG wrote:
> > I cannot use the first line unfortunately, it is not compatible to
> > licences of other files.
>
> Why not? Please explain.
Ok, I'm not sure. Others files licence is CDDL, at least I have heared that a
binary can't use sources with mixed CDDL and GPL.
There are al
> > But the mention of a FSF copyright has nothing to do with
> > GPL--right?
>
> Correct.
Ok, if the file is "unlicenced" then the header can of course stay like it is.
Thank you for clarify this.
Carsten
Hi Ingo,
thank you very much for explaining this in detail and giving a lot
of additional information. I need to save this mail for possible
later reference in similar cases.
That author names need to stay forever in a file is a matter
of course also without knowlegde of copyright laws.
Ok, now
Damian McGuckin wrote:
> What is the real fix please?
... the .sp -1 and \c in misc@tag don't look reliable and depending on what
follows may cause issues. This seems to be the case here. H adds space after
the heading, with the .br at begin of DS that space gets fixed. Now DS of
cause adds
Hello Mike,
what do you mean here--Damian didn't use \#?
Carsten
Damian McGuckin wrote:
> The use of \# looks like a fudge to fix a problem. Which sounds like a
> recipe for disaster.
Indeed :)
> Or are my ideas too rooted in the past? Comments (Doug)?
I think Doug is not to blame here :)
Werner, is misc@tag really written by you? Isn't it dangerous to u
Damian McGuckin wrote:
> [...] I was after some words of wisdom or
> more precisely, insight, from somebody who had used such a tool for longer
> than I have.
This is totally groff specific, AT&T roff didn't have this issue (and groff
doesn't have it either if this HTML specific line is remove
Werner LEMBERG wrote:
> No time to dig into this issue. If you provide a patch, I'm gladly
> applying it.
The macro misc@tag is solely used for HTML output (currently). It causes the
problem in this case (the line \h'\\n[misc*.k]u'\c). I suggest to enable this
macro only in HTML mode to avoi
Hello,
Bertrand Garrigues wrote:
> It would be helpful if you could send me the complete logs of your build
> (both configure and make phases).
To close this issue: Bertrand has traced the root cause to a bug in make(1)
used by NetBSD. FreeBSD uses this make(1) too so the issue does also occu
Hi Ralph,
> The `.in 1i' gives 2i indentation. Without diversions, this doesn't
> happen so in some way the token for indentation occurs once originally
> and is "replayed" by .prevline? I'm sure this has been discussed
> before, but my Google fu let me down.
.in should be set to 0 when the di
Hello Henry,
Henry McGilton wrote:
> I have been reading and re-reading the Heirloom instructions for
> adding fonts to the collection.
>
> Given that dpost is (apparently) a reflection of a LaserWriter II,
> should I add new fonts to dpost, or should I create some new
> device of my own?
Have
Doug McIlroy wrote:
> Bad case I: [...]
It neither works in groff nor in heirloom roff as specified (in original -ms
specification).
I suggest to make .QS, .QE, .QP work as specified for traditional -ms without
any warnings. Then there may be some redundant code in .QE and .RE but this
shoul
Doug McIlroy wrote:
> The -ms macro QE typically draws a misleading diagnostic, "unbalanced QE".
> This breaks old documents that expect QP-QE (quoted paragraph) to narrow
> the text and then restore it. The groff QE does not restore.
I had been wrong here. For the simple tests I've done groff
The paragraph spacing bug is also visible in the
re-typeset book utp_book-1.1.pdf (page 90). The
original book does have vertical space before the
quote (page 110).
The sentence "Use the .QP macro inside a .QS/.QE
block to break up paragraphs." on this page does
IMHO has a typo--.LP or .PP should
Hello,
the warning message is of course correct already.
For adding the vertical space macro par*start could be used, but the fewest
side effects to the current implementation may it have to add the vertical
space request directly. For @RE the macro name needs to be checked of course.
(Addit
Steffen Nurpmeso wrote:
> Disclaimer: i never have used ms nor have i ever looked into the
> macros.
> But of course i was interested in this and while i fully trust you
> (i haven't even tried it) i think a better approach would be to
> avoid the repititions. I saw you've copied+pasted the .sp
Hi Ralph,
> If the simple, minimal, change could be better implemented then I'd
> suggest making two commits. The first makes the fix, the second
> improves the source with "No functional change intended".
this is a good idea indeed. The first commit is done, now I can look how to
make the af
Hello,
since the last Heirloom troff release one year ago there had been many bug
fixes. Most of them are -mandoc related, some also address general typesetting
issues. It had become necessary to create a new release since the state of the
current release is quite obsolte.
Before the release
Werner LEMBERG wrote:
> Ah, I wasn't aware that the project moved to github. Please commit a
> last change to the CVS repository that explains that the project has
> moved, and that the CVS repository is now defunct! Ditto for
> http://heirloom.sourceforge.net/doctools.html.
That would indeed m
Hi Dorai,
Dorai Sitaram wrote:
> This is somewhat related. What is the canonical way to determine using
> generic troff commands that the troff being used is Heirloom troff, without
> regard to whether compatibility is off or on? (I used to test the number
> register .g to rule out groff, but a
Hello,
git cloning groff seems not to work at the moment:
$ git clone git://git.savannah.gnu.org/groff.git
Cloning into 'groff'...
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
This is tested on OpenBSD-CURRENT, but
> the README
> mentions INSTALL
>
> See the file `INSTALL' for instructions on how to install from a
> release. You will require a C++ compiler.
>
>
> But is not available
Maybe your local repository is not in sync. There is the symbolic link
INSTALL -> gnulib/doc/INSTALL
--Carsten
Doug McIlroy wrote:
> But it is not unnoticeable in case of unary minus.
> Groff eqn treats
> a~=~-b
> as if it were binary, and inserts extra space between
> the - and b.
It does work with the following patch--for the mentioned cases.
In case of a=c~-b then there is only space before the
Hello,
I did some further tests, the patch did work in these cases.
That "a=c~-b" is then rendered as "a = c -b" (instead of "a = c - b" without
the patch)
is IMHO consistent and not a regression. I does also work with '^' instead of
'~'.
Does someone like to do further tests or can we agree
The issue is fixed now in the git repository.
--Carsten
Hi,
?ukasz Stelmach wrote:
> I am developing a macro to print envelopes. Is it possible to pass a
> multi-line string (not necessarily defined with .ds) as a parameter
> for a macro?
what exactly would you like to do? Can you please give an example?
--Carsten
Henry McGilton wrote:
> I probably sound like a complete dummkopf in this illustrious group, but I
> have tried and
> failed with both Heirloom and regular groff.
ZD does work with Heirloom troff (and with DWB3.3 too), as I did already
wrote in http://lists.gnu.org/archive/html/groff/2015-12/msg
Hello Henry,
> So I am on El Capitan, and I am using the groff which comes installed
> with El Capitan, GNU groff version 1.19.2
I would suggest to compile from git in this case. groff's git source is
normally very stable and you can get quick bug fixes if issues occur.
It also may help groff to
nicolas.bourb...@web.de wrote:
> It is not long ago since I began using groff for text processing
> and I like it a lot.
> After having only used the default format for my bibliography,
> I would like to adapt the output a bit more to my needs.
> Therefore, I included some options between the .R
John Gardner wrote:
> I'm using the dl register to set page indent with .in, which works fine in
> nroff, but generates absurdly large sizes in groff. For instance, a
> diversion with a width of 624 in TTY output becomes 286946 in PostScript.
If you use .in with a register value you have to set
> > http://troff.org/54.pdf
It is recommended to study this document carefully. groff has useful
extensions, but it's best to learn them when you know about the portable subset
of the roff language.
You e.g. often use requests with register contents as arguments without using a
unit. I hope
Hello,
actually I don't think it is really a heirloom-doctools issue, but rather
problem with the font or ghostscript.
The problem is described at
https://github.com/n-t-roff/heirloom-doctools/issues/33
With the test file supplied by the user and
troff -ms test.ps | dpost > test.ps
gs test.ps
Hello,
for generating
[n]"dd"
which means "an optional number followed by string dd" in a list I use
.Bl -tag
.It ...
.It Oo Ar n Oc Ns Dq Li dd
.It ...
This is formated as expected by mandoc(1) and Heirloom nroff.
groff (current git) does indent two characters less than
and .
Is this a
> Carsten, can you post a complete self-contained example with .It arguments,
> .El etc.?
.Dd October 2, 2016
.Dt TOOL 1
.Sh NAME
.Nm tool
.Nd tool which does something
.Sh SYNOPSYS
.Nm
.Ar argument
.Sh DESCRIPTION
.Bl -tag
.It Fl ab
Command ab.
.It Oo Ar n Oc Ns Dq Li dd
Command dd.
.It cd
Comman
> Carsten, can you post a complete self-contained example with .It arguments,
> .El etc.?
>
> Marcin
The not-minimum example would be
https://raw.githubusercontent.com/n-t-roff/vddiff/master/vddiff.1
If you view this with
nroff -mdoc vddiff.1 | less
You see the different indentation.
--Carste
Hello,
the problem in the document is the missing "-width" argument for .Bl.
>From groff_mdoc:
If a width is not specified for the tag list
type, every time .It is invoked, an attempt
is made to determine an appropriate width.
If the first argument to .It is a callable
macro, the default widt
Werner LEMBERG wrote:
> > Whilst reading the info pages on Groff I came upon the following
>
> What following? You have forgotten to add a quote.
He refers to doc/groff.texi line 5060. The wording is questionable indeed.
Reducing the paragraph to "Inches. One inch is equal to 2.54 cm." (i.
Hi,
the problem with this sentence is, that not everyone understands it as a joke.
Some may think it is meant literally and then wonder how one can write this
into a professional documentation. If all agree that this sentence should be
kept--okay, but there is a risk that from time to time on
Hello,
there had been patches supplied for -me from Bjarni Ingi Gislason which seem to
be reasonable. I'd like to have a look at them and maybe commit them. May
take a week or so (because of other tasks...). (Maybe the bug list should be
reviewed in general for things to be fixed before the
Hello,
the intended commits are done. If nobody else intends to do late changes ;) the
testing phase may start.
Carsten
> Ingo Schwarze hat am 24. April 2017 um 16:39 geschrieben:
>
> Assuming this is considered the right direction, how would one
> best implement, in doc.tmac-u and an-old.tmac, - == \- == U+002D
> for all devices?
Isn't it already done for UTF-8 in the files you mentioned?
Both contain:
.if '\*[
> "G. Branden Robinson" hat am 3. Mai 2017 um
> 01:02 geschrieben:
>
> The .itc request is a groff extension so an additional layer of
>
> .ie \(.g
>
> could be added.
Where do you want to add this--in the macro package? This would not be
necessary, since it is already groff's own package.
> "G. Branden Robinson" hat am 3. Mai 2017 um
> 17:30 geschrieben:
>
> Nope. By "private macro" I mean one defined and used only within one
> document.
A manpage is "one document". Or what do you refer to?
> Most \n(.g tests I've seen in man pages are to try to _achieve_
> portability, not br
> Carsten Kunze hat am 3. Mai 2017 um 21:37
> geschrieben:
>
> > E.g., ncurses uses these conditionals in many of its pages:
> >
> > .ie \n(.g .ds `` \(lq
> > .el .ds `` ``
> > .ie \n(.g .ds '' \(rq
> > .el .ds '' &
> John Gardner hat am 3. Mai 2017 um 21:55 geschrieben:
>
>
> Is there literally no way to identify when a modern (non-GNU) troff is
> being used?
General typesetting is something else. Heirloom has this kludge only for
manpages, neatroff (AFAIK not used for manpages) likely does not set .g.
> "G. Branden Robinson" hat am 3. Mai 2017 um
> 22:47 geschrieben:
>
> So ncurses should be gating on the definition of the glyph rather than
> on whether groff is the typesetter, right?
>
> .ie c \(lq .ds `` \(lq
> .el.ds `` ``
> .ie c \(rq .ds '' \(rq
> .el.ds '' ''
>
> What
> "James K. Lowden" hat am 4. Mai 2017 um 02:13
> geschrieben:
>
> Why not? ISTM we'd have better manpages if they weren't constrained to
> the rendering capability of a VT-100 terminal. For example, equations
> or pictures could augment the text, or replace some of it, when
> "printed".
I
> Ralph Corderoy hat am 6. Mai 2018 um 14:33
> geschrieben:
> I don't know if C++ has different semantics that mean choice of position
> is less flexible; I've just been talking about C.
C++ has the same rules as C regarding this. See e.g. Bjarne Stroustrup's "The
C++ Programming Language" Fo
> Ralph Corderoy hat am 6. Mai 2018 um 00:03
> geschrieben:
> Just to make certain we're arguing about the same thing, I'm talking C
> here, not C++. I've no idea whether C++ is the same or different in
> this respect, and don't wish to learn. :-)
As said the same applies for C++. "const int
Hello,
sorry for misusing the list for something completely off-topic (while it still
refers to the documentation of the UNIX system), but since there are many UNIX
experts on the list maybe someone has a definite answer.
Many system calls (e.g. close(2),
http://pubs.opengroup.org/onlinepubs/9
Hello Colin, Ingo and Ralph,
thank you for your elaborate and clarifying answers.
Sorry again for the off-topic noise.
Regards,
Carsten
You can invoke a macro with name xxx with
\*[xxx]
instead of
.xxx
You can even provide arguments for the macro in the form
\*[xxx arg1 ...]
as explained in
http://n-t-roff.github.io/heirloom/doctools/troff.pdf
§7.1. Does this answer your question or did you mean something else?
Hello,
in troff the Times Roman Bold \(sq is filled solid black. In groff there is no
difference between any Times Roman font.
Is there a way to get the standard (UNIX V7) behaviour of a solid filled bold
\(sq?
(I also checked heirloom troff, there bold \(sq is as expected.)
Or is there any o
Hi Ralph,
> > in troff the Times Roman Bold \(sq is filled solid black. In groff
> > there is no difference between any Times Roman font.
>
> Agreed. This does seem to be a bug in groff that needs formerly lodging
> somewhere?
Yes, it's somehow a groff "bug". Could also be named a bug that thi
> .bp
> .if o .bp
>
> it doesn't work reliably.
groff's MM macros .SK does something like
.bp
.if o \{\
\&
.bp \}
> >> .bp
> >> .if o .bp
> >>
> >> it doesn't work reliably.
> > groff's MM macros .SK does something like
> >
> > .bp
> > .if o \{\
> > \&
> > .bp \}
> >
> I'm using s.tmac, but your example helped me figure it out. Thanks!
.bp
.if o .bp +1
would be more simple. A new page is forced if there is
I'd like to use a diversion for printing the bibliography. There I'd like to
avoid page breaks inside items. I tried to use .ne or .bp, both did not work.
For .bp I found in the groff that it does not work inside (not-top-level)
diversions, but for .ne it is not mentioned there.
I wonder why .b
1 - 100 of 240 matches
Mail list logo
