[Groff] Re: DESC question
Back from vacation > What exactly is the DESC file? It describes the capabilities of an output device. See the groff_font manpage for details of what the device does. > When I type in "groff" on my Debian testing box all it > does is wait for input (it doesn't return any output). Right. Given no arguments, groff reads stdin and writes PostScript output. Type "groff -v" to see what version you have installed already. Thing is, Debian's default groff package is cut back to the point where it's only good for formatting manpages. > I recently compiled groff from scratch in another > directory with a seperate native toolchain I've been > building, and when I run groff with no options, this is > the result: > > thebeast:/usr/src/groff-1.19.1# groff > groff: can't find `DESC' file > groff:fatal error: invalid device `ps' If you want to try out a compiled groff without installing it, you need to run ./test-groff from the build directory. For example, try this: ./test-groff -man -Tlatin1 man/groff_font.n | less That should simultaneously confirm that your build went right and answer your "what is DESC?" question in detail. :-) -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] The quest for a high-end typesetting system: A fewquestions
I'm not sure what the state of the .wdc request is (i.e. if it's been fully tested and is stable). If anyone has experience with it, could they let me know? It seems to work, but requires a little fiddling with paragraph macros. The archives should have a message from me, maybe a couple of years back, about how I got it working. You have to compile with WIDOW_CONTROL=1 set somewhere, turn it on, and make a couple of minor changes to paragraph macros. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] funding for groff hacking?
One thing I would like to see is the original AT&T docs brought into alignment with the current groff. I think it is an embarrassment that the groff docs aren't in roff, that's like using CVS to store the sources to Subversion, it doesn't say much for our faith in groff. I've been threatening to take a crack at that myself. The old texi2roff utility can do some of the work, although for a manual the size of the groff doc, the results were rather ugly. Some of the PDF extraction/reformatting scripts I've written for other projects might be more useful here. Once we have the docs back the next thing is to integrate into the original docs all of the old and new groff extensions. I think groff is much under appreciated. Are you saying, incorporate the AT&T docs into the GNU-troff manual where we don't have text written already? Or am I missing something? One thing I'm trying to track down & document is whether there are Free replacements for each of the 80 or so utilities making up the old DWB, either drop-in or "close enough." Some of the utilities are more or less obsolete or unnecessary nowadays, but it would be nice to have a list showing everything useful is available. Another thing I'd like to see is widows/orphans processing, it is so annoying to have to do that by hand. That might already be done or do-able See http://lists.gnu.org/archive/html/groff/2004-03/msg00124.html The patch I mentioned in the referenced message was added to the source tree IIRC. Some macro hacking might be required to completely implement the feature. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] questions about postscript and tex/latex output
Robert Dodier wrote: (1) The postscript output option (-T ps) puts the stuff between .DS/.DE in variable-width font, although I would have expected fixed width font. Is there a way to cajole groff into considering .DS/.DE stuff to be fixed width font? I haven't tried this, but it should work -- put it at the beginning of your file and see if it works: .rn DS DS-orig .rn DE DE-orig .de DS .CW .DS-orig .. .de DE .DE-orig .R .. That will set everything between *each* DS & DE in Courier, hope that's what you wanted. (2) Is there a way to generate tex or latex output from groff? I suppose, but why would you want to? :-P Seriously, your best bet would probably be to use groff -Thtml (instead of -Tps) to produce HTML output, run it through Tidy to clean it up a bit (I'd use "tidy -asxml" but plain tidy might work too), then convert that to *TeX. Google for "html to latex" (use the quotes for a change!) to find some possible utilities. You could also use doclifter to transform to DocBook then transform that to *TeX, but you'd probably have to do some manual cleanup after each transformation. Hope that helps -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Updated patch: m.tmac
I've rewritten the m.tmac patch to reflect changes in www.tmac. No functional changes beyond the previous patch; it simply marks headings for grohtml and disables headers & footers. m.tmac.patch Description: Binary data -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
Larry K., have you found a new CVS host for the UTP meanwhile? Have you finally announced the UTP on the various lists? Maybe we can find volunteers more easily if more people know of its existence... No, and no. Larry McVoy has offered Bitkeeper, and I'm going to take him up on it once I take the time to sit down and get familiar with it. I got stuck looking for a quote for the release note a while back, and I guess I'll just go with what I have for the announcement. (It's at http://home.alltel.net/~kollar/utp/press-release.txt if anyone hasn't seen it.) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Humor ...
Lars Segerlund wrote: Sorry to waste bandwith, but somehow I found poweroff on my machine, and subsequently tested this powerfull roff :-) ... to think before you type is a good rule :-) ... ( which I obviously didn't heed ). Heh. That was a good laugh -- unfortunately, most of the people who would get the joke are already subscribed to this list. :-P -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] www.tmac patch - lists
I've attached a patch to www.tmac and a test file (for the testsuite) that implements numbered and definition lists. One thing I'm not happy with yet is how list items get wrapped in paragraph tags, like this: blah blah foo I think that's grohtml getting a little too enthusiastic, but I haven't dug into fixes for that one yet. -- Larry www_tmac.tar.gz Description: GNU Zip compressed data ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Argh - updated www.tmac patch
I forgot the documentation update. Use this patch tarball instead. -- Larry www_tmac.tar.gz Description: GNU Zip compressed data ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] TeXifying groff possible?
John Doe wrote: Also I am interested in a list of documents to read in order to familiarize myself with groff more. I know of UTP and the gnu docs as well as Bell docs and I've bought the used book "troff Typesetting for Unix (tm) Systems", what else is to be done? Look at some document markup, especially parts that you like and want to repeat in your own documents. And at some point you need to stop reading and start writing. :-) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Spam from list member addresses
Peter Schaffter wrote: I got two pornographic-sounding spams today, one apparently from Werner, the other apparently from Ted Harding. Rather than wait to see if these are isolated incidents, I'm cut 'n' pasting both emails with full headers into this post. Yup, I noticed they came back in the last few days. Some server along the line has gotten smarter about removing the (presumably viral) payload, though. I'm not an expert in mail header forensics, but someone else may spot something useful. I can read headers most of the time, it comes in handy to track spam back to its injection point. It's the one at the bottom that seems to be the important one: Received: from [194.2.232.250] (helo=199.232.76.166) by monty-python.gnu.org with smtp (Exim 4.34) id 1DH2ik-0007k9-Uq for groff@gnu.org; Thu, 31 Mar 2005 11:40:39 -0500 The one I got had a similar header. The IP address in brackets is the one that's important here. Quoth the "dig" utility: % dig -x 194.2.232.250 ; <<>> DiG 8.3 <<>> -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; 250.232.2.194.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: 250.232.2.194.in-addr.arpa. 1H IN PTR nat.isep.fr. ;; Total query time: 2510 msec ;; FROM: Lapdancer.local. to SERVER: default -- 10.0.1.1 ;; WHEN: Thu Mar 31 21:32:56 2005 ;; MSG SIZE sent: 44 rcvd: 69 % The part we want is the line below the "ANSWER SECTION" -- nat.isep.fr. Querying RIPE's whois (whois -h whois.ripe.net 194.2.232.250) suggests that Kumar Reddy and Gilles Carpentier (first.last at isep.fr) would be the people to contact about what is likely an infested PC on their network. A lot of these parasitic programs work by scanning address books for more potential victims, and often use names from the same address book as the "source" and destination... which suggests to me that someone subscribed to the groff list -- or someone who knows someone (I doubt it's more than one degree of separation) has been infested. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
Jim Reid wrote: I very much doubt if anyone changed groff's build/install procedure with any intent to make it in any way Linux specific; Fact: somebody *did* change the build/install stuff. It used to work on BSD/OS. It had done so since at least 1996. Now it doesn't. To some extent, this specific discussion is now moot because BSD/OS is dead. That said, the wider point about trying to keep groff from falling into a Linux-only ghetto remains valid. I compile groff regularly on MacOS X, which (underneath Aqua at least) is supposedly mostly a FreeBSD userland with a few GNU pieces here & there. I've even made a few minor fixes and enhancements, and Werner hasn't indicated any problems with my patches (except that I forget to use diff -u on occasion :-P). Zvezdan Petkovic says he has built it on OpenBSD. I have to agree with Keith; in my experience groff is easier to compile than many other Free packages of similar size. From what Werner & Larry Jones were saying, it sounds like it might be a compiler bug in BSD/OS. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff for Mac OSX
compilation of groff is more or less without problem (a minor one with the accompaning gxditview, as I recall) from the tarball available at the groff home page, too. Use the following commands to completely replace the installed groff in OSX: ./configure --prefix=/usr --mandir=/usr/share/man CXX=g++2 make sudo make install The "CXX=g++2" part is necessary at least on OSX 10.2.x, and may be necessary in 10.3 and later. Omitting it results in runtime formatting errors, due to a bug in the gcc3 compiler. Some OSX security updates replace groff, so it's a good idea to keep it around to re-install after a routine system update. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff for Mac OSX
Robert Goulding wrote: ... it *would* be good if there were a precompiled binary around - I'm on vacation with a laptop without development tools installed, and would very much like to be able to download a ready-made binary of the latest CVS. When I get back home, I may well do it myself and put it on a webpage somewhere. I've built a .pkg of the 1.19.1 release. All dressed up & needs a website. ;-) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] What's missing for Unicode support of groff?
> The obvious king's path for this is to use GNOME's pango. Obvious? Some of us aren't using Linux, let alone GNOME. > What else is needed to support Unicode on the input side? My suggestion would be to start by picking one of the several UTF-8 preprocessors that have floated across the list lately, and include it in groff. Perhaps it's a little late to do for 1.19.2, but the next update could include it. That should give manpage writers a start and take some of the pressure off Werner, giving him time to really do it right. But Werner is probably going to end up doing most of the work, so it's his call in the end. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Cross references
amber hassan wrote: Please tell me , How do I create cross references in pdf or ps document which enabel movement within a document through mouse clicks Get the CVS version of groff, or a nightly build from http:// groff.ffii.org/groff/devel/ and compile it. The development version includes support (and documentation) for creating PDF files. Hope that helps. If you can't compile your own version, let us know what OS you're running & someone here can probably furnish you with a package. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Type 1 fonts "dead but twitching"
Information I just read on a FrameMaker list I just got back from the Helsinki ATypI conference, where Tom Phinney, Adobe's program manager for fonts and core technologies, basically said that Type 1 fonts are dead (but may take a while to lie down and stop twitching). Adobe hasn't made any new Type 1 fonts for several years - everything is OpenType now. ... Adobe is scratching its head about offering some kind of upgrade for people who have Type 1 fonts but there are lots of problems: not least that most people don't keep their proofs of purchase (and, unsaid, that many people steal fonts). I've kicked around a few ideas about how future versions of groff handle fonts, primarily working with the operating system's native font handling & printing APIs. I've never said anything because I don't have the expertise to code up even a proof-of-concept, and IIRC Linux and other Unix-type OSes often leave font & printer handling to the application. In any case, the current font handler should be at least a compile- time option, because I'm sure it's loads faster than any generalized OS-based handler & there's at least one person out there who depends on groff's raw formatting speed. Could this be kicked to the post- processor? That would be the best of both worlds; choose grops when you value speed over flexibility and gronative (groos? gross?) when it's the other way around. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] moving TOC to start
Jason St Armand wrote: does anyone have any simple methods for placing the table of contents at the start of the output file ? The easiest way is to create your table of contents in a separate run, process it into a groff file, then include it in the file. There are a couple of examples in the archives. -- Larry Kollark o l l a r @ a l l t e l . n e t "The hardest part of all this is the part that requires thinking." -- Paul Tyson, on xml-doc ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] moving TOC to start
> The `XS', `XA' and `XE' macros collect the TOC entries into a > diversion, which is flushed when `TC' is called; to cover the entire > document, this has to come at the end. This is the way `ms' has > always worked, both in groff and traditional troff implementations Just rank speculation, in the way of throwing out crazy ideas... Is there any merit to the idea of diverting an *entire* document and inserting a TOC in the right place just before printing the whole thing? -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] moving TOC to start
> Would it not, perhaps, be better to provide a separate generalised > TOC processing macro module, `gentoc.tmac' say, which could then > be .mso'd by ms, mm, or any other macro package wishing to exploit > its functionality? I *like* this idea. The devil, as usual, is in the (implementation) details. The TOC generation for UTP could serve as a reference, I suppose. Keith mentioned that UTP's system is inadequate for creating PDFs though; I'd like to hear more thoughts on that subject. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Converting groff input to LaTex input?
Robert Marks wrote: > Is there an easy way to convert groff input (using the mm macros, in > my case) to LaTex input? > > I'm aware of tr2latex, but it's now 13 years old, and pre-groff. > (Moreover, it crashes my Mac OS Tiger.) It's kind of a roundabout way of doing it, but you could try using -Thtml and (after cleaning up), use one of several HTML to LaTeX converters to finish the job. If you try it, make sure you use groff 1.19.2 or CVS -- there were several improvements to both grohtml and m.tmac to help them play better together. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
I overwrote the existing groff 1.15 that was installed to the system, so I am fairly certain. However, is there something I can do to test it to make sure? Now, why on earth would you do this This could very well be the source of all your problems. Why are you messing up with the carefully tuned system files. Isn't that a little harsh? I overwrite the default groff installed in MacOS X all the time. I simply built a .pkg file and re-install it when Apple's system updates make it necessary. The important thing is to make sure your build works properly before installing it over the default version. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] slack4, groff and ps
mikkel meinike wrote: I have a very small and old laptop computer with a very small and wonderful linux on it called Basiclinux 3.0. I have for some time bin looking for some word processing program. OK my local lug advice my to try with groff *roff. So now I am here. First I 'd like to know if you know if the groff packages that is in Slackware 4.0 can convert to postscript. (also with the Danish letters æ, ø, å)(I can install slackware 4.0 packages to Basiclinux 3.0) I installed Basic Linux on a 486 some time back, but an older version (1.0, I think?). After installing the gcc packages, I built a current version of groff from source. It worked quite well. The 486 was fast enough to use the Vim text editor, which supports syntax highlighting of *roff. As Ted pointed out, groff will output PostScript (that's its default) and should be able to handle Danish characters. Finally, you may want to download a copy of "Unix Text Processing" (see the URL in my signature) if you need a tutorial. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XSL-FO to groff to PDF?
___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Working down the backlog... I spend my days writing large, complex, highly-technical documents in Word for this reason. It's quite ugly, but we have to have documents that sales people and engineers and such can extract and "repurpose"... And young engineers don't know how to roff any more than the salespeople do ;-( I've been fiddling with OpenOffice lately. It's not a beauty, but it's sturdy and does a pretty good job importing & exporting Word files. I've literally had cases where OpenOffice had better luck with a seriously gnarly Word file than did Word itself. How this all relates to *roff... well, extraction & repurposing of existing documents requires a basic interchange format. It doesn't have to be Word; it just has to be something Word can open and deal with. Like HTML. The output from grohtml is good enough, or can be with just a little help, that Word should be able to open it easily. I just tried opening a test HTML file in OpenOffice 1.x and it actually looked pretty good. Now getting back to groff from ODF, that will take a little more work -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Clarke Echols wrote: ... By learning to use the tools, and nothing more complicated than simple shell scripts (I don't have the skills to get fancy because I don't think they're all that necessary when an easier approach works well), I was able to consistently get more done than any 4-10 people around me without straining myself. This is not to brag, but people waste an incredible amount of time and productivity by not learning to exploit the capabilities of a Unix-like machine instead of really dumb PCs. Amen. I'm lazy too, so I try to let the computer do as much of my work as possible. I once had a boss tell me I was twice as productive as the other two writers put together. While I would argue with the number, it was true that I would script away as much busy-work as possible. And this was on older Macs using AppleScript. Since OSX gave me back the Unix tools I learned so long ago, I've been able to pull miracles out of my... back pocket. Things like sales people asking, "um, can you get the Word file back out of this PDF? Joe Random quit and deleted the doc file." -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
There's a CVS repository for the UTP -- which isn't publicly available currently for unfortunate reasons. This should be moved into the public again -- IIRC, Larry McVoy has offered this a longer time ago. It's up to Larry Koller to proceed since he was (and hopefully still is) the driving force behind the UTP project. ZZ... *snort* Huh? Yes, with cooler weather on the way, it will soon be time to start UTP Revisited. My thoughts were to make the updates necessary for groff-centricity, and add at least one new chapter, "To HTML/ XML and Back" or something like it. I need to get UTP onto bkbits. I had tried doing it way back when it was offered, then I couldn't get on. This was during the time Linux and Bitkeeper parted ways, so I presume some bozo was DOSing the site. It seems to be OK now. So I'll get it put up there & open things up for business. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XSL-FO to groff to PDF?
OK, somehow my entire reply got deleted before I sent it (my copy in "Sent" is also blank). Michael Smith wanted to know if anyone ever thought about a utility to translate XSL:FO to groff. My opinion is that it would be better to skip the translation to FO and go straight to groff, for several reasons: 1) By transforming directly to groff markup based on a macro package (ms or mm, or perhaps a purpose-built package), you can simplify the XSLT enormously, improving readability and maintainability. 2) As groff is a typesetting language, deferring typesetting issues to groff would seem to be The Right Thing. 3) By using command-line parameters, the same generated groff markup could be used to create, say, A4 and USletter versions of a manual. 4) By transforming source -> FO -> groff, you create an unnecessary step. Why not cut out the middleman, especially when he's not adding any value? 5) If your budget or philosophy requires Free Software, the only Free FO processor (FOP) is really inadequate for typesetting -- it's missing things like keep-with, for example. Someone on the FrameUser's list was complaining about that yesterday morning. 6) Groff, as a *roff derivative, is designed to be hand-edited. If you have a formatting crisis with a deadline (and that's when the crises happen, right?), it's a *lot* easier to go in & make a tweak to generated groff than it would be for FO... and then it would probably be easier to find and fix the problem at its source later (see #1). 7) FO is a display language, rather than a content markup language. Personally, I think that defeats the whole purpose of XML to begin with. I can anticipate some objections here, primarily that many popular XML doc types already have XSL:FO stylesheets. But I'm not sure it would be any more work, short-term, to build new transforms directly to groff than it would be to create a groff -> FO utility (which could be done with XSLT itself). Long-term, I'm pretty certain it would be less work to transform directly to groff. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Meg McRoberts wrote: I've been fiddling with OpenOffice lately. In this context, I consider OpenOffice to be equivalent to Word (yeah, I know, at least it's not a proprietary format and all). And that things basically *work* in OOo. For technical documents, I need a lot more flexibility than Word can give. I would like to be able to write a bunch of small docs that could then be sourced into a big manual, mixed and matched. Of course, that's easy to do with *roff. It might be possible with OpenOffice before too long as well. You might be interested in a lengthy entry I wrote on my blog last week, in which I talked about some possible content management scenarios: http://farmanor.blogspot.com/2005/10/laziness-and-open-document- format.html The output from grohtml is good enough, or can be with just a little help, that Word should be able to open it easily. I prefer HTML as an output format from the same source that can also generate PS, PDF, formatted ASCII... It's great to get a technical document into HTML to display on the web but if I want a printed copy, the HTML doc isn't compact enough to be satisfying... Which are all arguments for using groff, of course. Edit and manage individual topics, preferably under source control, pull them together as needed, and create a PDF. If co-workers need a topic or three in a format Weird can deal with, make an HTML file. I really ought to ask our translation vendors if they can deal with markup in ASCII files instead of FrameMaker. Even if they're not doing the DTP end, if they send back translated source in Unicode, it wouldn't be hard to handle. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Which is the *best* editor? The one I know in I know my spine. Or in the case of vi, my fingers. I've been known to write about Un*x topics in a GUI text editor, start jackhammering the 'j' key, and wonder why the cursor isn't moving down. Is anyone collecting the "reasons for using groff" that have been going by in this thread? Such a collection would be a fine beginning to an advocacy/"Why Use groff" chapter in UTP (or a standalone web page). I'd be particularly interested in seeing James Deri send in a write-up about his monster print jobs. (We could put that under a heading like, "Scale THIS!" :-D) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Ted Harding wrote: This is true but very unfortunate IMHO. It isn't very difficult to write a texinfo file, and there are many benefits to do that. I would like to dissent (partially) from this. Me too. However, I have always regretted, even resented, GNU's transition from "man" to "info" for basic reference. ... But, nowadays, many GNU man pages are mere stubs, when they used to be full summaries, and the reader is told to read the info document. I'm sure there are some historical reasons for this... not the least of which being the lack of a Free *roff processor at the time. But given the need to process existing documents, often expressed by various scripts in comp.sources.* (including a subset processor written in awk!), one is left to wonder why the FSF/GNU project waited for James Clark to give the world a true replacement. ... there is something of "1984" about GNU. For instance, though are still far from succeeding, I suspect that the GNU Thought Police really want everyone to use EMACS. And it's not difficult to see hints of that in texinfo! I've actually tried getting into emacs several times. Maybe I'm too old & set in my ways, or maybe the reason there are so many different editors is that people aren't comfortable with the others. And if you're not comfortable in emacs, you won't like info. There are two certain ways for a manpage to annoy me: refer me to an info page, or to a website (especially when I'm not online). As for texinfo itself Sure, it was a good attempt for its time, and as Werner said it has a good indexing system. But texinfo (or more properly, info) is hobbled by its orientation toward character terminals: it can't get anywhere close to what groff can do using tbl or pic. Manpages are (were) oriented the same way, but the flexibility of groff lets manpages move beyond the confines of text-only while still producing sensible output in a terminal. Texinfo is more suited for long documents than short, especially compared to manpages, but I see manpages and long documents as two separate animals anyway. A few months back, I mentioned OmniHelp, a free (LGPL) HTML-based help engine (http://www.omsys.com/dcl/omnihelp.htm). It works pretty well with output from grohtml when split using -P-S4, and it supports indexing and search. Its only drawback is a heavy dependence on JavaScript, but otherwise it seems like a good way to put long documents online. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
Zvezdan Petkovic wrote: And people who tell me that I should use a graphical front-end for XML mark-up are equally clueless. It's not faster at all to move my hand towards the mouse, find the menu, and choose one of 200 DocBook elements just to put a word in constant-width font (as it turns out eventually in PDF, HTML, or any other of DocBook supported formats). Ridiculous. It is a fantastic way to lose the concentration during writing. As I progressed through my manual I diligently tagged each word that should be tagged, got tired of that and ended up basically writing the plain ASCII text just to be able to concentrate on writing. Then I went through a text for proofreading and used my Vim function (bound to a keystroke) to enclose words in tags selected from the narrow vertical buffer with DocBook keywords. I use structured FrameMaker at work to write documentation, and one of the easier ways I've found to get text into it is to paste it into Vim then pipe lines through scripts that wrap blocks of text in tags (lists, sections, and so forth). I then import that into Frame. It works very well, although the technique is probably specific to the writer and the work involved. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
Werner LEMBERG wrote: Oh, this transition is, I think, a few years old :-) As mentioned in a just written mail, info is today quite user friendly even for the non-emacs people. Yes, it has been a while since I tried info, but didn't think it has been several years... my iBook (running OSX 10.4.2) shows info version 4.2. Heh... just for grins, I Googled for "safari man page" and came up with two free Safari plug-ins for reading manpages in the web browser (restoring functionality that Konqueror has had for a while): http://www.bruji.com/bwana/ http://www.atamadison.com/w/kitzkikz.php?page=Sogudi -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
You use a totally different tool (Vim) to help another tool that's supposedly made to help you with XML (FrameMaker). Yes, but in this case I'm using vim (or rather, piping blocks of text into shell scripts from vim) to throw down the essential markup: I can do something like "8!!mks" to: wrap 8 lines of text in , wrap the first line in , and wrap the other lines in . Dealing with character- level markup isn't nearly as automatic, although Vim's XML plugin makes it no more difficult than doing the job in Frame. XML was never intended as an input language for human use but as a *human readable* machine-level data representation. On the other hand, troff, TeX and the macro packages built upon them are low/middle level languages that a human is expected to write and understand. I find the present day fascination with HTML/XML as another manifestation of the proverbial "he who only knows to use a hammer, thinks that every problem is a nail". A good dose of SGML hand-coding should sober up anyone any day. As I understand it, XML is simply SGML minus tag minimization plus Unicode. The first SGML spec was released around 1980, and the tag minimization features were there to make it easier to hand-code. I saw an example that looked like this: Frobnicating the Widget Blah chatter wibble... The DTD, in this case, was designed so that the first element inside is , which is followed by (and other elements). Knowing this, the SGML parser could infer that anything between the and tags is a element and therefore didn't have to be marked as such. Other shortcuts included to close the last open tag. Ideally, people using XML won't have to work directly with markup... thus, tag minimization wasn't considered important. But I agree with Alejandro that *roff is a nearly ideal markup language for hand-coding (I consider *TeX to be too verbose as well). The short commands don't get in your way and let you add markup while you're typing with little or no distraction. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Info versus man
Werner LEMBERG wrote: Second, quite apart from the ideological objections to texinfo and criticisms of the format itself, my real problem is that texinfo is a prerequisite for building the CVS groff, and that a TeX installation is required for building a pdf of the main documentation. [...] Well, this isn't an argument. Developers are expected to use more packages than Joe User. Would it be difficult to add a --without-texinfo configure option, or even check for the right version of texinfo during the configure phase? To me, that seems to be the best of both worlds; build the PDF when you can, and skip it (without aborting make) when you can't. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Info versus man
Keith Marshall wrote: On Wednesday 26 October 2005 9:28 pm, Werner LEMBERG wrote: Am I missing something? For building the info files you need the `texinfo' package but no TeX, and this is a developer's prerequisite I won't drop. Attempting to build from CVS, without texinfo installed, or with texinfo version < 4.8, causes make to abort at the point where the info files should be compiled. Immediately typing `make' again resumes the build, which apparently completes successfully, but leaves corrupt info files in the build tree. A `make install' at this point would appear to complete successfully, but the installed info files would be invalid. Keith is correct. Personally, I think it's kind of sloppy to have that happen; the info files aren't necessary for using groff so I think the Right Thing is to have an option to disable building them. Now I don't blame you for balking; autoconf is a hideous beast & I don't like to poke around in there either. :-) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff wiki?
Ted Harding wrote: On 28-Oct-05 Robert Goulding wrote: ...it seems to me that a wiki for groff would be very useful. ... This is a good idea! I've often thought of putting such things somewhere, for people to consult or to incorporate into more systematic documentation about different aspects of groff. ... I had that idea a while back, but never acted on it or even talked about it. I'd also sound a note of caution, however. My local Linux User Group ( http://www.alug.org.uk ) has had a wiki going for some months now, and it has unfortunately been vandalised on occasion, There are Wiki variants that provide page rollback, diff, and so on, which provide some ways to mitigate WikiSpam, vandalism, and so forth. LyX (wiki.lyx.org) uses one called PmWiki (http://www.pmichaud.com/pub/pmwiki). -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff wiki?
Bernd Warken wrote: There is a wiki page with an article on groff: http://en.wikipedia.org/wiki/Groff. There's a troff page, with a very familiar-sounding history, at http://en.wikipedia.org/wiki/Troff It is quite small. The German version http://de.wikipedia.org/wiki/Groff is different and much larger. Strangely enough, it comments `lbl' as supported preprocessor. I'll bet that's a typo & it's supposed to be "tbl" instead. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] "creep" and booklets
I'd welcome views and contributions about the following. It concerns making a "booklet" out of a PS document. Which is called "imposition." See http://en.wikipedia.org/wiki/ Imposition You can easily do this by manipulating the PostScript file. The Perl script below suffices. [8< snip >8] Nice little script. I could have sworn there was already some Free software that would compensate for creep -- in fact, I mistakenly thought psbook or psnup could do it. But if it's that easy In the commercial realm, Quite Imposing (quite.com) is popular. I'll take Free tools and a command line any day, though. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] "creep" and booklets
Having got your signatures, they then need to be attached together. For this, it's not ideal if each signature was stapled. Any recommendations for (a) making the central attachment for a signature instead of stapling; Use a thread binding. It's not that difficult to do as soon as you got accustomed to it. Of course, this isn't something for mass production on the kitchen table. I expect you would need some incredibly strong needles and perhaps some tools to help push it through the paper. (b) binding signatures together? Bookmaker's glue. Producing a good binding needs craftsmanship. For which you need a binding press. I have a copy of a PDF showing rough plans for a DIY binding press on my computer at work, but the my VPN client is flaked up at the moment. If someone sends me a reminder Monday, I'll dig it up & post it. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Book vise/binding press (was Re: [Groff] "creep" and booklets)
I couldn't find the PDF on my computer... but I had better luck finding the original in Google -- it was from a Linux Gazette article. The article includes notes that make the PDF more understandable (the link to the PDF is at the bottom of the article). http://linuxgazette.net/issue47/nielsen.html The article also mentions a utility called "mpage" that handles all imposition chores with one command. It doesn't compensate for creep as far as I can tell, but if you use a 4-page (one sheet) signature, you can ignore both creep and sewing issues. http://www.mesa.nl/download.html -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff Wiki
Heinz-Jürgen Oertel wrote: It was discussed that having a groff community Wiki would be valuable. ... I just configured it as a groff Wiki. It can be reached at http://www.port.de/cgi-bin/groff I've thrown a couple of suggestions into AddTopics and finished out the list of standard macro packages (added man & mm). Oh, and the "how-to" link is dead... or rather, moved to http:// awkiawki.bogosoft.com/cgi-bin/awki.cgi/HowToWriteAwkiAwki The topics I suggested -- GroffExtras and GroffTips -- could be initially populated with emails from the list that I've saved into folders of the same name... pending author permission, of course. If anyone wants to reprint an email of mine to the wiki, that's fine with me. And it's only fitting that the wiki itself is written in awk. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] UTP_book
mikkel meinike wrote: > Is it possible to format/compile the book UTP one chapter at a time, > so that I get one ps file for each chapter if yes what is the command > that I need for doeing this. make ch01 make ch02 ...etc... -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Syntax highlighting on Mac OSX
Robert Ullrey wrote: I am writing to see if anyone on the list has written a syntax highlighing code for groff, trogg, roff, mom for any of the GUI applications on the Mac OSX platform. Currently I use aquaemacs which does have it, but would like to write in SubEthaEdit or TextMate. Vim for Mac (both Gvim and the vim shipped with Tiger) support syntax highlighting for general groff. There's a Java editor called jEdit that (I think) also can do it. Having vi codes programmed into my fingers over 20 years ago, I tend to not bother with other text editors. ;-) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [GROFF] Groff wiki?
Robert Goulding wrote: Has there been any movement on the groff wiki? Yet more interesting snippets and tips have been posted recently - it would be nice to preserve them somewhere accessible! I've been adding the tips and other goodies I have archived -- in fact, I had intended to point people to a "fonts" HOWTO that I put together a couple days ago. It could probably use a little attention... if you see something that needs to be added or fixed, click the "Edit" link at the bottom of the page and fix it! http://www.port.de/cgi-bin/groff/ConvertingTrueTypeFonts (PostScript too, obviously) BTW, I used the procedure described above to "port" the DejaVu font family to work with groff. I was thinking about setting UTP Revisited in DejaVu Serif when we get started on it (which can be any time "we" are ready). If you don't want to bother with converting the fonts yourself, I've batched up the whole thing and put it at http://home.alltel.net/ ~kollar/groff/dejavu-22-groff.tar.gz (3.2MB). Untar it in /usr/share/ groff; it puts everything in site-font/devps. You'll have to rename the "download.dejavu" file to "download" or cat it to the end of the current download file. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: groff + mp
What is the real state of the troff land? What are the other players beyond groff? Some people still use the now defunct troff version of QuadSoft (many syntactical extensions implemented in groff resemble its format), many use Sun's troff (based on AT&T), and others rely on Plane 9's troff (based on AT&T, but extended to work with Unicode, more or less, IIRC). There are other troff implementations too, but AFAIK they are all based on the old AT&T troff. Interesting. How many of those are in active use, beyond formatting manpages, I wonder -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Fwd: [Groff] Re: begin page blues
(Sorry Peter, I meant to send that to the group...) When I was a youngster (yes!), device independence and pre- and post-processors were good ideas and necessary. I wonder whether it still is the case. For me: definitely yes. I concur. Yes. You have PS/PDF and plain text (usually for man pages), but there's also a need for HTML (which grohtml handles). Groff gives the best of both worlds -- the flexibility of adding whatever front-ends and back-ends are needed, but mostly hiding it all behind the "groff" command. This sounds very much like the idea that was fielded a while ago, namely a WYSIWYG-style front-end that generated groff-formatted source documents. I suspect groff would benefit from something like this--a sort of LyX for groff. ... However, I noticed that the idea died. Not sure if it was for lack of interest, or lack of skills and time in the development community. A combination, perhaps. I've played around with LyX, and I believe it is possible to write an exporter that would produce some flavor of groff -- the problem there is, what flavor do you pick? Do you aim for a vanilla macro set, add extensions, or strike off on your own? Once you make a choice that equally dissatisfies everyone, actually writing the exporter should be trivial by comparison. :-) No chance. Youngster don't use groff at all. It's way too uncool, isn't it? :-) Actually, I'm finding the opposite. I've been asked to give a talk about groff and the mom macro set to the Ottawa/Canada Linux Users Group, which is composed mostly of "youngsters". Conversely, I've noticed that it's people in their forties and fifties, accustomed to word processing, who think the whole text processing philosophy and implementation isn't sufficiently cool for their tastes. Hm. I'm 47, but I've spent the last 20-odd (and I do mean odd) years doing technical writing. I'm actually getting fed up with FrameMaker's limitations (and it's pretty much the best of the WYSIWYG lot) & have started porting one manual I'm working on to groff. If the translators don't have a coronary when they see the source files, I'll do more. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] unicode support - where to compose?
Werner LEMBERG wrote: Independently of this I think I think it would be a nice idea to extend afmtodit so that it supports `CC' (and `PCC'). ... Do you want to work on this? On the other hand, it's probably not worth the trouble since AFM files with `CC' directives are rare (and AFM is dying out anyway). How much work would it be to hook into whatever system-wide printer drivers there may be? This is something I've been pondering for a while, and I don't even have a clue how gtroff figures out glyph widths (is there some communication between gtroff & the postprocessor?). It would be nice to have access to all the TrueType and PostScript fonts installed on the system without having to build metric files and so forth. If I were to poke at this, where would I start? -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] unicode support - where to compose?
Werner LEMBERG wrote: ... how gtroff figures out glyph widths ... gtroff reads the metric files (in the devXXX directories) for the given device and positions the glyphs accordingly. The postprocessor just translates the intermediate output file into device-specific data -- no need to access the glyph metrics again. Aha... that makes sense now. It would be nice to have access to all the TrueType and PostScript fonts installed on the system without having to build metric files and so forth. This is virtually impossible IMHO. You need a tight integration between groff and the OS, making it highly system-specific. I don't know about that. Instead of reading the groff metrics, gtroff could perhaps query the system for metrics. Grops might not even have to do anything different. It might even be possible to make the source (mostly) backward-compatible by associating a groff-style font name with a real font name (e.g. TB with DejaVuSerif-Bold); versions that don't support the request would fall back to Times-Bold. The code to get the metrics would obviously be system-specific, and the Free operating systems would have to go even further and have WM-specific code (say, for Gnome or KDE)... which would be a problem when moving around. If I were to poke at this, where would I start? In case you really want to invest some time I suggest that you think about an improved `make install' (or `make font-install') which checks the system for fonts and calls FontForge, afmtodit, etc., to convert them to something groff can understand (this is, PFA+AFM). Today, disk space is abundant, and fonts are rather small, so this is the route to go I believe. Hm. I see the logic in that. It would certainly be a lot easier to do, given the currently amorphous state of font management on the Free OSes. FontForge would be a good choice of conversion utilities since it runs on the same platforms as groff does. But instead of driving it through make, I think a separate utility might be a better route -- each user will have to tell the converter *where* to find the fonts, because they live in different directories on each OS (and in the case of MacOSX, there are two system-wide font directories and each user can have his/her own set of fonts as well). I'll look into this a bit later. I'm currently setting up some infrastructure for UTP Revisited so those who are interested can get started soon. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://home.alltel.net/kollar/utp/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Manuals in pdf format
> Miklos Somogyi wrote: > >>>The simplest thing to do is to use 9 after viii, not 1. >> >> This is against all rules of typography. > > I have seen quite a few pdf books/manuals that are against all rules of > typography, e.g. ... > > This "i, ii, ..., 1, 2" system was all right in the age of paper 'cause > any-one page had only one page number. > In the age of pdf one has two numbers to describe the same thing. > Clickable links are good, very good, two numbers for the same thing is > perhaps not. You can set use the /PAGELABEL PDFmark so that the PDF's idea of page numbers match what's printed in the headers and footers. You would put something like this at the top of the page: [ /Label (iii) /PAGELABEL pdfmark This kind of thing should be easier in general, but I think if you're using the mspdf macros, I think it's as simple as defining the HD macro: .de HD . pdfmark /Label (\\n% /PAGELABEL .. I haven't tried this yet, but it ought to work. If it does, it's one more thing that's trivial to do in groff that's much tougher to do with "modern" graphical tools. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff_ms manpage patch: missing header/footer info
Werner LEMBERG wrote:
The groff_ms manpage doesn't describe the header & footer macros
(HT, PT, BT). I've attached a patch containing brief descriptions
of each.
Thanks, applied. Please do the same for groff.texinfo.
Here's the patch.

