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