PROBLEMS revision 104862
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 1469626Sru* My document says that the current year is 19100, not 2000. 1569626Sru 1669626SruIn groff, as in traditional troff, the yr number register yields the 1769626Sruyear minus 1900. Unfortunately, there is a longstanding bug in the 1869626SruTroff User's Manual <http://cm.bell-labs.com/cm/cs/cstr/54.ps.gz>, 1969626Sruwhich incorrectly claims that yr is the last two digits of the year. 2069626SruThis claim was never true of either Unix troff or of groff. 2169626Sru 2269626SruIf your text looks like this: 2369626Sru 2469626Sru .\" Wrong: 2569626Sru This document was formatted in 19\n(yr. 2669626Sru 2769626Sruyou can correct it as follows: 2869626Sru 2969626Sru This document was formatted in \n[year]. 3069626Sru 3169626Sruor, if you want to be portable to older troff versions, as follows: 3269626Sru 3369626Sru .nr y4 1900+\n(yr 3469626Sru This document was formatted in \n(y4. 3569626Sru 3669626Sru---------------------------------------------------------------------- 3769626Sru 38104862Sru* groff can't handle my troff document. It works fine with AT&T 39104862Sru troff. 4018099Spst 41104862SruRead the section on incompatibilities in gtroff(1). Try using the -C 42104862Sruoption. Alternatively there's the sed script `tmac/fixmacros.sed' 43104862Sruwhich will attempt to edit a file of macros so that it can be used 44104862Sruwith groff without the -C flag. 4518099Spst 4669626Sru---------------------------------------------------------------------- 4755839Sasmodai 48104862Sru* gtroff doesn't understand lines like `.ce99' with no space between 49104862Sru the name of the request or macro and the arguments. 5069626Sru 51104862Srugtroff requires a space between macro or request and its arguments 52104862Srubecause it allows the use of long names for macros and requests. You 53104862Srucan use the -C option or the `cp' request to put gtroff into a 54104862Srucompatibility mode in which it is not possible to use long names for 55104862Srumacros but in which no space is required between macros and their 56104862Sruarguments. The use of compatibility mode is strongly discouraged. 5755839Sasmodai 5869626Sru---------------------------------------------------------------------- 5969626Sru 6069626Sru* groff -Tdvi produces dvi files that use fonts at weird 6169626Sru magnifications. 6269626Sru 6318099SpstYes, it does. You may need to compile fonts with Metafont at these 6469626Srumagnifications. The CompileFonts script in the devdvi/generate 6575584Srudirectory may help you to do this. (It will take a *long* time on 6675584Sruslow computers.) 6718099Spst 6869626Sru---------------------------------------------------------------------- 6969626Sru 7018099Spst* Groff doesn't use the font names I'm used to. 7118099Spst 7275584SruUse the `ftr' request. See (g)troff(1). 7318099Spst 7469626Sru---------------------------------------------------------------------- 7569626Sru 76104862Sru* pic output is not centered horizontally; pictures sometimes run off 77104862Sru the bottom of the page. 7818099Spst 79104862SruThe macro package you are using is not supplying appropriate 80104862Srudefinitions of PS and PE. Give groff a -mpic option. 8118099Spst 8269626Sru---------------------------------------------------------------------- 8318099Spst 8469626Sru* gpic doesn't accept the syntax `chop N M' for chopping both ends of 8569626Sru a line. 8618099Spst 8718099SpstThe correct syntax is `chop N chop M'. 8818099Spst 8969626Sru---------------------------------------------------------------------- 9018099Spst 9169626Sru* With gpic -t, when I print `line ->; box' using a dvi to ps program, 9269626Sru the arrow head sticks through into the inside of the box. 9318099Spst 9469626SruThe dvi to ps program should be modified to set the line cap and line 9569626Srujoin parameters to 1 while printing tpic specials. 9669626Sru 9769626Sru---------------------------------------------------------------------- 9869626Sru 9918099Spst* gtroff gives warnings about lines like 10018099Spst .ev \" a comment 10169626Sru (with a tab after the .ev). 10218099Spst 10318099SpstA tab character cannot be used as a substitute for a space character 10418099Spst(except in one case: between a control character at the beginning of a 10518099Spstline and the name of a macro or request). For example, in Unix troff 10669626Sru 10718099Spst .ps \" restore the previous point size 10869626Sru 10918099Spst(with a tab after the .ps) will NOT restore the previous point-size; 11018099Spstinstead it will be silently ignored. Since this is very likely to be 11118099Spstan error, gtroff can give a warning about it. If you want to align 11218099Spstcomments, you can do it like this: 11369626Sru 11418099Spst .ev\" \" a comment 11518099Spst 11669626Sru---------------------------------------------------------------------- 11769626Sru 11818099Spst* I don't like the page headers and footers produced by groff -man. 11918099Spst 12018099SpstThere seem to be many different styles of page header and footer 12118099Spstproduced by different versions of the -man macros. You will need to 12275584Srumodify tmac/an-old.tmac to suit your personal taste. For example, if 12318099Spstyou want the center of the page header to say 12469626Sru 12555839Sasmodai System Programmer's Manual 12669626Sru 12718099Spstyou will need to change the line 12869626Sru 12955839Sasmodai .el .ds an-extra3 \"System Programmer's Manual 13069626Sru 13118099Spstto 13269626Sru 13355839Sasmodai .el .ds an-extra3 System Programmer's Manual 13418099Spst 13569626Sru---------------------------------------------------------------------- 13669626Sru 137104862Sru* Where can I get grap? 138104862Sru 139104862SruTed Faber <faber@lunabase.org> has written a freely available grap: 140104862Sru 141104862Sru http://www.lunabase.org/~faber/Vault/software/grap/ 142104862Sru 143104862Sru---------------------------------------------------------------------- 144104862Sru 145104862Sru* The \n(st and \n(sb registers don't seem to work. I thought \w set 146104862Sru them to the height and depth of its argument, but the registers 147104862Sru always seem to be 0. 148104862Sru 149104862Sru\n(st and \n(sb aren't supposed to give the height and depth of the 150104862Srustring rather they give the minimum and maximum vertical displacement 151104862Sruof the baseline. For example for \v'2u'\v'-3u', \n(st will be 1 and 152104862Sru\n(sb will be -2. The height and depth of the string is available in 153104862Sruthe \n[rst] and \n[rsb] registers: these are groff extensions. 154104862Sru 155104862Sru---------------------------------------------------------------------- 156104862Sru 15769626Sru* While formatting a manual page, groff complains about not being able 15869626Sru to break lines. The problem seems to be caused by a line like: 15918099Spst .TP \w'label'+2 16018099Spst 16118099SpstThe -man documentation says that the default scale indicator for TP 16218099Spstmacro is `n'. The groff -man macros implement this correctly, so that 16318099Spstthe argument will be evaluated as if it were 16469626Sru 16518099Spst \w'label'n+2n 16669626Sru 16718099SpstThe Unix -man macros don't implement this correctly (probably because 16818099Spstit's hard to do in Unix troff); they just append `n' to the entire 16918099Spstargument, so that it will be evaluated as if it were 17069626Sru 17118099Spst \w'label'u+2n 17269626Sru 17318099SpstThe solution is to fix the manual page: 17469626Sru 17518099Spst .TP \w'label'u+2 17618099Spst 17769626Sru---------------------------------------------------------------------- 17869626Sru 17918099Spst* I'm having problems formatting man pages produced by the perl 18069626Sru wrapman script. 18118099Spst 18218099SpstSome versions of wrapman have a superfluous blank line before the .TH 18318099Spstline. This must be deleted. Then either use groff -C, or apply the 18418099Spstfollowing patch: 18518099Spst 18618099Spst*** wrapman.~2~ Sun Jan 19 12:10:24 1992 18718099Spst--- wrapman Tue Aug 10 02:06:41 1993 18818099Spst*************** 18918099Spst*** 35,41 **** 19018099Spst $line1 .= <IN> if $line1 =~ /eval/; 19118099Spst $line1 .= <IN> if $line1 =~ /argv/; 19218099Spst $line2 = <IN>; 19318099Spst! next if $line2 eq "'di';\n"; 19418099Spst 19518099Spst # Pull the old switcheroo. 19618099Spst 19718099Spst--- 35,41 ---- 19818099Spst $line1 .= <IN> if $line1 =~ /eval/; 19918099Spst $line1 .= <IN> if $line1 =~ /argv/; 20018099Spst $line2 = <IN>; 20118099Spst! next if $line2 eq "'di ';\n" || $line2 eq "'di';\n"; 20218099Spst 20318099Spst # Pull the old switcheroo. 20418099Spst 20518099Spst*************** 20618099Spst*** 49,56 **** 20718099Spst 20818099Spst print OUT $line1; 20918099Spst print OUT <<EOF; 21018099Spst! 'di'; 21118099Spst! 'ig00'; 21218099Spst # 21318099Spst # $header 21418099Spst # 21518099Spst--- 49,58 ---- 21618099Spst 21718099Spst print OUT $line1; 21818099Spst print OUT <<EOF; 21918099Spst! 'di '; 22018099Spst! 'ds 00 \\"'; 22118099Spst! 'eo '; 22218099Spst! 'ig 00 '; 22318099Spst # 22418099Spst # $header 22518099Spst # 22618099Spst*************** 22718099Spst*** 72,85 **** 22818099Spst 22918099Spst # These next few lines are legal in both Perl and nroff. 23018099Spst 23118099Spst! $null.00; # finish .ig 23218099Spst 23318099Spst 'di \\" finish diversion--previous line must be blank 23418099Spst .nr nl 0-1 \\" fake up transition to first page again 23518099Spst .nr % 0 \\" start at page 1 23618099Spst! '; __END__ ##### From here on it's a standard manual page ##### 23718099Spst .TH $PROG 1 "$month $mday, 19$year" 23818099Spst- .AT 3 23918099Spst .SH NAME 24018099Spst $prog \\- whatever 24118099Spst .SH SYNOPSIS 24218099Spst--- 74,87 ---- 24318099Spst 24418099Spst # These next few lines are legal in both Perl and nroff. 24518099Spst 24618099Spst! $null.00 ; # finish .ig 24718099Spst! 'ec \\'; 24818099Spst 24918099Spst 'di \\" finish diversion--previous line must be blank 25018099Spst .nr nl 0-1 \\" fake up transition to first page again 25118099Spst .nr % 0 \\" start at page 1 25218099Spst! .\\"'; __END__ ##### From here on it's a standard manual page ##### 25318099Spst .TH $PROG 1 "$month $mday, 19$year" 25418099Spst .SH NAME 25518099Spst $prog \\- whatever 25618099Spst .SH SYNOPSIS 25718099Spst 25869626Sru---------------------------------------------------------------------- 25918099Spst 26018099Spst* groff uses up an enormous amount of memory processing large files. 26169626Sru I'm using 386BSD 0.1. 26218099Spst 26318099Spst386BSD includes an old version of g++, 1.39, which has a bug that 26418099Spstcauses a major memory leak in gtroff. Apply the following fix to g++ 26518099Spstand recompile groff: 26618099Spst 26718099Spst*** cplus-decl.c.~1~ Mon Aug 6 05:28:59 1990 26818099Spst--- cplus-decl.c Wed Jun 5 08:55:04 1991 26918099Spst*************** 27018099Spst*** 7951,7961 **** 27118099Spst 27218099Spst /* At the end, call delete if that's what's requested. */ 27318099Spst if (TREE_GETS_DELETE (current_class_type)) 27418099Spst exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node), 27518099Spst get_identifier (OPERATOR_DELETE_FORMAT), 27618099Spst! build_tree_list (NULL_TREE, integer_zero_node), 27718099Spst NULL_TREE, LOOKUP_NORMAL); 27818099Spst else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type)) 27918099Spst exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0); 28018099Spst else 28118099Spst exprstmt = 0; 28218099Spst--- 7951,7961 ---- 28318099Spst 28418099Spst /* At the end, call delete if that's what's requested. */ 28518099Spst if (TREE_GETS_DELETE (current_class_type)) 28618099Spst exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node), 28718099Spst get_identifier (OPERATOR_DELETE_FORMAT), 28818099Spst! build_tree_list (NULL_TREE, current_class_decl), 28918099Spst NULL_TREE, LOOKUP_NORMAL); 29018099Spst else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type)) 29118099Spst exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0); 29218099Spst else 29318099Spst exprstmt = 0; 29418099Spst 295104862Sru 296104862Sru 297104862SruPrinting and Display Problems 298104862Sru============================= 299104862Sru 300104862Sru 301104862Sru 302104862Sru* I'm having problems including PostScript illustrations (EPS) using 303104862Sru the PSPIC macro and/or \X'ps: import ...'. 304104862Sru 305104862SruA PostScript document must meet three requirements in order to be 306104862Sruincluded with the PSPIC macro: it must comply with the Adobe Document 307104862SruStructuring Conventions; it must contain a BoundingBox line; it must 308104862Srube ``well-behaved''. The BoundingBox line should be of the form: 309104862Sru 310104862Sru %%BoundingBox: llx lly urx ury 311104862Sru 312104862Sruwhere llx, lly, urx, ury are the coordinates of the lower left x, 313104862Srulower left y, upper right x, upper right y of the bounding box of 314104862Srumarks on the page expressed as integers in the default PostScript 315104862Srucoordinate system (72 units per inch, origin at bottom left corner). 316104862Sru 317104862SruThe most convenient program to get the bounding box of a document is 318104862Sruthe `ps2epsi' script coming with GhostScript. 319104862Sru 320104862SruIf you can't use this program, another useful tactic is to print out 321104862Sruthe illustration by itself (you may need to add a `showpage' at the 322104862Sruend), and physically measure the bounding box. For more detail on 323104862Sruthese requirements, read the specification of Encapsulated PostScript 324104862Sruformat. (This is available from the Adobe file server; send a message 325104862Sruwith a body of `help' to ps-file-server@adobe.com.) 326104862Sru 327104862SruIf an EPS file to be included via \X'ps: import' does not start with 328104862Sru%!PS-Adobe-...', gtroff will still include the file, but grops will 329104862Srunot add any fonts to the generated output file that are listed in the 330104862SruEPS file, even though the files are listed in the `download' file and 331104862Sruare available in the devps directory. 332104862Sru 33369626Sru---------------------------------------------------------------------- 33469626Sru 335104862Sru* I've configured groff for A4 paper, but gtroff still seems to think 336104862Sru that the length of a page (as returned by `\n(.p') is 11 inches. 33718099Spst 338104862SruThis is intentional. The PAGE option is used only by grops. For 339104862Srucompatibility with ditroff, the default page length in gtroff is 340104862Srualways 11 inches. The page length can be changed with the `pl' 341104862Srurequest. 34218099Spst 343104862Sru---------------------------------------------------------------------- 34469626Sru 345104862Sru* When I print the output groff -Tps, the output is always shifted up 346104862Sru by about 0.7 inches; I'm using 8.5x11 inch paper. 347104862Sru 348104862SruMake sure that PAGE is defined to be `letter' in the top-level 349104862SruMakefile. 350104862Sru 35169626Sru---------------------------------------------------------------------- 35269626Sru 353104862Sru* When I try to run gxditview, I get the error: 354104862Sru Error: Widget viewport has zero width and/or height 355104862Sru 356104862SruThis error means you haven't correctly installed the application 357104862Srudefaults file, GXditview.ad; ``make install'' does this for you 358104862Sruautomatically, so either you didn't do ``make install'', or you don't 359104862Sruhave imake configured correctly. 360104862Sru 361104862Sru---------------------------------------------------------------------- 362104862Sru 363104862Sru* When I preview documents using -TX75 or -TX100, the layout is not 364104862Sru the same as when I print the document with -Tps: the line and page 365104862Sru breaks come in different places. 366104862Sru 367104862SruUse groff -X -Tps. 368104862Sru 369104862Sru---------------------------------------------------------------------- 370104862Sru 371104862Sru* When I try to print the output of groff -Tps, I get no output at all 372104862Sru from the printer, and the log file shows the error 373104862Sru %%[ error: undefined; offendingcommand: BP ]%% 374104862Sru I'm using TranScript spooling software. 375104862Sru 376104862SruThis is a bug in the page reversal filter in early versions of 377104862SruTranScript. Change the `broken' parameter in 378104862Sru/usr/local/lib/groff/font/devps/DESC to 7. 379104862Sru 380104862Sru---------------------------------------------------------------------- 381104862Sru 382104862Sru* When I preview groff -Tps output using the Sun OpenWindows 2.0 383104862Sru pageview program, all the pages are displayed on top of each other. 384104862Sru 385104862SruThis is a defect in pageview. Change the `broken' parameter in 386104862Sru/usr/local/lib/groff/font/devps/DESC to 2. 387104862Sru 388104862Sru---------------------------------------------------------------------- 389104862Sru 390104862Sru* With groff -TX75, -TX100 or -X, I can only view the first page. 391104862Sru 392104862SruThe left mouse button brings up a menu that allows you to view other 393104862Srupages. 394104862Sru 395104862Sru---------------------------------------------------------------------- 396104862Sru 397104862Sru* When I print the output of groff -Tdvi, I just get a black dot in 398104862Sru upper left corner. 399104862Sru 400104862SruSome dvi drivers (notably early versions of xtex) do not correctly 401104862Sruhandle dvi files that use a resolution different from that used by dvi 402104862Srufiles produced by TeX. Try getting a more up to date driver. 403104862Sru 404104862Sru---------------------------------------------------------------------- 405104862Sru 40618099Spst* How can I use groff with an old LaserJet printer that doesn't work 40769626Sru with groff -Tlj4? 40818099Spst 40918099SpstYou have at least 3 options: 41018099Spst 41118099Spst- use groff -Tps with GNU Ghostscript; 41218099Spst 41318099Spst- use groff -Tdvi with a TeX .dvi to Laserjet driver; 41418099Spst 41518099Spst- use groff with the LaserJet driver in Chris Lewis' psroff package 41669626Sru (available for ftp from: 41769626Sru ftp.uunet.ca:/distrib/chris_lewis/psroff3.0pl17). 41818099Spst 41969626Sru---------------------------------------------------------------------- 42069626Sru 42118099Spst* Groff seems to generate level 3 Postscript, but my printer is only a 42269626Sru level 1 or 2 PostScript printer. 42318099Spst 42418099SpstIn fact groff generates only level 1 PostScript. The `%!PS-Adobe-3.0' 42518099Spstcomment at the beginning of PostScript output generated by groff 42618099Spstindicates that the file conforms to version 3.0 of the Adobe Document 42718099SpstStructuring Conventions. The output generated by groff should be 42818099Spstprintable on any PostScript printer. Problems with groff output's not 42918099Spstprinting are most often caused by the spooling system. 43018099Spst 431104862Sru 432104862Sru 433104862SruPlatform-Dependent Macro Problems 434104862Sru================================= 435104862Sru 436104862Sru 437104862Sru 438104862Sru* I get lots of errors when I use groff with the AT&T -mm macros. 439104862Sru 440104862SruUse the groff -mm macros. 441104862Sru 44269626Sru---------------------------------------------------------------------- 44369626Sru 444104862Sru* groff produces wrapper macros for `ms' and friends which call the 445104862Sru system's original macros. Then, to get groff's ms macro package I 446104862Sru have to use `-mgs' instead `-ms'. Can I avoid this? 44718099Spst 448104862SruYes. Configure and compile groff as usual, but install it with 44918099Spst 450104862Sru make install tmac_wrap="" 451104862Sru 452104862SruThen no wrapper files are produced, and `-ms' will use groff's `ms' 453104862Srumacros. 454104862Sru 45569626Sru---------------------------------------------------------------------- 45669626Sru 457104862Sru* I'm having problems formatting HP-UX 9.0 man pages with groff -man. 458104862Sru 459104862SruCopy HP's tmac.an into /usr/local/share/groff/site-tmac/an.tmac, and 460104862Srueither put `.cp 1' at the beginning or filter it (and any files it 461104862Sru.so's) through tmac/fixmacros.sed. 462104862Sru 463104862Sru---------------------------------------------------------------------- 464104862Sru 465104862Sru* I get errors using the Unix -ms macros with groff -e -C. 466104862Sru 467104862SruApply this change: 468104862Sru 469104862Sru*** /usr/lib/ms/ms.eqn Tue Apr 25 02:14:28 1989 470104862Sru--- ms.eqn Sun Nov 11 10:33:59 1990 471104862Sru*************** 472104862Sru*** 22,29 **** 473104862Sru .. 474104862Sru . \" EN - end of a displayed equation 475104862Sru .de EN 476104862Sru! .if !\\*(10 .br 477104862Sru .di 478104862Sru .rm EZ 479104862Sru .nr ZN \\n(dn 480104862Sru .if \\n(ZN>0 .if \\n(YE=0 .LP 481104862Sru--- 22,30 ---- 482104862Sru .. 483104862Sru . \" EN - end of a displayed equation 484104862Sru .de EN 485104862Sru! .if \\n(.k>0 .br 486104862Sru .di 487104862Sru+ .ds 10 \\*(EZ\\ 488104862Sru .rm EZ 489104862Sru .nr ZN \\n(dn 490104862Sru .if \\n(ZN>0 .if \\n(YE=0 .LP 491104862Sru 492104862Sru---------------------------------------------------------------------- 493104862Sru 494104862Sru* I'm having problems formatting Ultrix man pages with groff -man. 495104862Sru 496104862SruThe Ultrix man pages use a number of non-standard extensions to the 497104862SruUnix man macros. One solution is to use the Ultrix -man macros with 498104862Srugroff. Copy /usr/lib/tmac/tmac.an to 499104862Sru/usr/local/share/groff/site-tmac/an.tmac and apply the following patch 500104862Sru(from Frank Wortner): 501104862Sru 502104862Sru*** /usr/local/lib/groff/tmac/tmac.an Wed Sep 9 12:29:28 1992 503104862Sru--- /usr/lib/tmac/tmac.an Fri Jul 24 19:58:19 1992 504104862Sru*************** 505104862Sru*** 489,495 **** 506104862Sru . \" make special case of shift out of italic 507104862Sru .de }S 508104862Sru .ds ]F 509104862Sru! .if \\$12 .if !\\$5 .ds ]F \^ 510104862Sru .ie !\\$4 .}S \\$2 \\$1 "\\$3\f\\$1\\$4\\*(]F" "\\$5" "\\$6" "\\$7" "\\$8" "\\$9" 511104862Sru .el \\$3 512104862Sru .}f 513104862Sru--- 489,495 ---- 514104862Sru . \" make special case of shift out of italic 515104862Sru .de }S 516104862Sru .ds ]F 517104862Sru! .if \\$12 .if !\\$5 .ds ]F\^ 518104862Sru .ie !\\$4 .}S \\$2 \\$1 "\\$3\f\\$1\\$4\\*(]F" "\\$5" "\\$6" "\\$7" "\\$8" "\\$9" 519104862Sru .el \\$3 520104862Sru .}f 521104862Sru 522104862SruAnother possible solution is to install tmac/man.ultrix as 523104862Sru/usr/local/share/groff/site-tmac/man.local. 524104862Sru 525104862Sru---------------------------------------------------------------------- 526104862Sru 52718099Spst* On an SGI system, how can I make the man command use groff? 52818099Spst 52918099SpstFrom David Hinds <dhinds@allegro.stanford.edu> (some of these steps 53018099Spstare unnecessary if you install with the `g' Makefile variable defined 53118099Spstas empty): 53218099Spst 53318099SpstCreate a script called 'eqn': 53418099Spst 53518099Spst > #!/bin/sh 53618099Spst > if [ ${1:-""} = /usr/pub/eqnchar ] ; then shift ; fi 53718099Spst > geqn $* 53818099Spst 53918099Spstand a script called 'neqn': 54018099Spst 54118099Spst > #!/bin/sh 54218099Spst > if [ ${1:-""} = /usr/pub/eqnchar ] ; then shift ; fi 54318099Spst > geqn -Tascii $* 54418099Spst 54518099Spstand do: 54618099Spst 54718099Spst > ln -s gnroff nroff 54818099Spst 54918099Spstand edit the end of the gnroff script to be: 55018099Spst 55118099Spst > rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'` 55218099Spst > exec groff -Wall -mtty-char $T $opts $rest 55318099Spst 55418099SpstTo get PostScript output from 'man -t', you also need to create a 55518099Spst'psroff' script similar to 'nroff'. Here are the context diffs: 55618099Spst 55718099Spst*** /usr/local/bin/nroff Sat Feb 13 15:51:09 1993 55818099Spst--- /usr/local/bin/psroff Sat Feb 13 17:45:46 1993 55918099Spst*************** 56018099Spst*** 1,8 **** 56118099Spst #!/bin/sh 56218099Spst! # Emulate nroff with groff. 56318099Spst 56418099Spst prog="$0" 56518099Spst! T=-Tascii 56618099Spst opts= 56718099Spst 56818099Spst for i 56918099Spst--- 1,8 ---- 57018099Spst #!/bin/sh 57118099Spst! # Emulate psroff with groff. 57218099Spst 57318099Spst prog="$0" 57418099Spst! T=-Tps 57518099Spst opts= 57618099Spst 57718099Spst for i 57818099Spst*************** 57918099Spst*** 25,30 **** 58018099Spst--- 25,33 ---- 58118099Spst -Tascii|-Tlatin1) 58218099Spst T=$1 58318099Spst ;; 58418099Spst+ -t) 58518099Spst+ # ignore -- default is send to stdout 58618099Spst+ ;; 58718099Spst -T*) 58818099Spst # ignore other devices 58918099Spst ;; 59018099Spst*************** 59118099Spst*** 49,53 **** 59218099Spst rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'` 59318099Spst 59418099Spst # This shell script is intended for use with man, so warnings are 59518099Spst # probably not wanted. Also load nroff-style character definitions. 59618099Spst! exec groff -Wall -mtty-char $T $opts $rest 59718099Spst--- 52,56 ---- 59818099Spst rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'` 59918099Spst 60018099Spst # This shell script is intended for use with man, so warnings are 60118099Spst! # probably not wanted. 60218099Spst! exec groff -Wall $T $opts $rest 603104862Sru 604104862Sru 605104862Sru 606104862SruCompilation Problems 607104862Sru==================== 608104862Sru 609104862Sru 610104862Sru 611104862Sru* Compilation dies with 612104862Sru 613104862Sru y.tab.c: In function `int yyparse()': 614104862Sru y.tab.c: `size_t' undeclared in namespace `std' 615104862Sru 616104862SruThis is a bug in bison 1.32. Don't use this version. 1.28 or 1.33 works 617104862Srufine. Alternatively, use yacc or byacc. 618104862Sru 619104862Sru---------------------------------------------------------------------- 620104862Sru 621104862Sru* There are many empty `Makefile.dep' files. Is this a bug? 622104862Sru 623104862SruNo. Real dependency files are created with a `make depend' call. 624104862Sru 625104862Sru---------------------------------------------------------------------- 626104862Sru 627104862Sru* On HP-UX, the compiler complains about missing symbol `alloca'. 628104862Sru 629104862SruSay 630104862Sru 631104862Sru export LDFLAGS=-lPW 632104862Sru 633104862Srubefore starting the configure script. 634104862Sru 635104862Sru---------------------------------------------------------------------- 636104862Sru 637104862Sru* The configure script fails on OS/390 (z/OS) Unix. 638104862Sru 639104862Sru[This has been fixed in z/OS V1R3 (aka OS/390 R13).] 640104862Sru 641104862SruThere is a bug in the Language Environment (LE) whereby the test 642104862Sruprogram for static destructors fails. You will see the message 643104862Sru`configure: error: a working C++ compiler is required' 644104862Sru 645104862SruApplying PTF UQ42006 is supposed to fix this, but the test program is 646104862Srustill returning the wrong value (1). To work around this problem, you 647104862Srucan comment out the following in the configure script (near line 2029). 648104862SruThis will effectively bypass the test (static constructors and 649104862Srudestructors do actually work properly): 650104862Sru 651104862Sru#if { (eval echo "$as_me:2029: \"$ac_link\"") >&5 652104862Sru# (eval $ac_link) 2>&5 653104862Sru# ac_status=$? 654104862Sru# echo "$as_me:2032: \$? = $ac_status" >&5 655104862Sru# (exit $ac_status); } && { ac_try='./conftest$ac_exeext' 656104862Sru# { (eval echo "$as_me:2034: \"$ac_try\"") >&5 657104862Sru# (eval $ac_try) 2>&5 658104862Sru# ac_status=$? 659104862Sru# echo "$as_me:2037: \$? = $ac_status" >&5 660104862Sru# (exit $ac_status); }; }; then 661104862Sru# echo "$as_me:2039: result: yes" >&5 662104862Sru#echo "${ECHO_T}yes" >&6 663104862Sru#else 664104862Sru# echo "$as_me: program exited with status $ac_status" >&5 665104862Sru#echo "$as_me: failed program was:" >&5 666104862Sru#cat conftest.$ac_ext >&5 667104862Sru#echo "$as_me:2045: result: no" >&5 668104862Sru#echo "${ECHO_T}no" >&6;{ { echo "$as_me:2046: error: a working C++ compiler is required" >&5 669104862Sru#echo "$as_me: error: a working C++ compiler is required" >&2;} 670104862Sru# { (exit 1); exit 1; }; } 671104862Sru#fi 672104862Sru 673104862Sru---------------------------------------------------------------------- 674104862Sru 675104862Sru* I get errors when I try to compile groff with DEC C++. 676104862Sru 677104862SruFix the declaration of write() in <unistd.h> so that the second 678104862Sruargument is a const char *. Fix the declaration of open() in 679104862Sru<sys/file.h> so that the first argument is a const char *. 680104862Sru 681104862Sru---------------------------------------------------------------------- 682104862Sru 683104862Sru* On a host using Unix make (e.g. Solaris), if you are compiling for 684104862Sru multiple architectures by building in a subdirectory, the make stops 685104862Sru with a message like this: 686104862Sru 687104862Sru make: Fatal error: Don't know how to make target `assert.o' 688104862Sru 689104862Sru or like this: 690104862Sru 691104862Sru make: Fatal error: Can't find /u/src/groff/src/include/Makefile.sub': No such file or directory 692104862Sru 693104862SruThis occurs because GNU make and Unix make handle VPATH differently, 694104862Sruand the groff build relies on GNU make's VPATH handling. 695104862Sru 696104862SruUse GNU make to work around the problem. In Solaris 8, GNU make is 697104862Sruon the Software Companion CD and is installed as /opt/sfw/bin/gmake. 698104862Sru 699104862Sru---------------------------------------------------------------------- 700104862Sru 701104862Sru* On Ultrix, the make stops with the message 702104862Sru 703104862Sru *** Error code 1 704104862Sru 705104862Sru Stop. 706104862Sru 707104862Sru for no apparent reason. 708104862Sru 709104862SruUse GNU make. 710104862Sru 711104862Sru---------------------------------------------------------------------- 712104862Sru 713104862Sru* I'm having problems compiling groff on 386BSD 0.1. 714104862Sru 715104862SruIf you're using ash as /bin/sh, you'll need the following patch. 716104862Sru 717104862Sru*** gendef.sh.org Sun Jun 30 13:30:36 1991 718104862Sru--- gendef.sh Sun Feb 28 10:23:49 1993 719104862Sru*************** 720104862Sru*** 3,9 **** 721104862Sru file=$1 722104862Sru shift 723104862Sru 724104862Sru! defs="#define $1" 725104862Sru shift 726104862Sru for def 727104862Sru do 728104862Sru--- 3,10 ---- 729104862Sru file=$1 730104862Sru shift 731104862Sru 732104862Sru! x=$1 733104862Sru! defs="#define $x" 734104862Sru shift 735104862Sru for def 736104862Sru do 737104862Sru 738104862SruYou'll also need to change dirnamemax.c so that it doesn't use 739104862Srupathconf(). 740104862Sru 741104862Sru---------------------------------------------------------------------- 742104862Sru 743104862Sru* While compiling on Xenix, ranlib libgroff.a fails. 744104862Sru 745104862SruThe system ranlib can't handle externals longer than 40 characters. 746104862SruUse the ranlib included in demon.co.uk:/pub/xenix/g++-1.40.3a.v1 747104862Sruinstead. 748104862Sru 749104862Sru---------------------------------------------------------------------- 750104862Sru 751104862Sru* I get errors when I try to compile groff with Sun C++ version 3 or 752104862Sru earlier. 753104862Sru 754104862SruGroff requires header files that are moderately compatible with AT&T 755104862SruC++ and ANSI C. With some versions of Sun C++, the supplied header 756104862Srufiles need some of the following changes to meet this requirement: 757104862Sru<string.h> must declare the mem* functions, (just add `#include 758104862Sru<memory.h>' to <string.h>); the first argument to fopen and freopen 759104862Srushould be declared as `const char *'; the first argument to fread 760104862Srushould be declared as `void *'; the first argument to fwrite should be 761104862Srudeclared as `const void *'; malloc should be declared to return 762104862Sru`void *'; in <alloca.h>, the declaration `extern "C" { void 763104862Sru*__builtin_alloca(int); }' should be added; in <sys/signal.h> the 764104862Srureturn type and the second argument type of signal() should be changed 765104862Sruto be `void (*)(int)'. 766104862Sru 767104862SruYou can either change them in place, or copy them to some other 768104862Srudirectory and include that directory with a -I option. 769104862Sru 770104862Sru---------------------------------------------------------------------- 771104862Sru 772104862Sru* I get errors when I try to compile groff with Sun C++ version 5.0 773104862Sru or 5.1. 774104862Sru 775104862SruThis is a known problem; see Sun bug #4301919. As of this writing, no 776104862Srupatch is available. Use GCC 2.95.2 or later instead. 777104862Sru 778104862Sru---------------------------------------------------------------------- 779104862Sru 780104862Sru* I get lots of `numeric overflow' error messages whenever I run 781104862Sru groff; I compiled groff with AT&T C++ 2.0 with an ANSI C compiler. 782104862Sru 783104862SruMake sure -DCFRONT_ANSI_BUG is included in DEFINES in the top-level 784104862SruMakefile. If that doesn't solve the problem, define INT_MIN as 785104862Sru-INT_MAX in libgroff/lib.h. 786