118099SpstThis file describes various problems that have been encountered in
218099Spstcompiling, installing and running groff.  Suggestions for additions or
318099Spstother improvements to this file are welcome.
418099Spst
569626Sru----------------------------------------------------------------------
669626Sru
7104862Sru
8104862Sru
9104862SruGeneric Problems
10104862Sru================
11104862Sru
12104862Sru
13104862Sru
14151497Sru* Displaying a man page on a terminal with/without my favourite pager
15151497Sru  only gives garbage.
16151497Sru
17151497Srugroff by default now uses SGR escape sequences (`ANSI color') to
18151497Srucontrol the display attributes (bold, underlined, colour) on TTYs. 
19151497SruSome terminals (e.g. `kterm') don't understand SGR, and some pagers
20151497Sru(e.g. older versions of `less' or `less' without the -R option) don't
21151497Sruunderstand SGR either.  There are three solutions to fix this, in order
22151497Sruof preference; please read the grotty man page for more details.
23151497Sru
24151497SruThe fourth and probably best option is to update your terminal program
25151497Sruand pager to versions which can handle SGR.
26151497Sru
27151497Sru  1. Set the GROFF_NO_SGR environment variable.
28151497Sru
29151497Sru  2. Pass option -c to grotty.
30151497Sru
31151497Sru  3. Append the following fragment to the `troffrc' file:
32151497Sru
33151497Sru
34151497Sru--- start ---
35151497Sru.if n \{\
36151497Sru.  nr _C \n(.C
37151497Sru.  cp 0
38151497Sru.
39151497Sru.  \" The following code sets a top-of-page trap to disable grotty's TTY
40151497Sru.  \" mode.  Since neither \X nor .output can be used before the first
41151497Sru.  \" page has started, we must use a trap.  To make it work with troff's
42151497Sru.  \" -o option, we wait until the first printed page.
43151497Sru.
44151497Sru.  de sgr@dummy
45151497Sru.  .
46151497Sru.
47151497Sru.  rn wh wh@old
48151497Sru.
49151497Sru.  \" The stand-alone version.  If no other trap is set, we can safely
50151497Sru.  \" insert the truncated vertical space caused by the trap (if any).
51151497Sru.  \" Otherwise we assume that the document's main macro package takes
52151497Sru.  \" care of that.  As soon as the trap has been executed, it is removed.
53151497Sru.  de1 no@sgr
54151497Sru.    if \\n[.P] \{\
55151497Sru.      if (\\n[.t] == \\n[.p]) \{\
56151497Sru.        rn wh@old wh
57151497Sru.        rm no@sgr
58151497Sru.        wh 0
59151497Sru.        sp \\n[.trunc]
60151497Sru.        nop \X'tty: sgr 0'
61151497Sru.        sp -1
62151497Sru.    \}\}
63151497Sru.  .
64151497Sru.
65151497Sru.  wh@old 0 no@sgr
66151497Sru.
67151497Sru.  \" The piggyback version to be appended to macros planted with the
68151497Sru.  \" modified `wh' request.
69151497Sru.  de1 no@sgr1
70151497Sru.    if \\n[.P] \{\
71151497Sru.      rn wh@old wh
72151497Sru.      ds no@sgr1
73151497Sru.      nop \X'tty: sgr 0'
74151497Sru.      sp -1
75151497Sru.    \}
76151497Sru.  .
77151497Sru.
78151497Sru.  \" We redefine the `wh' request so that `no@sgr1' is appended to
79151497Sru.  \" the trap macro.
80151497Sru.  de1 wh
81151497Sru.    am1 \\$2 sgr@dummy
82151497Sru.      no@sgr1
83151497Sru.    sgr@dummy
84151497Sru.    wh@old \\$1 \\$2
85151497Sru.  .
86151497Sru.
87151497Sru.  cp \n[_C]
88151497Sru.\}
89151497Sru--- end ---
90151497Sru
91151497Sru----------------------------------------------------------------------
92151497Sru
93151497Sru* The UTF-8 output of grotty has strange characters for the minus, the
94151497Sru  hyphen, and the right quote.  Why?
95151497Sru
96151497SruThe used Unicode characters (U+2212 for the minus sign and U+2010 for
97151497Sruthe hyphen) are the correct ones, but many programs can't search them
98151497Sruproperly.  The same is true for the right quote (U+201D).  To map those
99151497Srucharacters back to the ASCII characters, insert the following code
100151497Srusnippet into the `troffrc' configuration file:
101151497Sru
102151497Sru.if '\*[.T]'utf8' \{\
103151497Sru.  char \- \N'45'
104151497Sru.  char  - \N'45'
105151497Sru.  char  ' \N'39'
106151497Sru.\}
107151497Sru
108151497Sru
109151497Sru----------------------------------------------------------------------
110151497Sru
11169626Sru* My document says that the current year is 19100, not 2000.
11269626Sru
11369626SruIn groff, as in traditional troff, the yr number register yields the
11469626Sruyear minus 1900.  Unfortunately, there is a longstanding bug in the
11569626SruTroff User's Manual <http://cm.bell-labs.com/cm/cs/cstr/54.ps.gz>,
11669626Sruwhich incorrectly claims that yr is the last two digits of the year.
11769626SruThis claim was never true of either Unix troff or of groff.
11869626Sru
11969626SruIf your text looks like this:
12069626Sru
12169626Sru	.\" Wrong:
12269626Sru	This document was formatted in 19\n(yr.
12369626Sru
12469626Sruyou can correct it as follows:
12569626Sru
12669626Sru	This document was formatted in \n[year].
12769626Sru
12869626Sruor, if you want to be portable to older troff versions, as follows:
12969626Sru
13069626Sru	.nr y4 1900+\n(yr
13169626Sru	This document was formatted in \n(y4.
13269626Sru
13369626Sru----------------------------------------------------------------------
13469626Sru
135104862Sru* groff can't handle my troff document.  It works fine with AT&T
136104862Sru  troff.
13718099Spst
138114402SruRead the section on incompatibilities in groff_diff(7).  Try using
139114402Sruthe -C option.  Alternatively there's the sed script
140114402Sru`tmac/fixmacros.sed' which will attempt to edit a file of macros so
141114402Sruthat it can be used with groff without the -C flag.
14218099Spst
14369626Sru----------------------------------------------------------------------
14455839Sasmodai
145104862Sru* gtroff doesn't understand lines like `.ce99' with no space between
146104862Sru  the name of the request or macro and the arguments.
14769626Sru
148104862Srugtroff requires a space between macro or request and its arguments
149104862Srubecause it allows the use of long names for macros and requests.  You
150104862Srucan use the -C option or the `cp' request to put gtroff into a
151104862Srucompatibility mode in which it is not possible to use long names for
152104862Srumacros but in which no space is required between macros and their
153104862Sruarguments.  The use of compatibility mode is strongly discouraged.
15455839Sasmodai
15569626Sru----------------------------------------------------------------------
15669626Sru
15769626Sru* groff -Tdvi produces dvi files that use fonts at weird
15869626Sru  magnifications.
15969626Sru
16018099SpstYes, it does.  You may need to compile fonts with Metafont at these
16169626Srumagnifications.  The CompileFonts script in the devdvi/generate
16275584Srudirectory may help you to do this.  (It will take a *long* time on
16375584Sruslow computers.)
16418099Spst
16569626Sru----------------------------------------------------------------------
16669626Sru
16718099Spst* Groff doesn't use the font names I'm used to.
16818099Spst
169114402SruUse the `ftr' request.  See groff_diff(7).
17018099Spst
17169626Sru----------------------------------------------------------------------
17269626Sru
173104862Sru* pic output is not centered horizontally; pictures sometimes run off
174104862Sru  the bottom of the page.
17518099Spst
176104862SruThe macro package you are using is not supplying appropriate
177104862Srudefinitions of PS and PE.  Give groff a -mpic option.
17818099Spst
17969626Sru----------------------------------------------------------------------
18018099Spst
18169626Sru* gpic doesn't accept the syntax `chop N M' for chopping both ends of
18269626Sru  a line.
18318099Spst
18418099SpstThe correct syntax is `chop N chop M'.
18518099Spst
18669626Sru----------------------------------------------------------------------
18718099Spst
18869626Sru* With gpic -t, when I print `line ->; box' using a dvi to ps program,
18969626Sru  the arrow head sticks through into the inside of the box.
19018099Spst
19169626SruThe dvi to ps program should be modified to set the line cap and line
19269626Srujoin parameters to 1 while printing tpic specials.
19369626Sru
19469626Sru----------------------------------------------------------------------
19569626Sru
19618099Spst* gtroff gives warnings about lines like
19718099Spst  .ev	\" a comment
19869626Sru  (with a tab after the .ev).
19918099Spst
20018099SpstA tab character cannot be used as a substitute for a space character
20118099Spst(except in one case: between a control character at the beginning of a
20218099Spstline and the name of a macro or request).  For example, in Unix troff
20369626Sru
20418099Spst  .ps	\" restore the previous point size
20569626Sru
20618099Spst(with a tab after the .ps) will NOT restore the previous point-size;
20718099Spstinstead it will be silently ignored.  Since this is very likely to be
20818099Spstan error, gtroff can give a warning about it.  If you want to align
20918099Spstcomments, you can do it like this:
21069626Sru
21118099Spst  .ev\"				\" a comment
21218099Spst
21369626Sru----------------------------------------------------------------------
21469626Sru
21518099Spst* I don't like the page headers and footers produced by groff -man.
21618099Spst
21718099SpstThere seem to be many different styles of page header and footer
21818099Spstproduced by different versions of the -man macros.  You will need to
219114402Sruput modified macros from tmac/an-old.tmac into man.local.  More
220114402Sruinformation is available in groff_man(7).
22169626Sru
22269626Sru----------------------------------------------------------------------
22369626Sru
224104862Sru* Where can I get grap?
225104862Sru
226104862SruTed Faber <faber@lunabase.org> has written a freely available grap:
227104862Sru
228104862Sru  http://www.lunabase.org/~faber/Vault/software/grap/
229104862Sru
230104862Sru----------------------------------------------------------------------
231104862Sru
232104862Sru* The \n(st and \n(sb registers don't seem to work.  I thought \w set
233104862Sru  them to the height and depth of its argument, but the registers
234104862Sru  always seem to be 0.
235104862Sru
236104862Sru\n(st and \n(sb aren't supposed to give the height and depth of the
237104862Srustring rather they give the minimum and maximum vertical displacement
238104862Sruof the baseline.  For example for \v'2u'\v'-3u', \n(st will be 1 and
239104862Sru\n(sb will be -2.  The height and depth of the string is available in
240104862Sruthe \n[rst] and \n[rsb] registers: these are groff extensions.
241104862Sru
242104862Sru----------------------------------------------------------------------
243104862Sru
24469626Sru* While formatting a manual page, groff complains about not being able
24569626Sru  to break lines.  The problem seems to be caused by a line like:
24618099Spst  .TP \w'label'+2
24718099Spst
24818099SpstThe -man documentation says that the default scale indicator for TP
24918099Spstmacro is `n'.  The groff -man macros implement this correctly, so that
25018099Spstthe argument will be evaluated as if it were
25169626Sru
25218099Spst  \w'label'n+2n
25369626Sru
25418099SpstThe Unix -man macros don't implement this correctly (probably because
25518099Spstit's hard to do in Unix troff); they just append `n' to the entire
25618099Spstargument, so that it will be evaluated as if it were
25769626Sru
25818099Spst  \w'label'u+2n
25969626Sru
26018099SpstThe solution is to fix the manual page:
26169626Sru
26218099Spst  .TP \w'label'u+2
26318099Spst
26469626Sru----------------------------------------------------------------------
26569626Sru
26618099Spst* I'm having problems formatting man pages produced by the perl
26769626Sru  wrapman script.
26818099Spst
26918099SpstSome versions of wrapman have a superfluous blank line before the .TH
27018099Spstline.  This must be deleted.  Then either use groff -C, or apply the
27118099Spstfollowing patch:
27218099Spst
27318099Spst*** wrapman.~2~	Sun Jan 19 12:10:24 1992
27418099Spst--- wrapman	Tue Aug 10 02:06:41 1993
27518099Spst***************
27618099Spst*** 35,41 ****
27718099Spst      $line1 .= <IN> if $line1 =~ /eval/;
27818099Spst      $line1 .= <IN> if $line1 =~ /argv/;
27918099Spst      $line2 = <IN>;
28018099Spst!     next if $line2 eq "'di';\n";
28118099Spst  
28218099Spst      # Pull the old switcheroo.
28318099Spst  
28418099Spst--- 35,41 ----
28518099Spst      $line1 .= <IN> if $line1 =~ /eval/;
28618099Spst      $line1 .= <IN> if $line1 =~ /argv/;
28718099Spst      $line2 = <IN>;
28818099Spst!     next if $line2 eq "'di ';\n" || $line2 eq "'di';\n";
28918099Spst  
29018099Spst      # Pull the old switcheroo.
29118099Spst  
29218099Spst***************
29318099Spst*** 49,56 ****
29418099Spst  
29518099Spst      print OUT $line1;
29618099Spst      print OUT <<EOF;
29718099Spst! 'di';
29818099Spst! 'ig00';
29918099Spst  #
30018099Spst  # $header
30118099Spst  #
30218099Spst--- 49,58 ----
30318099Spst  
30418099Spst      print OUT $line1;
30518099Spst      print OUT <<EOF;
30618099Spst! 'di ';
30718099Spst! 'ds 00 \\"';
30818099Spst! 'eo ';
30918099Spst! 'ig 00 ';
31018099Spst  #
31118099Spst  # $header
31218099Spst  #
31318099Spst***************
31418099Spst*** 72,85 ****
31518099Spst  
31618099Spst      # These next few lines are legal in both Perl and nroff.
31718099Spst  
31818099Spst! $null.00;                       # finish .ig
31918099Spst   
32018099Spst  'di           \\" finish diversion--previous line must be blank
32118099Spst  .nr nl 0-1    \\" fake up transition to first page again
32218099Spst  .nr % 0         \\" start at page 1
32318099Spst! '; __END__ ##### From here on it's a standard manual page #####
32418099Spst  .TH $PROG 1 "$month $mday, 19$year"
32518099Spst- .AT 3
32618099Spst  .SH NAME
32718099Spst  $prog \\- whatever
32818099Spst  .SH SYNOPSIS
32918099Spst--- 74,87 ----
33018099Spst  
33118099Spst      # These next few lines are legal in both Perl and nroff.
33218099Spst  
33318099Spst! $null.00 ;                      # finish .ig
33418099Spst! 'ec \\';
33518099Spst   
33618099Spst  'di           \\" finish diversion--previous line must be blank
33718099Spst  .nr nl 0-1    \\" fake up transition to first page again
33818099Spst  .nr % 0         \\" start at page 1
33918099Spst! .\\"'; __END__ ##### From here on it's a standard manual page #####
34018099Spst  .TH $PROG 1 "$month $mday, 19$year"
34118099Spst  .SH NAME
34218099Spst  $prog \\- whatever
34318099Spst  .SH SYNOPSIS
34418099Spst
34569626Sru----------------------------------------------------------------------
34618099Spst
34718099Spst* groff uses up an enormous amount of memory processing large files.
34869626Sru  I'm using 386BSD 0.1.
34918099Spst
35018099Spst386BSD includes an old version of g++, 1.39, which has a bug that
35118099Spstcauses a major memory leak in gtroff.  Apply the following fix to g++
35218099Spstand recompile groff:
35318099Spst
35418099Spst*** cplus-decl.c.~1~	Mon Aug  6 05:28:59 1990
35518099Spst--- cplus-decl.c	Wed Jun  5 08:55:04 1991
35618099Spst***************
35718099Spst*** 7951,7961 ****
35818099Spst  
35918099Spst        /* At the end, call delete if that's what's requested.  */
36018099Spst        if (TREE_GETS_DELETE (current_class_type))
36118099Spst  	exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node),
36218099Spst  				      get_identifier (OPERATOR_DELETE_FORMAT),
36318099Spst! 				      build_tree_list (NULL_TREE, integer_zero_node),
36418099Spst  				      NULL_TREE, LOOKUP_NORMAL);
36518099Spst        else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type))
36618099Spst  	exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0);
36718099Spst        else
36818099Spst  	exprstmt = 0;
36918099Spst--- 7951,7961 ----
37018099Spst  
37118099Spst        /* At the end, call delete if that's what's requested.  */
37218099Spst        if (TREE_GETS_DELETE (current_class_type))
37318099Spst  	exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node),
37418099Spst  				      get_identifier (OPERATOR_DELETE_FORMAT),
37518099Spst! 				      build_tree_list (NULL_TREE, current_class_decl),
37618099Spst  				      NULL_TREE, LOOKUP_NORMAL);
37718099Spst        else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type))
37818099Spst  	exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0);
37918099Spst        else
38018099Spst  	exprstmt = 0;
38118099Spst
382104862Sru
383104862Sru
384104862SruPrinting and Display Problems
385104862Sru=============================
386104862Sru
387104862Sru
388104862Sru
389104862Sru* I'm having problems including PostScript illustrations (EPS) using
390104862Sru  the PSPIC macro and/or \X'ps: import ...'.
391104862Sru
392104862SruA PostScript document must meet three requirements in order to be
393104862Sruincluded with the PSPIC macro: it must comply with the Adobe Document
394104862SruStructuring Conventions; it must contain a BoundingBox line; it must
395151497Srube `well-behaved'.  The BoundingBox line should be of the form:
396104862Sru
397104862Sru  %%BoundingBox: llx lly urx ury
398104862Sru
399104862Sruwhere llx, lly, urx, ury are the coordinates of the lower left x,
400104862Srulower left y, upper right x, upper right y of the bounding box of
401104862Srumarks on the page expressed as integers in the default PostScript
402104862Srucoordinate system (72 units per inch, origin at bottom left corner).
403104862Sru
404104862SruThe most convenient program to get the bounding box of a document is
405104862Sruthe `ps2epsi' script coming with GhostScript.
406104862Sru
407104862SruIf you can't use this program, another useful tactic is to print out
408104862Sruthe illustration by itself (you may need to add a `showpage' at the
409104862Sruend), and physically measure the bounding box.  For more detail on
410104862Sruthese requirements, read the specification of Encapsulated PostScript
411104862Sruformat.  (This is available from the Adobe file server; send a message
412104862Sruwith a body of `help' to ps-file-server@adobe.com.)
413104862Sru
414104862SruIf an EPS file to be included via \X'ps: import' does not start with
415151497Sru`%!PS-Adobe-...', gtroff will still include the file, but grops will
416104862Srunot add any fonts to the generated output file that are listed in the
417104862SruEPS file, even though the files are listed in the `download' file and
418104862Sruare available in the devps directory.
419104862Sru
42069626Sru----------------------------------------------------------------------
42169626Sru
422104862Sru* I've configured groff for A4 paper, but gtroff still seems to think
423104862Sru  that the length of a page (as returned by `\n(.p') is 11 inches.
42418099Spst
425114402SruThis is intentional.  The PAGE option during configuration is used
426114402Sruonly by grops.  For compatibility with ditroff, the default page
427114402Srulength in gtroff is always 11 inches.  The page length can be changed
428114402Sruwith the `pl' request.
42918099Spst
430114402SruA convenient way to set paper dimensions is to use the -dpaper option
431114402Sruof groff, together with proper -P options for the postprocessor
432114402Sru(overriding the default).  For example, use the following for PS
433114402Sruoutput on A4 paper in landscape orientation:
434114402Sru
435114402Sru  groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo.ps
436114402Sru
437114402SruSee groff_tmac(5) for more information.
438114402Sru
439104862Sru----------------------------------------------------------------------
44069626Sru
441114402Sru* When I print the output of groff -Tps, the output is always shifted
442114402Sru  up by about 0.7 inches; I'm using 8.5x11 inch paper.
443104862Sru
444114402SruMake sure that the paper size is `letter'.  See groff_tmac(5).
445104862Sru
44669626Sru----------------------------------------------------------------------
44769626Sru
448104862Sru* When I try to run gxditview, I get the error:
449104862Sru  Error: Widget viewport has zero width and/or height
450104862Sru
451104862SruThis error means you haven't correctly installed the application
452151497Srudefaults file, GXditview.ad; `make install' does this for you
453151497Sruautomatically, so either you didn't do `make install', or you haven't
454151497Srupassed a good `--appresdir=<DIR>' argument to groff's configure script.
455104862Sru
456151497SruSee the X(7) man page for information how and where application resource
457151497Srufiles have to be located.  Look for the XAPPLRESDIR and XUSERFILESEARCHPATH
458151497Sruenvironment variables.
459151497Sru
460104862Sru----------------------------------------------------------------------
461104862Sru
462104862Sru* When I preview documents using -TX75 or -TX100, the layout is not
463104862Sru  the same as when I print the document with -Tps: the line and page
464104862Sru  breaks come in different places.
465104862Sru
466151497SruUse `groff -X -Tps'.
467104862Sru
468104862Sru----------------------------------------------------------------------
469104862Sru
470104862Sru* When I try to print the output of groff -Tps, I get no output at all
471104862Sru  from the printer, and the log file shows the error
472104862Sru  %%[ error: undefined; offendingcommand: BP ]%%
473104862Sru  I'm using TranScript spooling software.
474104862Sru
475104862SruThis is a bug in the page reversal filter in early versions of
476104862SruTranScript.  Change the `broken' parameter in
477104862Sru/usr/local/lib/groff/font/devps/DESC to 7.
478104862Sru
479104862Sru----------------------------------------------------------------------
480104862Sru
481104862Sru* When I preview groff -Tps output using the Sun OpenWindows 2.0
482104862Sru  pageview program, all the pages are displayed on top of each other.
483104862Sru
484104862SruThis is a defect in pageview.  Change the `broken' parameter in
485104862Sru/usr/local/lib/groff/font/devps/DESC to 2.
486104862Sru
487104862Sru----------------------------------------------------------------------
488104862Sru
489104862Sru* With groff -TX75, -TX100 or -X, I can only view the first page.
490104862Sru
491104862SruThe left mouse button brings up a menu that allows you to view other
492104862Srupages.
493104862Sru
494104862Sru----------------------------------------------------------------------
495104862Sru
496104862Sru* When I print the output of groff -Tdvi, I just get a black dot in
497104862Sru  upper left corner.
498104862Sru
499104862SruSome dvi drivers (notably early versions of xtex) do not correctly
500104862Sruhandle dvi files that use a resolution different from that used by dvi
501104862Srufiles produced by TeX.  Try getting a more up to date driver.
502104862Sru
503104862Sru----------------------------------------------------------------------
504104862Sru
50518099Spst* How can I use groff with an old LaserJet printer that doesn't work
50669626Sru  with groff -Tlj4?
50718099Spst
50818099SpstYou have at least 3 options:
50918099Spst
51018099Spst- use groff -Tps with GNU Ghostscript;
51118099Spst
51218099Spst- use groff -Tdvi with a TeX .dvi to Laserjet driver;
51318099Spst
51418099Spst- use groff with the LaserJet driver in Chris Lewis' psroff package
51569626Sru  (available for ftp from:
51669626Sru  ftp.uunet.ca:/distrib/chris_lewis/psroff3.0pl17).
51718099Spst
51869626Sru----------------------------------------------------------------------
51969626Sru
52018099Spst* Groff seems to generate level 3 Postscript, but my printer is only a
52169626Sru  level 1 or 2 PostScript printer.
52218099Spst
523114402SruIn fact groff generates only level 2 PostScript (or rather level 1
524114402Sruwith some extensions; see grops(1) for more information how to disable
525114402Sruthem).  The `%!PS-Adobe-3.0' comment at the beginning of PostScript
526114402Sruoutput generated by groff indicates that the file conforms to
527114402Sruversion 3.0 of the Adobe Document Structuring Conventions.  The output
528114402Srugenerated by groff should be printable on any PostScript printer.
529114402SruProblems with groff output's not printing are most often caused by the
530114402Sruspooling system.
53118099Spst
532104862Sru
533104862Sru
534104862SruPlatform-Dependent Macro Problems
535104862Sru=================================
536104862Sru
537104862Sru
538104862Sru
539104862Sru* I get lots of errors when I use groff with the AT&T -mm macros.
540104862Sru
541104862SruUse the groff -mm macros.
542104862Sru
54369626Sru----------------------------------------------------------------------
54469626Sru
545104862Sru* groff produces wrapper macros for `ms' and friends which call the
546104862Sru  system's original macros.  Then, to get groff's ms macro package I
547104862Sru  have to use `-mgs' instead `-ms'.  Can I avoid this?
54818099Spst
549104862SruYes.  Configure and compile groff as usual, but install it with
55018099Spst
551104862Sru  make install tmac_wrap=""
552104862Sru
553104862SruThen no wrapper files are produced, and `-ms' will use groff's `ms'
554104862Srumacros.
555104862Sru
55669626Sru----------------------------------------------------------------------
55769626Sru
558104862Sru* I'm having problems formatting HP-UX 9.0 man pages with groff -man.
559104862Sru
560104862SruCopy HP's tmac.an into /usr/local/share/groff/site-tmac/an.tmac, and
561104862Srueither put `.cp 1' at the beginning or filter it (and any files it
562104862Sru.so's) through tmac/fixmacros.sed.
563104862Sru
564104862Sru----------------------------------------------------------------------
565104862Sru
566104862Sru* I get errors using the Unix -ms macros with groff -e -C.
567104862Sru
568104862SruApply this change:
569104862Sru
570104862Sru*** /usr/lib/ms/ms.eqn	Tue Apr 25 02:14:28 1989
571104862Sru--- ms.eqn	Sun Nov 11 10:33:59 1990
572104862Sru***************
573104862Sru*** 22,29 ****
574104862Sru  ..
575104862Sru  .	\" EN - end of a displayed equation
576104862Sru  .de EN
577104862Sru! .if !\\*(10 .br
578104862Sru  .di
579104862Sru  .rm EZ
580104862Sru  .nr ZN \\n(dn
581104862Sru  .if \\n(ZN>0 .if \\n(YE=0 .LP
582104862Sru--- 22,30 ----
583104862Sru  ..
584104862Sru  .	\" EN - end of a displayed equation
585104862Sru  .de EN
586104862Sru! .if \\n(.k>0 .br
587104862Sru  .di
588104862Sru+ .ds 10 \\*(EZ\\
589104862Sru  .rm EZ
590104862Sru  .nr ZN \\n(dn
591104862Sru  .if \\n(ZN>0 .if \\n(YE=0 .LP
592104862Sru
593104862Sru----------------------------------------------------------------------
594104862Sru
595104862Sru* I'm having problems formatting Ultrix man pages with groff -man.
596104862Sru
597104862SruThe Ultrix man pages use a number of non-standard extensions to the
598104862SruUnix man macros.  One solution is to use the Ultrix -man macros with
599104862Srugroff.  Copy /usr/lib/tmac/tmac.an to
600104862Sru/usr/local/share/groff/site-tmac/an.tmac and apply the following patch
601104862Sru(from Frank Wortner):
602104862Sru
603104862Sru*** /usr/local/lib/groff/tmac/tmac.an     Wed Sep  9 12:29:28 1992
604104862Sru--- /usr/lib/tmac/tmac.an       Fri Jul 24 19:58:19 1992
605104862Sru***************
606104862Sru*** 489,495 ****
607104862Sru  .     \" make special case of shift out of italic
608104862Sru  .de }S
609104862Sru  .ds ]F
610104862Sru! .if \\$12 .if !\\$5 .ds ]F \^
611104862Sru  .ie !\\$4 .}S \\$2 \\$1 "\\$3\f\\$1\\$4\\*(]F" "\\$5" "\\$6" "\\$7" "\\$8" "\\$9"
612104862Sru  .el \\$3
613104862Sru  .}f
614104862Sru--- 489,495 ----
615104862Sru  .     \" make special case of shift out of italic
616104862Sru  .de }S
617104862Sru  .ds ]F
618104862Sru! .if \\$12 .if !\\$5 .ds ]F\^
619104862Sru  .ie !\\$4 .}S \\$2 \\$1 "\\$3\f\\$1\\$4\\*(]F" "\\$5" "\\$6" "\\$7" "\\$8" "\\$9"
620104862Sru  .el \\$3
621104862Sru  .}f
622104862Sru
623104862SruAnother possible solution is to install tmac/man.ultrix as
624104862Sru/usr/local/share/groff/site-tmac/man.local.
625104862Sru
626104862Sru----------------------------------------------------------------------
627104862Sru
62818099Spst* On an SGI system, how can I make the man command use groff?
62918099Spst
63018099SpstFrom David Hinds <dhinds@allegro.stanford.edu> (some of these steps
63118099Spstare unnecessary if you install with the `g' Makefile variable defined
63218099Spstas empty):
63318099Spst
63418099SpstCreate a script called 'eqn':
63518099Spst
636151497Sru > #! /bin/sh
63718099Spst > if [ ${1:-""} = /usr/pub/eqnchar ] ; then shift ; fi
63818099Spst > geqn $*
63918099Spst
64018099Spstand a script called 'neqn':
64118099Spst
642151497Sru > #! /bin/sh
64318099Spst > if [ ${1:-""} = /usr/pub/eqnchar ] ; then shift ; fi
64418099Spst > geqn -Tascii $*
64518099Spst
64618099Spstand do:
64718099Spst
64818099Spst > ln -s gnroff nroff
64918099Spst
65018099Spstand edit the end of the gnroff script to be:
65118099Spst
65218099Spst > rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'`
65318099Spst > exec groff -Wall -mtty-char $T $opts $rest
65418099Spst
65518099SpstTo get PostScript output from 'man -t', you also need to create a
65618099Spst'psroff' script similar to 'nroff'.  Here are the context diffs:
65718099Spst
65818099Spst*** /usr/local/bin/nroff        Sat Feb 13 15:51:09 1993
65918099Spst--- /usr/local/bin/psroff       Sat Feb 13 17:45:46 1993
66018099Spst***************
66118099Spst*** 1,8 ****
662151497Sru  #! /bin/sh
66318099Spst! # Emulate nroff with groff.
66418099Spst
66518099Spst  prog="$0"
66618099Spst! T=-Tascii
66718099Spst  opts=
66818099Spst
66918099Spst  for i
67018099Spst--- 1,8 ----
671151497Sru  #! /bin/sh
67218099Spst! # Emulate psroff with groff.
67318099Spst
67418099Spst  prog="$0"
67518099Spst! T=-Tps
67618099Spst  opts=
67718099Spst
67818099Spst  for i
67918099Spst***************
68018099Spst*** 25,30 ****
68118099Spst--- 25,33 ----
68218099Spst        -Tascii|-Tlatin1)
68318099Spst                T=$1
68418099Spst                ;;
68518099Spst+       -t)
68618099Spst+               # ignore -- default is send to stdout
68718099Spst+               ;;
68818099Spst        -T*)
68918099Spst                # ignore other devices
69018099Spst                ;;
69118099Spst***************
69218099Spst*** 49,53 ****
69318099Spst  rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'`
69418099Spst
69518099Spst  # This shell script is intended for use with man, so warnings are
69618099Spst  # probably not wanted.  Also load nroff-style character definitions.
69718099Spst! exec groff -Wall -mtty-char $T $opts $rest
69818099Spst--- 52,56 ----
69918099Spst  rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'`
70018099Spst
70118099Spst  # This shell script is intended for use with man, so warnings are
70218099Spst! # probably not wanted.
70318099Spst! exec groff -Wall $T $opts $rest
704104862Sru
705104862Sru
706104862Sru
707104862SruCompilation Problems
708104862Sru====================
709104862Sru
710104862Sru
711104862Sru
712104862Sru* Compilation dies with
713104862Sru
714104862Sru    y.tab.c: In function `int yyparse()':
715104862Sru    y.tab.c: `size_t' undeclared in namespace `std'
716104862Sru
717114402Sru* bison reports conflicts (either on stderr or in the `pic.output'
718114402Sru  file) while processing `pic.y', and the produced pic binary doesn't
719114402Sru  work at all.
720104862Sru
721114402SruYou need bison version 1.875b or greater.  Alternatively, use yacc or
722114402Srubyacc.
723114402Sru
724104862Sru----------------------------------------------------------------------
725104862Sru
726104862Sru* There are many empty `Makefile.dep' files.  Is this a bug?
727104862Sru
728104862SruNo.  Real dependency files are created with a `make depend' call.
729104862Sru
730104862Sru----------------------------------------------------------------------
731104862Sru
732104862Sru* On HP-UX, the compiler complains about missing symbol `alloca'.
733104862Sru
734104862SruSay
735104862Sru
736104862Sru  export LDFLAGS=-lPW
737104862Sru
738104862Srubefore starting the configure script.
739104862Sru
740104862Sru----------------------------------------------------------------------
741104862Sru
742104862Sru* The configure script fails on OS/390 (z/OS) Unix.
743104862Sru
744104862Sru[This has been fixed in z/OS V1R3 (aka OS/390 R13).]
745104862Sru
746104862SruThere is a bug in the Language Environment (LE) whereby the test
747104862Sruprogram for static destructors fails.  You will see the message
748104862Sru`configure: error: a working C++ compiler is required'
749104862Sru
750104862SruApplying PTF UQ42006 is supposed to fix this, but the test program is
751104862Srustill returning the wrong value (1).  To work around this problem, you
752104862Srucan comment out the following in the configure script (near line 2029).
753104862SruThis will effectively bypass the test (static constructors and
754104862Srudestructors do actually work properly):
755104862Sru
756104862Sru#if { (eval echo "$as_me:2029: \"$ac_link\"") >&5
757104862Sru#  (eval $ac_link) 2>&5
758104862Sru#  ac_status=$?
759104862Sru#  echo "$as_me:2032: \$? = $ac_status" >&5
760104862Sru#  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
761104862Sru#  { (eval echo "$as_me:2034: \"$ac_try\"") >&5
762104862Sru#  (eval $ac_try) 2>&5
763104862Sru#  ac_status=$?
764104862Sru#  echo "$as_me:2037: \$? = $ac_status" >&5
765104862Sru#  (exit $ac_status); }; }; then
766104862Sru#  echo "$as_me:2039: result: yes" >&5
767104862Sru#echo "${ECHO_T}yes" >&6
768104862Sru#else
769104862Sru#  echo "$as_me: program exited with status $ac_status" >&5
770104862Sru#echo "$as_me: failed program was:" >&5
771104862Sru#cat conftest.$ac_ext >&5
772104862Sru#echo "$as_me:2045: result: no" >&5
773104862Sru#echo "${ECHO_T}no" >&6;{ { echo "$as_me:2046: error: a working C++ compiler is required" >&5
774104862Sru#echo "$as_me: error: a working C++ compiler is required" >&2;}
775104862Sru#   { (exit 1); exit 1; }; }
776104862Sru#fi
777104862Sru
778104862Sru----------------------------------------------------------------------
779104862Sru
780104862Sru* I get errors when I try to compile groff with DEC C++.
781104862Sru
782104862SruFix the declaration of write() in <unistd.h> so that the second
783104862Sruargument is a const char *.  Fix the declaration of open() in
784104862Sru<sys/file.h> so that the first argument is a const char *.
785104862Sru
786104862Sru----------------------------------------------------------------------
787104862Sru
788104862Sru* On a host using Unix make (e.g. Solaris), if you are compiling for
789104862Sru  multiple architectures by building in a subdirectory, the make stops
790104862Sru  with a message like this:
791104862Sru
792104862Sru    make: Fatal error: Don't know how to make target `assert.o'
793104862Sru
794104862Sru  or like this:
795104862Sru
796104862Sru    make: Fatal error: Can't find /u/src/groff/src/include/Makefile.sub': No such file or directory
797104862Sru
798104862SruThis occurs because GNU make and Unix make handle VPATH differently,
799104862Sruand the groff build relies on GNU make's VPATH handling.
800104862Sru
801151497SruUse GNU make <http://www.gnu.org/software/make/> to work around this.
802151497SruIn Solaris 8 and 9, GNU make is on the Software Companion CD in
803151497Srupackage SFWgmake and is installed as /opt/sfw/bin/gmake.  Prebuilt
804151497Sruversions of GNU make for Solaris are also available from
805151497Srusunfreeware.com.
806104862Sru
807104862Sru----------------------------------------------------------------------
808104862Sru
809151497Sru* On Ultrix, the make program stops with the message
810104862Sru
811104862Sru    *** Error code 1
812104862Sru
813104862Sru    Stop.
814104862Sru
815104862Sru  for no apparent reason.
816104862Sru
817104862SruUse GNU make.
818104862Sru
819104862Sru----------------------------------------------------------------------
820104862Sru
821104862Sru* I'm having problems compiling groff on 386BSD 0.1.
822104862Sru
823104862SruIf you're using ash as /bin/sh, you'll need the following patch.
824104862Sru
825104862Sru*** gendef.sh.org	Sun Jun 30 13:30:36 1991
826104862Sru--- gendef.sh	Sun Feb 28 10:23:49 1993
827104862Sru***************
828104862Sru*** 3,9 ****
829104862Sru  file=$1
830104862Sru  shift
831104862Sru  
832104862Sru! defs="#define $1"
833104862Sru  shift
834104862Sru  for def
835104862Sru  do
836104862Sru--- 3,10 ----
837104862Sru  file=$1
838104862Sru  shift
839104862Sru  
840104862Sru! x=$1
841104862Sru! defs="#define $x"
842104862Sru  shift
843104862Sru  for def
844104862Sru  do
845104862Sru
846104862SruYou'll also need to change dirnamemax.c so that it doesn't use
847104862Srupathconf().
848104862Sru
849104862Sru----------------------------------------------------------------------
850104862Sru
851104862Sru* While compiling on Xenix, ranlib libgroff.a fails.
852104862Sru
853104862SruThe system ranlib can't handle externals longer than 40 characters.
854104862SruUse the ranlib included in demon.co.uk:/pub/xenix/g++-1.40.3a.v1
855104862Sruinstead.
856104862Sru
857104862Sru----------------------------------------------------------------------
858104862Sru
859104862Sru* I get errors when I try to compile groff with Sun C++ version 3 or
860104862Sru  earlier.
861104862Sru
862104862SruGroff requires header files that are moderately compatible with AT&T
863104862SruC++ and ANSI C.  With some versions of Sun C++, the supplied header
864104862Srufiles need some of the following changes to meet this requirement:
865104862Sru<string.h> must declare the mem* functions, (just add `#include
866104862Sru<memory.h>' to <string.h>); the first argument to fopen and freopen
867104862Srushould be declared as `const char *'; the first argument to fread
868104862Srushould be declared as `void *'; the first argument to fwrite should be
869104862Srudeclared as `const void *'; malloc should be declared to return
870104862Sru`void *'; in <alloca.h>, the declaration `extern "C" { void
871104862Sru*__builtin_alloca(int); }' should be added; in <sys/signal.h> the
872104862Srureturn type and the second argument type of signal() should be changed
873104862Sruto be `void (*)(int)'.
874104862Sru
875104862SruYou can either change them in place, or copy them to some other
876104862Srudirectory and include that directory with a -I option.
877104862Sru
878104862Sru----------------------------------------------------------------------
879104862Sru
880151497Sru* I get errors when I try to compile groff with Forte Development 6
881151497Sru  or 6u1, or Sun C++ version 5.0 through 5.2.
882104862Sru
883151497SruThis is a known problem; see Sun bug #4301919.  See Sun patches
884151497Sru109482, 109490, 109508, and 109509 for fixes.
885104862Sru
886104862Sru----------------------------------------------------------------------
887104862Sru
888151497Sru* I get warnings from the Sun linker while using gcc 3.4.0:
889151497Sru
890151497Sru  ld: warning: relocation error: R_SPARC_UA32:
891151497Sru      file groff/src/libs/libgroff/libgroff.a(getopt.o): symbol optarg:
892151497Sru      external symbolic relocation against non-allocatable
893151497Sru      section .debug_info; cannot be processed at runtime:
894151497Sru      relocation ignored
895151497Sru
896151497SruThis seems to be a known problem (Sun bugs #4910101 and #4910810,
897151497Srufiled in September 2003; gcc bug #15599, filed May 2004) without a
898151497Srupublic fix as of this writing.  A work-around is to use option
899151497Sru`-gstabs+' instead of `-g' (and a high probability that the output is
900151497Sruonly debuggable with gdb but not with Sun's debuggers).
901151497Sru
902151497Sru----------------------------------------------------------------------
903151497Sru
904104862Sru* I get lots of `numeric overflow' error messages whenever I run
905104862Sru  groff; I compiled groff with AT&T C++ 2.0 with an ANSI C compiler.
906104862Sru
907104862SruMake sure -DCFRONT_ANSI_BUG is included in DEFINES in the top-level
908104862SruMakefile.  If that doesn't solve the problem, define INT_MIN as
909104862Sru-INT_MAX in libgroff/lib.h.
910114402Sru
911114402Sru----------------------------------------------------------------------
912114402Sru
913151497Sru* When compiling on MacOS X, groff compiles but does not run well,
914151497Sru  especially `eqn', causing many `can't break line' messages.
915114402Sru
916114402SruUse  ./configure CXX=g++2  then make as usual.
917