--
Larry Kollar k o l l a r @ a l l t e l . n e t
Unix Text Processing: "UTP Revival" ("UTP Revisited" beginning soon!)
http://unixtext.org/
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Both Headers AND Footers with Mom Macros
Peter Schaffter wrote: ---End recipe for getting both headers and footers--- You should probably copy that to the Groff Wiki I'm interested to know how you intend to use the combo of headers and footers. If your situation is a common one, I may macro-ize the above to save other users the trouble. Commercial documentation uses both headers and footers pretty often -- in over 20 years of technical writing, I can't remember seeing a "house style" that *doesn't* use both. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff_ms manpage patch: missing header/footer info
Werner LEMBERG wrote: The groff_ms manpage doesn't describe the header & footer macros (HT, PT, BT). I've attached a patch containing brief descriptions of each. Thanks, applied. Please do the same for groff.texinfo. Here's the patch. Not yet :-) THAT was weird. Let's try this again.  -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] groff_ms manpage patch: missing header/footer info
The groff_ms manpage doesn't describe the header & footer macros (HT, PT, BT). I've attached a patch containing brief descriptions of each. -- Larry msman.patch.gz Description: GNU Zip compressed data ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] pdfroff broken?
Running "make" on the CVS, I get this: [everything OK up to here] rm -f pdfmark.pdf export GROFF_COMMAND_PREFIX; GROFF_COMMAND_PREFIX=''; export GROFF_BIN_DIR; GROFF_BIN_DIR=/Users/larry/Projects/groff/src/roff/groff; export GROFF_BIN_PATH; GROFF_BIN_PATH=`echo /Users/larry/Projects/ groff/src/roff/groff /Users/larry/Projects/groff/src/roff/troff /Users/larry/ Projects/groff/src/devices/grops | sed -e 's| *|:|g'`; ./pdfroff -F/Users/larry/ Projects/groff/font -F/Users/larry/Projects/groff/font -M. -M/Users/larry/ Projects/groff/tmac -M/Users/larry/Projects/groff/tmac -dpaper=A4 -P-pA4 -mspdf --stylesheet=./cover.ms pdfmark.ms >pdfmark.pdf AFPL Ghostscript 8.53: Unrecoverable error, exit code 1 larry% ls -l contrib/pdfmark/pdfmark.pdf -rw-r--r-- 1 larry staff 1955 Mar 1 09:14 contrib/pdfmark/pdfmark.pdf The PDF has no content. MacOSX 10.4.5, configure line is "./configure --prefix=/usr --mandir=/usr/ share/man" (adding "CXX=g++2" is not required for 10.4.x) if that makes a difference. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pdfroff broken?
I did "make clean," updated, did a configure & make, and everything seems to be working properly now. Sorry for the false alarm. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] tbl: Standard column width?
Daniel Leidert wrote:
I would like to know, if there is a standard column width, when I use
the .TS macro? The problem is, that the result of the following
code is
wrapped text in the second column (independent from MANWIDTH), even
if I
use expand:
.TS
expand allbox;
ll.
T{
"0x1000"
T} T{
Disable AGP 4x (forces 8x).
T}
T{
"0x2000"
T} T{
Disable AGP 8x (forces 4x).
T}
.TE
The second column is always wrapped after 22/23 chars [1]. Is this
intended behaviour?
I'm sure there's a formulaic reason for tbl to do the things it does,
but I've never gotten curious enough to root around in the source and
figure out what it is. :-)
But for short entries like you have in the example table, you could
eliminate the T{ T} constructs and get it to work:
.TS
expand allbox;
l l .
"0x1000" Disable AGP 4x (forces 8x).
"0x2000" Disable AGP 8x (forces 4x).
.TE
One thing I have noticed, when you don't use T{ T}, tbl won't wrap
even if the row runs off the end of the paper.
--
Larry Kollar k o l l a r @ a l l t e l . n e t
Unix Text Processing: "UTP Revival"
http://unixtext.org/
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pdfroff broken?
Larry Kollar wrote: I did "make clean," updated, did a configure & make, and everything seems to be working properly now. Sorry for the false alarm. But then a trivial change to pdfroff.ms broke it again. I guess I should bite the bullet, install it, and see if that takes care of it. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Adding fonts to groff -- instructions?
Ted suggests adding the font to /font/devps/DESC (see below). What is the purpose of this? I haven't done it and things seem to work, but perhaps I'm missing something. Agreed -- if you add your fonts to /usr/share/groff/site-font/devps, then you don't have to worry about them getting stomped out when you upgrade. Also, I see the AddingFonts instructions I wrote for the Groff Wiki got completely replaced -- were they totally wrong or what? -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pdfroff broken?
Keith MARSHALL wrote: Larry Kollar wrote, quoting himself: I did "make clean," updated, did a configure & make, and everything seems to be working properly now. Sorry for the false alarm. But then a trivial change to pdfroff.ms broke it again. pdfroff.ms??? That isn't one of the distributed files; do you mean pdfmark.ms? If yes, what trivial change broke it? Was it a `make' that failed? If not, what was the failing command? You're right, pdfmark.ms. I need to not post when I'm frustrated. :-P The change I made was to define .HD at the top of the file as follows: .de HD . pdfmark /Label (\\n% /PAGELABEL .. The intent was to test my theory about setting PDF's page numbers to match the current page number (i.e. if you're in the TOC, the page number should be "iii" or something similar). Then I did "make" and it gave me the same "gs 8.53 failed" error as I had before I reloaded. Backing out the change and "make"ing gave me the same error. It's like you can only do it once. I guess I should bite the bullet, install it, and see if that takes care of it. Perhaps. But it really should run within the build directory, if the environment is appropriately configured. Agreed. If I get a chance, I'll figure out how to make gs/ps2pdf get ultra-chatty about what it's doing and hack pdfroff accordingly. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Adding fonts to groff -- instructions?
Heinz-Jürgen Oertel wrote: Also, I see the AddingFonts instructions I wrote for the Groff Wiki got completely replaced -- were they totally wrong or what? Larry, wasn't it http://www.groff-wiki.info/ConvertingTrueTypeFonts D'OH! You're right. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: [Fwd: Wrapping Text Around Pictures]
Frank Jahnke wrote:
I'm sending you a copy of a message I attempted to post to the groff
group. When I have done this in the past, I have received a
notification from the moderator that my message was being reviewed
before it was released. This time, though, I have not received this
notification, nor has the message been posted.
Has something changed with policies governing posting to the
group? Or
did this fall into a crack?
I'm not sure -- the list has recently moved from ffii.org to gnu.org,
you
already know that because you sent the email to the right place. Maybe
you need to subscribe (or re-subscribe). Werner, do you have any
further insights?
Thanks for your attention to this. And if you have an answer to the
question, I would most like to learn how to do this.
How does one go about wrapping text around pictures that do not occupy
the entire line width? PSPIC does not seem to do this, and MPIMG does
not seem to be available with the -ms macros that I normally use.
Output will be to Postscript/PDF. Any advice would be most
appreciated!
It has been a long time since I attempted something like this, but
I'll throw out a couple of ideas that might or might not work & perhaps
other listers have some insights. I'll try them later & post it to
the Groff
Wiki if they work. Searching the list archives didn't turn up anything
obvious, and there aren't any simple ways that I'm aware of. So...
The brute force method (assuming ms macros). This could probably
be built into a macro.
.\" --
.\" not tested - adjust as necessary for graphic width
.de NoWrap
.nr PO \\n[OLDPO]
.po \\n[PO]u
.\" cancel the trap...
.wh \\n[Endofpic]
..
.\" some time later
text text leading up to the graphic text text...
.mk
.PSPIC -L foo.ps 2i
.\" remember where the bottom of the pic is...
.nr Endofpic \[nl]
.\" back up to the top of the pic...
.rt
.\" ...and move the margin over until we get past the picture
.wh \n[Endofpic] NoWrap
.\" Need the following in case there's a paragraph break
.nr OLDPO \n[PO]
.po +2.25i
.nr PO \n[.o]
text getting set alongside the graphic,
automagically returning to the left margin
once past the graphic...
text text
.\" --
The tbl method. Unfortunately, this method won't automatically return
to the left margin.
.\" --
.TS
expand;
lw(2.1i) l .
T{
.PSPIC -L foo.ps 2i
T} T{
text text text
T}
.TE
.\" --
--
Larry Kollar k o l l a r @ a l l t e l . n e t
Unix Text Processing: "UTP Revival"
http://unixtext.org/
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: Re: [Groff] Re: [Fwd: Wrapping Text Around Pictures]
>> the MPIMG macro should be available via the -mwww >> macroset, which should also work with Postscript. > > Yes, I am aware of the www macros. The document I'm > writing is quite long, is full of -ms macros > This does not really seem like > the use for which -mwww is intended. Actually, -mwww co-exists well with -ms -- I completely forgot about the MPIMG macro. One of these days, I'll finish a paper I started that discusses using -ms & -mwww to create single-sourced documents that produce both printed/PostScript and (fairly) clean HTML. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Inserting/importing jpeg photos into groff text?
Clarke Echols wrote: I need to place a jpeg photo inside a groff document. I am running cygwin on Windows 98, and there is no indication that the convert utility is available in the Cygwin packages; at least none that I can find... Is there an easy way to get jpeg photos into a groff document that I have overlooked? You can use netpbm; it's in Cygwin. The pipeline to make your conversion is: jpegtopnm foo.jpg | pnmtops > foo.eps This actually produces EPSF, which I think groff has no problem with. If you prefer the convert utility, their page - http:// imagemagick.org/ - links to a binary that should work for you. Hope that helps! -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Anyone have a good -ms cheatsheet?
My daughter (high school age) is getting fed up with AppleWorks and TextEdit for writing reports, and is ready to try something new. I remember depending pretty heavily on a cheat sheet in my first little while with *roff, 20+ years ago. So before I re-invent the wheel, has anyone done it already? Thanx! -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] (no subject)
___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] gtroff & soelim don't recognize ~ in paths
Sourcing a file like this: .so ~/Library/XSL/html2ms.xsl Using either straight groff or soelim, I get the message: ./single.ms:207: can't open `~/Library/XSL/html2ms.xsl': No such file or directory It works with an explicit path. Is this a bug or a feature? -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] gtroff & soelim don't recognize ~ in paths
Werner LEMBERG asked, perhaps rhetorically: Why on earth do you expect tilde expansion within groff? I'm used to it working in vi(m) and I seem to remember it working in awk. I've also seen it work in X11-based file dialogs. Over time, I suppose I've come to assume that ~ was a Un*x idiom rather than a shell idiom. Do this instead: .so \V[HOME]/Library/XSL/html2ms.xsl That should do it -- thanks for the pointer. I really need to get a cheat sheet together.... -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] gtroff & soelim don't recognize ~ in paths
Miklos Somogyi wrote: Ditto. Environment variables too. Everything valid to the shell, should be valid to groff. Why? User convenience. Shouldn't this be consideration No 1? Slight problems: which shell, what OS? That's exactly the point. I can't believe I'm the first to mention this as a problem in 35 years of *roff's existence. But with groff being cross-platform, ~ might not mean anything to a W32 user. I think using \V[HOME] to pull the home directory from the environment is reasonably portable. I would rather pay for a thoroughly modern implementation of troff that only inherits the wonderful original ideas but not the constraints of the original times. Well, groff eliminated what I would consider the biggest constraint of the original: the two-character namespace. The second biggest is Unicode support, and that has both a current workaround and a real fix in CVS. Other things like TOC, Index, cross-references, and bitmap graphic support are supported through long-established workflows, without excess baggage where such things aren't needed. What do you see as major constraints with groff at this time? -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] gtroff & soelim don't recognize ~ in paths
Tadziu Hoffmann wrote: **] And remember there is one fundamental design difference between groff and TeX: TeX has exactly *one* "device" (in groff parlance), and we expect exactly the same output in all implementations. Groff has never had that aim. On the contrary, output is explicitly device dependent (let's say "device optimized"). Why not generalize this and allow differences even for the same device on different installations? If you want people to see exactly what you have, send the the finished, formatted output (text, PS, PCL, whatever). If you send them the source, expect them to edit it and get different results anyway. IMO, this is precisely why groff works so well even today -- the designer's dream of getting exactly the same output on different devices [in the groff sense, not two PostScript printers] is a chimera that has led to all sorts of problems for technical writers who often *have* to publish the same documents as (usually) PDF and HTML. I like that phrase, "device optimized" -- it recognizes that different publishing media work differently. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Need some troubleshooting help
Good to see you again, Michael! > I've a wierd problem I'm trying to track down. Hopefully my > explanation will make sense. First, some software versions: > MacIntosh OS X version 10.4.5 running groff 1.19.1 and gv 3.6.1 Is that the version of groff that ships with OSX? Things *should* have changed for the better, but it used to be that recompiling groff was necessary to do anything besides format manpages. > Linux Slackware version 10.2 with a 2.4.29 kernel, groff 1.17.2 and > gv 3.5.8 > The printing mechanism on the Linux box is LPRng version 3.9.0 > with ifhp-3.5.11 I don't think it matters, but what version(s) of Ghostscript are you using? One of the most outstanding things I see in the diff file is that the 1.19.1 version is specifying a default page size while the 1.17.2 version isn't. I wonder if the printer or the print daemon is getting confused by that. One thing you might want to try, convert the output to PDF (using ps2pdf) before sending it to the Linux box -- gv should be able to open and print it. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Need some troubleshooting help
Michael Parson wrote: I just checked my 10.4.6 install and the shipped version of groff is 1.19.1 and it does default to A4 paper size. Specifying - dpaper=letter on the command line does not work properly either... Keith pointed out the workaround for that. You could also edit the file /usr/share/groff/1.19.1/font/devps/DESC and change the line that begins with "papersize" to read "papersize letter" for a permanent fix. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] www.tmac patch (PIMG functionality)
Calling PIMG without an alignment option (-L, -R, -C) would create all sorts of problems. The following patch is probably not the most efficient way of fixing it, but it does the job. Gaius, could you test, perhaps improve further, and commit this? www.tmac.patch.gz Description: GNU Zip compressed data -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Generating HTML / XML
Gaius Mulley wrote: Thanks for the quick reply. W.r.t. your question below, I like making "the www macro set initialise post-grohtml with the correct set of tags for headings, titles, preformatted text etc." Sounds great to me. ok, I wonder whether it could be improved if say the www.tmac told post-grohtml which tags to use together with a tag priority (similar to operator precedence) - which post-grohtml could then determine if a tag should be nested with the current tag stack or whether the current top of stack tag should be popped.. This modification _might_ allow post-grohtml to be emit trivial XML or any tag based output (well in basic form anyway) I gave this idea (turning grohtml into a general groxml post- processor) some passing thought a while back, but never really developed it to the point where I felt it worth sharing. The idea I had was to make tag generation table-driven, similar to what AT&T nroff used for printer drivers (I wrote one for the NEC SpinWriter back when). The default table would still generate HTML, and probably live in the (version).tmac directory. An alternate table (for DocBook, DITA, OpenDoc, or whatever) could be specified with a command-line option, and live anywhere along the GROFF_TMAC_PATH. In the meantime, unless you have specific needs, grohtml produces HTML that can be cleaned up fairly easily & then transformed to something else. You can add a layer on top of ms/mwww to produce more customized output or add CLASS-based hooks for transformation. Here's an example: .\" format MIB variables .de MIB .ie '\\*[.T]'html' .HTML \\$3\\$1\\$2 .el \\$3\f[HB]\s-1\\$1\s0\fP\\$2 .. For character-class formatting like that, a character-level tag (like B) gives you a fallback format if the CSS goes missing or a browser doesn't support it (or the user turned off CSS). Of course, you can use SPAN if you want the fallback to be plain text. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Survey on Document Creation Software
groff/troff/nroff is languishing even against KOffice and GNOME Office (AbiWord etc), at only 2% (37 votes). We're not going to knock off TeX, but surely readers of this list are more numerous than that! Go to http://www.cups.org/ to vote for your favourite. Well, with 52 votes just now [3%], groff now weighs in at No 3 (after OpenOffice with 878 [53%] and TeX with 507 [31%]), if one excludes "Other Commercial". I'd think we would finish a stronger third than that. Maybe we're not the poll-freeping types? Maybe someone ought to create a poll for that. :-P I'd guess the "Other Commercial" is mostly split between Weird and FrameMaker. Kind of hard to tell, since "Other Commercial" is the *only* choice for commercial software. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] www.tmac patch (PIMG functionality)
Gaius Mulley wrote: have done, I've altered in certain places - mainly to fix the HTML generation of aligned images and to retain the @[EMAIL PROTECTED] Great! It just occurred to me, looking at the latest update, that changing "pngtopnm" to "anytopnm" would allow placement of GIF and/or JPEG images as well as PNG... seems like older graphical browsers also would do XBM, but I don't know if they bother nowadays -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] on MacOSX (was: Odd problem escaping `.')
Joerg van den Hoff wrote: well, MacOS is commercial and they seem to be reluctant to update things like, e.g., rsync or groff as fast as they could [...] Apple updates it when there's a security-related issue. I install groff in /usr/bin, wiping the Apple-supplied version... which means that when Apple releases a patch with a groff fix, it wipes *my* version. Unfortunately, they erase site-font and site-tmac as well -- so if you make use of those directories, keep a copy in your home directory or somewhere else where it won't get stomped. The upside is, Apple generally lets you know when they're updating (i.e. replacing) groff in a patch, so you have some fair warning if you look at the update info. But now that I have finally gotten around to using groff for real work projects, I find myself a little more reticent to install the latest CVS -- even though I made a 1.19.1 package & keep it handy. I probably should make a 1.19.2 package too; I'm using a lot of the latest stuff (PDF, grohtml) and need more. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Suggested tbl enhancement
I tried poking at this once & got stuck... Anyway, it's kind of surprising that there's no "pointsize" global option for tables. I guess the typical workaround is to bracket the table with .ps requests. If anyone is bored enough to take a crack at this, I'll be glad to test it. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Some levity: How the other side does graphs
This turned up today on a FrameMaker list I'm subscribed to. Oh yeah, minor detail, you need Acrobat (not just Reader) to crop the drawn graph then re-import it. And I thought this GUI stuff was supposed to make things easier? Im talking about graphs where both the horizontal and/or vertical axes have a linear array of marked values, and the axis lines extend across the graphic. In other words, the background of the graphic looks like a FrameMaker table in which , consisting of rows and columns in which all columns are of equal width, and all rows are of equal height, using the minimum row height setting in the Row Format dialog. All table cells are empty. Here's the procedure: 1. Create a new document in which the right master page has a text frame of the desired width and height. and super-impose on top of that text frame a background text frame, and create the table (as described above) in that background text frame. Be sure to include an extra appropriately sized column on the left side of the table. This column should straddle all rows, and be wide enough to later label the title of the vertical axis, as well as space to put in tick-marks and numbers for each horizontal line in the table. Similarly, create a straddled row at the bottom of the table high enough to later enter the title of the horizontal axis, as well as space to put in tic-marks and numbers for each vertical line in the table. 2. When you are finished creating the empty table, send the bacground text frame to the back. 3. Go to page 1 of the new document. The table you created in step 1 appears. 4. First, you use the FrameMaker text and line-drawing tools to enter the titles, numbers and tic-marks for the harizontal and vertical axes in the the column with straddled rows, and and the row with the straddled columns3. 5. Next, use the drawing tool dwaring tools (curve, polyline, or whatever else0 to draw the graph lines. and smooth or reshape them as needed. 6. Save the 1-page FrameMaker document as a PDF with an appropriate filename. 7. In Acrobat, open the PDF produced in step 6, and use the Acrobat crop tool to crop the page to the size of the graphic image. and then re-save it. 8. Within any document where you want the graph to appear, import the PDF produced in step 7 by reference or copy, as appropriate. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: Re: [Groff] Suggested tbl enhancement
Werner LEMBERG wrote: > > It sounds like a good idea, but there are so many potential > > enhancements that would make tbl easier to live with that it's > > almost worth a rewrite. > > Hmm, can you post a TODO, please? My short list is primarily cosmetic (the goal is to require a minimal amount of primitive markup) and there are workarounds to most of them. 1 HTML support (would probably require changes to the groff wrapper to pass a command-line option to tbl for -Thtml) 2) Global point size option 3) Rotate option for -Tps (a built-in version of http:// www.port.de/cgi-bin/groff/RotateTables more or less) 4) Conditional global options and formats - if you're using the same info in a different document, for example > Additionally, I ask you to further test Joachim's `HDtbl' package > > ftp://ftp.uni-heidelberg.de/pub/HDtbl/0.91 The introduction is here, if anyone wants to see what it's doing: http://lists.gnu.org/archive/html/groff/2005-12/msg3.html > I'm going to include this soon (after I've released a new FreeType > version). H looks like two of those pesky TrueType hinting patents are going to expire on Monday. Is that the reason for the new version? -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Another small www.tmac patch
This patch provides PORPHANS support (if the register has been defined) for list items. Amazing, the little nits you find when you start using this stuff in the Real World. :-)  -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Meeting Werner
M Bianchi wrote: It was great to read the interview with Werner (our Fearless Leader?). What an interesting story! It is good to "meet" you, Werner. Agreed! Here I was, thinking Werner was primarily a math student instead of a musician. That's actually pretty cool. Now all we need is a Groff Anthem to be sung at the next International Groff Confernece ;) A Groff Anthem? That should be interesting. Maybe a variation of "Sing Hosanna," which would naturally start "Sing Ossanna" -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Inline evaluation of calculations?
I was wondering if there was a way to, for example, print the result of \n%+1 without using a junk variable. I didn't see a request equivalent to "eval" in the manpages or the texinfo thing. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Another small www.tmac patch
Werner LEMBERG wrote: This patch provides PORPHANS support (if the register has been defined) for list items. I don't see a patch. Please repost. The mailing list ate my attachment. :-) (A common schoolboy excuse in the US is "the dog ate my homework.") www.tmac.patch Description: Binary data -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] The permuted index from Hell
So I got this bright idea to build a permuted index for the MIBs we support in our products at work. It might be helpful for customers who are trying to figure out which MIB object would have the information they're looking for. So I grabbed the textutils package and built it, checking over the documentation several times, installing an "eign" file in the right place, and adding the #define to the ptx source code so it will *find* the ignore list. Then once I fed some sample data in, I figured out which options I needed (settling on "ptx -frRO -F '...'"), then wrote an awk script to pull what I wanted out of the MIB files. After a bit of debugging, and writing a Q&D ".xx" macro to format the index, I was ready to see what I had. What I had was 253 pages of 8- point text, formatted properly. Back to the drawing board, I guess. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] The permuted index from Hell
Werner LEMBERG wrote: >> What started that was my early experiences with unix where I went >> to the permuted index and looked for "rename a file". I was not >> plesed when the only thing I could find is the rename(2) system call. > > For groff.texinfo, I manually add permuted index entries. I really > doubt (as others do on this list) that it can be done automatically in > a sensible way. Very true. Indexing is actually a specialty profession, best performed by someone who *isn't* the writer of the document. Unfortunately, there isn't a lot of budget for hiring indexers in the Real World, and even less of one elsewhere, so we have to resort to tricks like permuted indexes and systems like that in CSTR 128. They often end up substituting quantity for quality, but usually it's better than nothing -- and "nothing" is exactly what you would get otherwise in most cases. On the other hand, a good permuted index can show relationships between topics that you might not have seen before, or show you things you didn't know existed. As a dry run for the MIB permuted index (which I reduced to a "mere" 198 pages after adding some unnecessary keywords to the ignore list), I did one for the (1) manpages on my system (MacOSX) and found several utilities I didn' t know about but could be very useful. Clarke's example, which I remember reading about before, leaves me shaking my head though. It's a perfect example of why one should always concentrate on creating a good "Name" line in manpages; that and the See Also blocks are the two most likely candidates for extraction & processing. Rather than being a "neat" solution, I find it rather sloppy (of AT&T). And please, other GNU projects, could we have something more out of your manpages than a list of command-line options and "see the info file"? If we wanted to see the info file, we would have gone there. Grumble. Off to improve the ptx(1) page -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Sun's troff now available
I stumbled across this today, and didn't see anything about it in the archives. http://heirloom.sourceforge.net/doctools.html "The Heirloom Documentation Tools package provides troff, nroff, and related utilities They are portable and enhanced versions of the utilities released by Sun as part of OpenSolaris, which are a variant of ditroff, which, in turn, descends to the historical Unix troff that generated output for the C/A/T phototypesetter." There might be something worth cherry-picking. :-) -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Sun's troff now available
Joerg van den Hoff wrote: Larry Kollar wrote: I stumbled across this today, and didn't see anything about it in the archives. http://heirloom.sourceforge.net/doctools.html that's rather interesting! installation is a bit funny: you have to edit `mk.config' and set lots of dirnames manually (no configure) but then `make; make install' (you need a ucb compatibel `install') worked without a single warning (under MacOS, which might be a consequence of the fact that this is very near to FreeBSD anyway). and there is ptx included: is this a good tool for index generating or can I forget about it (did'nt catch the bottom line of the recent thread)? It probably works OK. There's also a ptx in GNU textutils, with several extensions over the AT&T version, that compiles in OSX with minimal fiddling. The Heirloom manpage for their ptx is probably better than the GNU version though. The bottom line of my experiments with ptx is that I bit off a rather large chunk of text; after eliminating some unhelpful keywords I got my permuted index down to 198 pages. Either ptx is probably fine for its intended purpose. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Sun's troff now available
Werner LEMBERG wrote: If you had a "pre-output" macro (just as you can have macros which are sprung by bottom-of-page, so you could have macros sprung by "about to output line"), then this could look at [...] Similar to TeX I think it is next to impossible to find a suitable macro interface for the things you want to do. Pity. Seems like an elegant concept, and very familiar. a) Inter-word spaces: if larger than a threshold, expand the inter-character space until these are reduced below it. Instead of handling this with a macro I could imagine to set and unset a flag which makes troff do that. b) Is there an end-of-line character (like the soft hyphen above, which might not have been explicit in the source) which we would like to hang over the end of the line? Then slightly increase the linelength of this line (or redefine "-" to have smaller width, or whatever) so that it sticks out by the right amount. Ditto. Wasn't there a compile-time option for hanging punctuation at one time, similar to the widow/orphan option? A quick grep doesn't turn it up in the source, so perhaps I was hallucinating. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff 1.19.2 with pdfref
> I am using the pdfref macros from Kees Zeelenberg found here > http://lists.gnu.org/archive/html/groff/2001-01/msg00047.html. > > It works nicely together with the ms macros. I better should say > worked. We updated to version 1.19.2 and now it doesn't work > anymore. In the referenced message, Kees said, "they work silently by redefining the NH and SH macros." I expect that there have been changes in s.tmac between 1.19.1 to 1.19.2 that clash with pdfref. You might want to try running a diff between the two versions, to figure out what's happening. I've woven the pdfmark macros into the -ms extensions I'm using for documentation at work, and they work well enough. I'm having trouble with pdfroff though; it repeats the output twice in the PDF. I haven't had time to figure out what's happening there; I'm getting good bookmarks without it so that should be OK for this release. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] making tbl created tables fit on the paper
Nick Stoughton wrote:
> I've had similar problems with long tables, particularly where a column
> is longer than a page ... that is, there are too many lines between
> T{ and }T to fit this column on a single page. In this case, tbl says
>
> warning: page 236: table text block will not fit on one page
FrameMaker can't break a tall row across pages either. One of the very few
things Word does better.
> In my case, I was able to work-around this by using mm's .MC to switch
> to multi-column mode, since the tbl actually just contained several
> columns of text. With this, you can also use .NCOL to move to the next
> column, but beware this doesn't solve many of the problems ... a column
> that reaches the end of the page will cause a move to the next column,
> so if it matters which column particular text lands in, then this isn't
> necessarily the best answer!
Way back when I was writing documentation using a troff clone ("trol", a
homegrown clone that ran on VAX/VMS and printed to a LaserJet), I wrote a
set of macros to handle tables. It was smart enough to break tall rows across
pages, although it was hardly a general table solution. Perhaps the hdtbl
macros can do this?
> Width related problems usually result in the message:
>
> stdin:9597: warning [p 331, 3.0i, div `3tbd4,5', 0.3i]: can't break line
>
> The already suggested approaches of reducing the inter-column spacing,
> reduced inter-word spacing, etc are usually the best bets, and switching
> to landscape also helps if the table is on a page by itself.
It's also helpful to turn off full justification inside tables. The
hack^H^H^H^H
extension I use for ms includes the following:
.am @TS
.ad l
..
.am TE
.ad b
..
That gets rid of nearly all the "can't break line" warnings for me.
-- Larry
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] Tables in .ig/.. blocks not ignored
Tables that *should* be commented out using the .ig / .. construct still appear in the output. I first noticed this in 1.19.2, but it also appears in the CVS. Here's an example file: .\" start -- .LP The following table should be seen: .TS allbox; cb cb n l . Value Description 1 enable line 1 2 enable line 2 3 enable both lines .TE .LP But this table should .I not be seen: .ig .TS allbox; cb cb n l . Value Description 0 Disable all lines. 1 Enable line 1. 2 Enable line 2. 4 Enable line 3. 8 Enable line 4. .TE .. .LP And that's all. .\" end -- -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] error in README-file of groff distribution?
> > I also had to use cvs login to get a checkout started (restoring > > important parts of an office computer). I added it to the wiki as > > well. > > Really? How comes? I'm not sure why. It was behind the firewall at work, and CVS to the "outside" has exhibited flaky behavior in the past (sometimes savannah won't resolve). It could have been a savannah glitch as well, although I'm leaning toward the "it just happens sometimes" theory. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Address labels
John Poltorak wrote: > > Is there any way to use groff for creating addresses using standard Avery > labels? I wrote a "labels" macro package a while back; it has a definition file for Avery 5160 address labels. http://home.alltel.net/kollar/groff/ -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] explicit hyphen and numbers
Werner LEMBERG wrote: > Urs showed up an interesting problem in groff: A hyphen between two > numbers does *not* insert a breakpoint! To be more specific, the > .cflags values 2 and 4 of a character x are only active if the > characters before and after x both have non-zero hyphenation codes (as > set with the `hcode' request). > > Since it isn't possible to set the hcode value for numbers, things > like `200-400' are never hyphenated. Personally, I think that's a (good) feature. I'm sure someone will disagree. :-) -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] explicit hyphen and numbers
Ted Harding wrote: > On 10-Aug-06 Steve Izma wrote: >> >> Well, I'll disagree. [...] when setting >> indexes on short lines (e.g., two columns on book page, which >> gives you about 10 to 12 picas, usually indented), any place >> where you can get a line break is very important. > > Yes, that does make something of a case for it, and indeed it > does occur. But even so I think it can be avoided in most cases. > > Fr example, I just checked in the index of a book "Multivariate > Analysis" (Mardia, Kent & Bibby, Academic Press 1979). > > In one entry I see: > > seemingly unrelated regressions, 203- > 5, 211 And this is considered acceptable? If you're going to break sequences like this, at least use the entire number. Someone quickly skimming this index might be mislead to check page 5. > Both cases could have been improved in appearance by not filling > the lines: > > seemingly unrelated regressions, > 203-5, 211 > > simultaneous confidence intervals, > 144-5 > > especially since some index entries are short lines anyway I agree with this -- I drop back to left-adjustment in my indexes too. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] grohtml and indentation
> I wonder why it is that paragraphs inside a -ms .RS/.RE block get turned > into a table by grohtml. > > The same happens with .IP. (maybe other requests too.) > > Wouldn't it be better if a were generated with an indentation? And > an unordered list for .IPs? > > For example... > > > .RS > .IP \(bu > sun is shining > .IP \(bu > the weather is sweet > .IP \(bu > make you wanna move > .IP \(bu > your dancin' feet > .RE There's already a fair workaround for that. Make sure you include www.tmac (it's automatic if you use grohtml) and replace the above with: .ULS .LI sun is shining .LI the weather is sweet .LI make you wanna move .LI your dancin' feet .ULE If you want it indented a little, add this line somewhere before the first list: .nr www-li-indent +3n I also added some patches to grohtml some time last year to improve the HTML output a bit. It's better than it used to be, but you have to work with it and fiddle with some stuff along the way. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Other PS fonts for groff not in Cygwin distribution?
Clarke Echols wrote: > I would like to have a broader selection of fonts on my system, but > dislike the idea of paying $50 or more each for them. > > Are there any sites where one can download *.pfb or *.pfa files that > can be used with groff? There are lots of sites with free fonts; I think I have a list at work (which means "ping me on Monday" :-). You can even use TrueType fonts, converted or not; see http://www.port.de/cgi-bin/groff/AddingFonts for starters. Also, give DejaVu a look -- http://dejavu.sourceforge.net/wiki/index.php/ Main_Page -- the Condensed variant might be particularly interesting for your situation. -- Larry ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Blocks of text in -ms
I'm wondering if there's a way to do a block of text using -ms macros, where the lines don't all get joined. Add the request: .nf (begin no-fill mode) before the block of text, then add .fi (begin fill mode) after. Or... .DS I pasted in text... .DE See "Displays and keeps" in groff_ms(7) for more variations. -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] help required regarding groff/psroff
hi, myself Himanshu i have a project in whcih i need to get the width tables from HP laserjet fontsie fonts which are stored inside the laserjet.. i have windows as operating system and hp 4250 laser printeri have downloaded gsroff and psroff 3.0 was not able to install Psroff as it contains ".Z" files :( Hello Himanshu, I don't think you need psroff to do your printing. There are three ways you can print to a LaserJet: 1) Use '-Tlj4' in your command line (like 'groff -ms -Tlj4 myfile.t | lpr). This method uses the native LaserJet language and fonts and is fastest. The width tables are already made for the most common HP fonts. :-) 2) Print to a PostScript file, and use GhostScript to convert it to LaserJet format (like 'groff -ms myfile.t | gswin32c -sDEVICE=ljet4 - | lpr'). This method is slower, but is more general. 3) Print to a PostScript file, convert to PDF, and use Acrobat Reader to send it to the printer (like 'groff -ms myfile.t > out.ps; ps2pdf out.ps out.pdf'). This is slowest of all, but lets you check the output for pagination and other errors before using up paper. I use this method on MacOSX, since my work requires PDF output anyway. Hope that helps -- Larry Kollar k o l l a r @ a l l t e l . n e t Unix Text Processing: "UTP Revival" http://unixtext.org/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
