cal space.
>
> If this is a bug and not a feature of MM (I am not
> sure which it is) than it can be rid of by replacing
> the second call to .sp with .SP in the ds@end macro:
>
> -.if \n[Ds] .sp \n[ds*i]u
> +.if \n[Ds] .SP \n[ds*i]u
It is a bug -- my AT&T MM macros
ndard top-of-page
processing (the mgm macros do not), which is more in keeping with my
original proposal to define .EOP with the standard end-of-page
processing. Does that change anyone's mind about the correct approach?
It makes sense to me to use the same approach for both.
--
Larry Jones
These pictures will remind us of more than we want to remember.
-- Calvin's Mom
ove it to get back the standard processing.
--
Larry Jones
I stand FIRM in my belief of what's right! I REFUSE to
compromise my principles! -- Calvin
[pg*odd-footer]
-. el .tl \\*[pg*even-footer]
-. ds hd*format \\g[P]
-. af P 0
-. ie (\\n[P]=1)&(\\n[N]=1) .tl \\*[pg*header]
-. el .tl \\*[pg*footer]
-. af P \\*[hd*format]
-. tl ''\\*[pg_type!\...@copy_type]]''
-.\}
+.EOP
.vpt 1
.ev
.\&quo
he backslash to defer the substitution
until the macro is invoked:
.de macro
.nr returnlocation \\n[nl]u \"Preserve location to return to.
--
Larry Jones
I must have been delirious from having so much fun. -- Calvin
d it would be replaced with the contents of that string. Is that a feature
> > of groff? I'd like to clear things up. Thanks.
>
> Doesn't work that way.
Yes, it does. And it "always" has. It was an undocumented feature (or
bug, if you prefer) of nroff/troff that gro
7;t already an existing equivalent to alias.
-Larry Jones
He's just jealous because I accomplish so much more than he does. -- Calvin
mented
registers that showed up in people's documents.
-Larry Jones
My dreams are getting way too literal. -- Calvin
.als :p ft*nr
to the mm macros like is done for other obscure number registers. As a
temporary workaround, you could also just add that to your document.
-Larry Jones
What's Santa's definition? How good do you have to be to qualify as good?
-- Calvin
in the right way
since it's schizophrenic where line endings are concerned. (And it
seems that some utilities insist on even when cygwin has been
configured to use by default.)
-Larry Jones
Santa's gonna skip this block for years. -- Calvin
l line
ending used in the repository and the local system's line ending (for
text files). "That CVS" is a Windows client and the Windows line ending
convention is . If you're pretending you're not really using
Windows and want a different line ending convention, then yo
Joel E. Denny writes:
>
> I've searched the web and Open Group for some roff or pic standards
> document. So far, I haven't found one. Does one exist?
<http://plan9.bell-labs.com/cm/cs/cstr/116.ps.gz>
-Larry Jones
I'm not a vegetarian! I'm a dessertarian. -- Calvin
spec itself uses upper- and lowercase for
readability, but HTML is case insensitive so , , , and
are all equally valid.
-Larry Jones
Nothing spoils fun like finding out it builds character. -- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
s meant to encourage
readability.
-Larry Jones
I've got to start listening to those quiet, nagging doubts. -- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
nctuation mark), which makes it moot.
-Larry Jones
This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
the solution is to use command -v.
Hardly -- "type" is probably more portable than "command -v" is.
Particularly since "command -v" is optional in the latest version of
POSIX (it's part of the User Portability Utilities option).
-Larry Jones
Thi
st a basic Bourne shell, which *did* have `type' as a builtin.
I stand corrected -- I just dug out my copy of the System V Interface
Definition and it does show "type" as an sh built-in as of SvR2. I
thought the SVID was the basis for the POSIX spec, but that seems to
have been lef
ware and widely portable) has the same problem in its test suite
(although not in the core product) and uses a shell function to solve
it. In fact, the test suite makes extensive use of shell functions. So
I suggest going with 4: it's inifinitely better than using "type" and it
seems t
e from #!/bin/sh to #!/bin/bash,
but it should probably be rewritten portably.
-Larry Jones
OK, there IS a middle ground, but it's for sissy weasels. -- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
are called *before*
the global environment pointer is set, so getenv() doesn't work in a
static constructor. Not being a C++ expert, I have no idea whether this
is a bug in my C++ implementation or a bug in groff.
-Larry Jones
I'm not a vegetari
he problem fixed than I
am in getting it installed.
-Larry Jones
Summer vacation started! I can't be sick! -- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
sr/local/share/groff/site-tmac:/usr/local/share/groff/1.19.2/tmac
top_builddir=/public/GNU/groff
top_srcdir=/public/GNU/groff
usermodmap=/thor/scjones/.Xmodmap
userresources=/thor/scjones/.Xresources
version=1.19
-Larry Jones
Whatever it is, it's driving me crazy! -- Calvin
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ke a make problem to me, it looks like something's not
working right in the font file search logic, but I don't know enough
about it to even know where to start trying to debug it. The last
version of groff I built on this platform was 1.15, so it's been a
while, but it
[meref.ps] Error 1
gmake[2]: Leaving directory `/public/GNU/groff/doc'
gmake[1]: *** [doc] Error 2
gmake[1]: Leaving directory `/public/GNU/groff'
gmake: *** [all] Error 2
There is a DESC file in /pubic/GNU/groff/font/devps, so I'm not sure why
it's not being fou
24 matches
Mail list logo
