PROBLEMS revision 114402
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 41114402SruRead the section on incompatibilities in groff_diff(7). Try using 42114402Sruthe -C option. Alternatively there's the sed script 43114402Sru`tmac/fixmacros.sed' which will attempt to edit a file of macros so 44114402Sruthat it can be used with 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 72114402SruUse the `ftr' request. See groff_diff(7). 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 122114402Sruput modified macros from tmac/an-old.tmac into man.local. More 123114402Sruinformation is available in groff_man(7). 12469626Sru 12569626Sru---------------------------------------------------------------------- 12669626Sru 127104862Sru* Where can I get grap? 128104862Sru 129104862SruTed Faber <faber@lunabase.org> has written a freely available grap: 130104862Sru 131104862Sru http://www.lunabase.org/~faber/Vault/software/grap/ 132104862Sru 133104862Sru---------------------------------------------------------------------- 134104862Sru 135104862Sru* The \n(st and \n(sb registers don't seem to work. I thought \w set 136104862Sru them to the height and depth of its argument, but the registers 137104862Sru always seem to be 0. 138104862Sru 139104862Sru\n(st and \n(sb aren't supposed to give the height and depth of the 140104862Srustring rather they give the minimum and maximum vertical displacement 141104862Sruof the baseline. For example for \v'2u'\v'-3u', \n(st will be 1 and 142104862Sru\n(sb will be -2. The height and depth of the string is available in 143104862Sruthe \n[rst] and \n[rsb] registers: these are groff extensions. 144104862Sru 145104862Sru---------------------------------------------------------------------- 146104862Sru 14769626Sru* While formatting a manual page, groff complains about not being able 14869626Sru to break lines. The problem seems to be caused by a line like: 14918099Spst .TP \w'label'+2 15018099Spst 15118099SpstThe -man documentation says that the default scale indicator for TP 15218099Spstmacro is `n'. The groff -man macros implement this correctly, so that 15318099Spstthe argument will be evaluated as if it were 15469626Sru 15518099Spst \w'label'n+2n 15669626Sru 15718099SpstThe Unix -man macros don't implement this correctly (probably because 15818099Spstit's hard to do in Unix troff); they just append `n' to the entire 15918099Spstargument, so that it will be evaluated as if it were 16069626Sru 16118099Spst \w'label'u+2n 16269626Sru 16318099SpstThe solution is to fix the manual page: 16469626Sru 16518099Spst .TP \w'label'u+2 16618099Spst 16769626Sru---------------------------------------------------------------------- 16869626Sru 16918099Spst* I'm having problems formatting man pages produced by the perl 17069626Sru wrapman script. 17118099Spst 17218099SpstSome versions of wrapman have a superfluous blank line before the .TH 17318099Spstline. This must be deleted. Then either use groff -C, or apply the 17418099Spstfollowing patch: 17518099Spst 17618099Spst*** wrapman.~2~ Sun Jan 19 12:10:24 1992 17718099Spst--- wrapman Tue Aug 10 02:06:41 1993 17818099Spst*************** 17918099Spst*** 35,41 **** 18018099Spst $line1 .= <IN> if $line1 =~ /eval/; 18118099Spst $line1 .= <IN> if $line1 =~ /argv/; 18218099Spst $line2 = <IN>; 18318099Spst! next if $line2 eq "'di';\n"; 18418099Spst 18518099Spst # Pull the old switcheroo. 18618099Spst 18718099Spst--- 35,41 ---- 18818099Spst $line1 .= <IN> if $line1 =~ /eval/; 18918099Spst $line1 .= <IN> if $line1 =~ /argv/; 19018099Spst $line2 = <IN>; 19118099Spst! next if $line2 eq "'di ';\n" || $line2 eq "'di';\n"; 19218099Spst 19318099Spst # Pull the old switcheroo. 19418099Spst 19518099Spst*************** 19618099Spst*** 49,56 **** 19718099Spst 19818099Spst print OUT $line1; 19918099Spst print OUT <<EOF; 20018099Spst! 'di'; 20118099Spst! 'ig00'; 20218099Spst # 20318099Spst # $header 20418099Spst # 20518099Spst--- 49,58 ---- 20618099Spst 20718099Spst print OUT $line1; 20818099Spst print OUT <<EOF; 20918099Spst! 'di '; 21018099Spst! 'ds 00 \\"'; 21118099Spst! 'eo '; 21218099Spst! 'ig 00 '; 21318099Spst # 21418099Spst # $header 21518099Spst # 21618099Spst*************** 21718099Spst*** 72,85 **** 21818099Spst 21918099Spst # These next few lines are legal in both Perl and nroff. 22018099Spst 22118099Spst! $null.00; # finish .ig 22218099Spst 22318099Spst 'di \\" finish diversion--previous line must be blank 22418099Spst .nr nl 0-1 \\" fake up transition to first page again 22518099Spst .nr % 0 \\" start at page 1 22618099Spst! '; __END__ ##### From here on it's a standard manual page ##### 22718099Spst .TH $PROG 1 "$month $mday, 19$year" 22818099Spst- .AT 3 22918099Spst .SH NAME 23018099Spst $prog \\- whatever 23118099Spst .SH SYNOPSIS 23218099Spst--- 74,87 ---- 23318099Spst 23418099Spst # These next few lines are legal in both Perl and nroff. 23518099Spst 23618099Spst! $null.00 ; # finish .ig 23718099Spst! 'ec \\'; 23818099Spst 23918099Spst 'di \\" finish diversion--previous line must be blank 24018099Spst .nr nl 0-1 \\" fake up transition to first page again 24118099Spst .nr % 0 \\" start at page 1 24218099Spst! .\\"'; __END__ ##### From here on it's a standard manual page ##### 24318099Spst .TH $PROG 1 "$month $mday, 19$year" 24418099Spst .SH NAME 24518099Spst $prog \\- whatever 24618099Spst .SH SYNOPSIS 24718099Spst 24869626Sru---------------------------------------------------------------------- 24918099Spst 25018099Spst* groff uses up an enormous amount of memory processing large files. 25169626Sru I'm using 386BSD 0.1. 25218099Spst 25318099Spst386BSD includes an old version of g++, 1.39, which has a bug that 25418099Spstcauses a major memory leak in gtroff. Apply the following fix to g++ 25518099Spstand recompile groff: 25618099Spst 25718099Spst*** cplus-decl.c.~1~ Mon Aug 6 05:28:59 1990 25818099Spst--- cplus-decl.c Wed Jun 5 08:55:04 1991 25918099Spst*************** 26018099Spst*** 7951,7961 **** 26118099Spst 26218099Spst /* At the end, call delete if that's what's requested. */ 26318099Spst if (TREE_GETS_DELETE (current_class_type)) 26418099Spst exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node), 26518099Spst get_identifier (OPERATOR_DELETE_FORMAT), 26618099Spst! build_tree_list (NULL_TREE, integer_zero_node), 26718099Spst NULL_TREE, LOOKUP_NORMAL); 26818099Spst else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type)) 26918099Spst exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0); 27018099Spst else 27118099Spst exprstmt = 0; 27218099Spst--- 7951,7961 ---- 27318099Spst 27418099Spst /* At the end, call delete if that's what's requested. */ 27518099Spst if (TREE_GETS_DELETE (current_class_type)) 27618099Spst exprstmt = build_method_call (build1 (NOP_EXPR, TYPE_POINTER_TO (current_class_type), error_mark_node), 27718099Spst get_identifier (OPERATOR_DELETE_FORMAT), 27818099Spst! build_tree_list (NULL_TREE, current_class_decl), 27918099Spst NULL_TREE, LOOKUP_NORMAL); 28018099Spst else if (TYPE_USES_VIRTUAL_BASECLASSES (current_class_type)) 28118099Spst exprstmt = build_x_delete (ptr_type_node, current_class_decl, 0); 28218099Spst else 28318099Spst exprstmt = 0; 28418099Spst 285104862Sru 286104862Sru 287104862SruPrinting and Display Problems 288104862Sru============================= 289104862Sru 290104862Sru 291104862Sru 292104862Sru* I'm having problems including PostScript illustrations (EPS) using 293104862Sru the PSPIC macro and/or \X'ps: import ...'. 294104862Sru 295104862SruA PostScript document must meet three requirements in order to be 296104862Sruincluded with the PSPIC macro: it must comply with the Adobe Document 297104862SruStructuring Conventions; it must contain a BoundingBox line; it must 298104862Srube ``well-behaved''. The BoundingBox line should be of the form: 299104862Sru 300104862Sru %%BoundingBox: llx lly urx ury 301104862Sru 302104862Sruwhere llx, lly, urx, ury are the coordinates of the lower left x, 303104862Srulower left y, upper right x, upper right y of the bounding box of 304104862Srumarks on the page expressed as integers in the default PostScript 305104862Srucoordinate system (72 units per inch, origin at bottom left corner). 306104862Sru 307104862SruThe most convenient program to get the bounding box of a document is 308104862Sruthe `ps2epsi' script coming with GhostScript. 309104862Sru 310104862SruIf you can't use this program, another useful tactic is to print out 311104862Sruthe illustration by itself (you may need to add a `showpage' at the 312104862Sruend), and physically measure the bounding box. For more detail on 313104862Sruthese requirements, read the specification of Encapsulated PostScript 314104862Sruformat. (This is available from the Adobe file server; send a message 315104862Sruwith a body of `help' to ps-file-server@adobe.com.) 316104862Sru 317104862SruIf an EPS file to be included via \X'ps: import' does not start with 318104862Sru%!PS-Adobe-...', gtroff will still include the file, but grops will 319104862Srunot add any fonts to the generated output file that are listed in the 320104862SruEPS file, even though the files are listed in the `download' file and 321104862Sruare available in the devps directory. 322104862Sru 32369626Sru---------------------------------------------------------------------- 32469626Sru 325104862Sru* I've configured groff for A4 paper, but gtroff still seems to think 326104862Sru that the length of a page (as returned by `\n(.p') is 11 inches. 32718099Spst 328114402SruThis is intentional. The PAGE option during configuration is used 329114402Sruonly by grops. For compatibility with ditroff, the default page 330114402Srulength in gtroff is always 11 inches. The page length can be changed 331114402Sruwith the `pl' request. 33218099Spst 333114402SruA convenient way to set paper dimensions is to use the -dpaper option 334114402Sruof groff, together with proper -P options for the postprocessor 335114402Sru(overriding the default). For example, use the following for PS 336114402Sruoutput on A4 paper in landscape orientation: 337114402Sru 338114402Sru groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo.ps 339114402Sru 340114402SruSee groff_tmac(5) for more information. 341114402Sru 342104862Sru---------------------------------------------------------------------- 34369626Sru 344114402Sru* When I print the output of groff -Tps, the output is always shifted 345114402Sru up by about 0.7 inches; I'm using 8.5x11 inch paper. 346104862Sru 347114402SruMake sure that the paper size is `letter'. See groff_tmac(5). 348104862Sru 34969626Sru---------------------------------------------------------------------- 35069626Sru 351104862Sru* When I try to run gxditview, I get the error: 352104862Sru Error: Widget viewport has zero width and/or height 353104862Sru 354104862SruThis error means you haven't correctly installed the application 355104862Srudefaults file, GXditview.ad; ``make install'' does this for you 356104862Sruautomatically, so either you didn't do ``make install'', or you don't 357104862Sruhave imake configured correctly. 358104862Sru 359104862Sru---------------------------------------------------------------------- 360104862Sru 361104862Sru* When I preview documents using -TX75 or -TX100, the layout is not 362104862Sru the same as when I print the document with -Tps: the line and page 363104862Sru breaks come in different places. 364104862Sru 365104862SruUse groff -X -Tps. 366104862Sru 367104862Sru---------------------------------------------------------------------- 368104862Sru 369104862Sru* When I try to print the output of groff -Tps, I get no output at all 370104862Sru from the printer, and the log file shows the error 371104862Sru %%[ error: undefined; offendingcommand: BP ]%% 372104862Sru I'm using TranScript spooling software. 373104862Sru 374104862SruThis is a bug in the page reversal filter in early versions of 375104862SruTranScript. Change the `broken' parameter in 376104862Sru/usr/local/lib/groff/font/devps/DESC to 7. 377104862Sru 378104862Sru---------------------------------------------------------------------- 379104862Sru 380104862Sru* When I preview groff -Tps output using the Sun OpenWindows 2.0 381104862Sru pageview program, all the pages are displayed on top of each other. 382104862Sru 383104862SruThis is a defect in pageview. Change the `broken' parameter in 384104862Sru/usr/local/lib/groff/font/devps/DESC to 2. 385104862Sru 386104862Sru---------------------------------------------------------------------- 387104862Sru 388104862Sru* With groff -TX75, -TX100 or -X, I can only view the first page. 389104862Sru 390104862SruThe left mouse button brings up a menu that allows you to view other 391104862Srupages. 392104862Sru 393104862Sru---------------------------------------------------------------------- 394104862Sru 395104862Sru* When I print the output of groff -Tdvi, I just get a black dot in 396104862Sru upper left corner. 397104862Sru 398104862SruSome dvi drivers (notably early versions of xtex) do not correctly 399104862Sruhandle dvi files that use a resolution different from that used by dvi 400104862Srufiles produced by TeX. Try getting a more up to date driver. 401104862Sru 402104862Sru---------------------------------------------------------------------- 403104862Sru 40418099Spst* How can I use groff with an old LaserJet printer that doesn't work 40569626Sru with groff -Tlj4? 40618099Spst 40718099SpstYou have at least 3 options: 40818099Spst 40918099Spst- use groff -Tps with GNU Ghostscript; 41018099Spst 41118099Spst- use groff -Tdvi with a TeX .dvi to Laserjet driver; 41218099Spst 41318099Spst- use groff with the LaserJet driver in Chris Lewis' psroff package 41469626Sru (available for ftp from: 41569626Sru ftp.uunet.ca:/distrib/chris_lewis/psroff3.0pl17). 41618099Spst 41769626Sru---------------------------------------------------------------------- 41869626Sru 41918099Spst* Groff seems to generate level 3 Postscript, but my printer is only a 42069626Sru level 1 or 2 PostScript printer. 42118099Spst 422114402SruIn fact groff generates only level 2 PostScript (or rather level 1 423114402Sruwith some extensions; see grops(1) for more information how to disable 424114402Sruthem). The `%!PS-Adobe-3.0' comment at the beginning of PostScript 425114402Sruoutput generated by groff indicates that the file conforms to 426114402Sruversion 3.0 of the Adobe Document Structuring Conventions. The output 427114402Srugenerated by groff should be printable on any PostScript printer. 428114402SruProblems with groff output's not printing are most often caused by the 429114402Sruspooling 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 616114402Sru* bison reports conflicts (either on stderr or in the `pic.output' 617114402Sru file) while processing `pic.y', and the produced pic binary doesn't 618114402Sru work at all. 619104862Sru 620114402SruYou need bison version 1.875b or greater. Alternatively, use yacc or 621114402Srubyacc. 622114402Sru 623104862Sru---------------------------------------------------------------------- 624104862Sru 625104862Sru* There are many empty `Makefile.dep' files. Is this a bug? 626104862Sru 627104862SruNo. Real dependency files are created with a `make depend' call. 628104862Sru 629104862Sru---------------------------------------------------------------------- 630104862Sru 631104862Sru* On HP-UX, the compiler complains about missing symbol `alloca'. 632104862Sru 633104862SruSay 634104862Sru 635104862Sru export LDFLAGS=-lPW 636104862Sru 637104862Srubefore starting the configure script. 638104862Sru 639104862Sru---------------------------------------------------------------------- 640104862Sru 641104862Sru* The configure script fails on OS/390 (z/OS) Unix. 642104862Sru 643104862Sru[This has been fixed in z/OS V1R3 (aka OS/390 R13).] 644104862Sru 645104862SruThere is a bug in the Language Environment (LE) whereby the test 646104862Sruprogram for static destructors fails. You will see the message 647104862Sru`configure: error: a working C++ compiler is required' 648104862Sru 649104862SruApplying PTF UQ42006 is supposed to fix this, but the test program is 650104862Srustill returning the wrong value (1). To work around this problem, you 651104862Srucan comment out the following in the configure script (near line 2029). 652104862SruThis will effectively bypass the test (static constructors and 653104862Srudestructors do actually work properly): 654104862Sru 655104862Sru#if { (eval echo "$as_me:2029: \"$ac_link\"") >&5 656104862Sru# (eval $ac_link) 2>&5 657104862Sru# ac_status=$? 658104862Sru# echo "$as_me:2032: \$? = $ac_status" >&5 659104862Sru# (exit $ac_status); } && { ac_try='./conftest$ac_exeext' 660104862Sru# { (eval echo "$as_me:2034: \"$ac_try\"") >&5 661104862Sru# (eval $ac_try) 2>&5 662104862Sru# ac_status=$? 663104862Sru# echo "$as_me:2037: \$? = $ac_status" >&5 664104862Sru# (exit $ac_status); }; }; then 665104862Sru# echo "$as_me:2039: result: yes" >&5 666104862Sru#echo "${ECHO_T}yes" >&6 667104862Sru#else 668104862Sru# echo "$as_me: program exited with status $ac_status" >&5 669104862Sru#echo "$as_me: failed program was:" >&5 670104862Sru#cat conftest.$ac_ext >&5 671104862Sru#echo "$as_me:2045: result: no" >&5 672104862Sru#echo "${ECHO_T}no" >&6;{ { echo "$as_me:2046: error: a working C++ compiler is required" >&5 673104862Sru#echo "$as_me: error: a working C++ compiler is required" >&2;} 674104862Sru# { (exit 1); exit 1; }; } 675104862Sru#fi 676104862Sru 677104862Sru---------------------------------------------------------------------- 678104862Sru 679104862Sru* I get errors when I try to compile groff with DEC C++. 680104862Sru 681104862SruFix the declaration of write() in <unistd.h> so that the second 682104862Sruargument is a const char *. Fix the declaration of open() in 683104862Sru<sys/file.h> so that the first argument is a const char *. 684104862Sru 685104862Sru---------------------------------------------------------------------- 686104862Sru 687104862Sru* On a host using Unix make (e.g. Solaris), if you are compiling for 688104862Sru multiple architectures by building in a subdirectory, the make stops 689104862Sru with a message like this: 690104862Sru 691104862Sru make: Fatal error: Don't know how to make target `assert.o' 692104862Sru 693104862Sru or like this: 694104862Sru 695104862Sru make: Fatal error: Can't find /u/src/groff/src/include/Makefile.sub': No such file or directory 696104862Sru 697104862SruThis occurs because GNU make and Unix make handle VPATH differently, 698104862Sruand the groff build relies on GNU make's VPATH handling. 699104862Sru 700104862SruUse GNU make to work around the problem. In Solaris 8, GNU make is 701104862Sruon the Software Companion CD and is installed as /opt/sfw/bin/gmake. 702104862Sru 703104862Sru---------------------------------------------------------------------- 704104862Sru 705104862Sru* On Ultrix, the make stops with the message 706104862Sru 707104862Sru *** Error code 1 708104862Sru 709104862Sru Stop. 710104862Sru 711104862Sru for no apparent reason. 712104862Sru 713104862SruUse GNU make. 714104862Sru 715104862Sru---------------------------------------------------------------------- 716104862Sru 717104862Sru* I'm having problems compiling groff on 386BSD 0.1. 718104862Sru 719104862SruIf you're using ash as /bin/sh, you'll need the following patch. 720104862Sru 721104862Sru*** gendef.sh.org Sun Jun 30 13:30:36 1991 722104862Sru--- gendef.sh Sun Feb 28 10:23:49 1993 723104862Sru*************** 724104862Sru*** 3,9 **** 725104862Sru file=$1 726104862Sru shift 727104862Sru 728104862Sru! defs="#define $1" 729104862Sru shift 730104862Sru for def 731104862Sru do 732104862Sru--- 3,10 ---- 733104862Sru file=$1 734104862Sru shift 735104862Sru 736104862Sru! x=$1 737104862Sru! defs="#define $x" 738104862Sru shift 739104862Sru for def 740104862Sru do 741104862Sru 742104862SruYou'll also need to change dirnamemax.c so that it doesn't use 743104862Srupathconf(). 744104862Sru 745104862Sru---------------------------------------------------------------------- 746104862Sru 747104862Sru* While compiling on Xenix, ranlib libgroff.a fails. 748104862Sru 749104862SruThe system ranlib can't handle externals longer than 40 characters. 750104862SruUse the ranlib included in demon.co.uk:/pub/xenix/g++-1.40.3a.v1 751104862Sruinstead. 752104862Sru 753104862Sru---------------------------------------------------------------------- 754104862Sru 755104862Sru* I get errors when I try to compile groff with Sun C++ version 3 or 756104862Sru earlier. 757104862Sru 758104862SruGroff requires header files that are moderately compatible with AT&T 759104862SruC++ and ANSI C. With some versions of Sun C++, the supplied header 760104862Srufiles need some of the following changes to meet this requirement: 761104862Sru<string.h> must declare the mem* functions, (just add `#include 762104862Sru<memory.h>' to <string.h>); the first argument to fopen and freopen 763104862Srushould be declared as `const char *'; the first argument to fread 764104862Srushould be declared as `void *'; the first argument to fwrite should be 765104862Srudeclared as `const void *'; malloc should be declared to return 766104862Sru`void *'; in <alloca.h>, the declaration `extern "C" { void 767104862Sru*__builtin_alloca(int); }' should be added; in <sys/signal.h> the 768104862Srureturn type and the second argument type of signal() should be changed 769104862Sruto be `void (*)(int)'. 770104862Sru 771104862SruYou can either change them in place, or copy them to some other 772104862Srudirectory and include that directory with a -I option. 773104862Sru 774104862Sru---------------------------------------------------------------------- 775104862Sru 776104862Sru* I get errors when I try to compile groff with Sun C++ version 5.0 777104862Sru or 5.1. 778104862Sru 779104862SruThis is a known problem; see Sun bug #4301919. As of this writing, no 780104862Srupatch is available. Use GCC 2.95.2 or later instead. 781104862Sru 782104862Sru---------------------------------------------------------------------- 783104862Sru 784104862Sru* I get lots of `numeric overflow' error messages whenever I run 785104862Sru groff; I compiled groff with AT&T C++ 2.0 with an ANSI C compiler. 786104862Sru 787104862SruMake sure -DCFRONT_ANSI_BUG is included in DEFINES in the top-level 788104862SruMakefile. If that doesn't solve the problem, define INT_MIN as 789104862Sru-INT_MAX in libgroff/lib.h. 790114402Sru 791114402Sru---------------------------------------------------------------------- 792114402Sru 793114402Sru* When compiling on MacOS X, groff compiles but does not run well. 794114402Sru 795114402SruUse ./configure CXX=g++2 then make as usual. 796