Re: [Groff] mom: Some follow-up questions
On Fri, Mar 11, 2005 at 08:18:44PM -0500, Peter Schaffter wrote: > On Fri, Mar 11, 2005, Mats Broberg wrote: > > Since I don't know much about groff yet, this may be a uninformed > > question - but is it possible to use e.g. other listmembers' specific > > macros for crossreferences together with mom? I browsed the archives > > and found out that e.g. Jon Snader has some xref macros. > > I haven't tested this, but I'm almost certain the answer is: not > without modification, although I'd welcome the opportunity to be > proven wrong. :) > I do have cross reference macros that I use for my books. As with TeX and LaTeX, this requires two passes through groff. The first accumulates the references and the second actually does the type setting. That sounds like a pain, but I handle it all with a make file, so I don't really notice it when I'm making trial or final runs. I'd be happy to make them available (it's really only a couple of macros) to anyone who's interested. If there's enough interest, I'll post them here. Peter, if you'd like to include them in mom or use them as a starting point, you're more than welcome--just let me know. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
On Sat, Mar 12, 2005 at 11:17:45AM -0500, Peter Schaffter wrote: > On Sat, Mar 12, 2005, Jon Snader wrote: > > I do have cross reference macros that I use for my books. > > > Peter, if you'd like to include them in mom or use them as a > > starting point, you're more than welcome--just let me know. > > Please, pass them along. > Will do. Give me a couple of days to do a minimal writeup on how to use them. I call the two macros .Xr (a cross reference reference) and .Rf (a cross reference definition). At a minimum, you'd probably want to change the names to be more in line with the macro names you use in mom. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] getting .na, .nh thruout doc for nroff
On Wed, Mar 16, 2005 at 03:08:59PM -0500, Dorai Sitaram wrote:
> I'd like to avoid adjustment (justification) and hyphenation on a document
> but only if it's being processed by nroff.if n). In essence,
>
> .if n .na
> .if n .nh
>
> should hold for every paragraph. What's a robust way to do this? Trying
> to adding this as a hook (via .am) to various things, like the header
> macros, or even par*start, always seems to miss the first couple
> paragraphs.
>
I usually just add
.if n \{
.na
.nr HY 0
.\}
at the top of my file. If you don't want nroff to paginate, add
a .pl 1000 right after the .nr HY 0, and a .pl \n[nl]u at the end
of the file.
jcs
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Line fragments with .TS and .PSPIC
On Mon, Aug 22, 2005 at 09:33:43PM +0200, Bernd Warken wrote: > > > Werner LEMBERG <[EMAIL PROTECTED]> schrieb am 22.08.05 16:26:08: > > > > > Isn't there a possibility to change `groff' such that it is not > > > necessary to redefine .TS and .TE? > > > > Please elaborate. > > The `groff' .TS and .TE could be such that the text goes around a table in a > nice way. Maybe you could use your redefinitions in the original > definitions. I hope that I understood that right. > Provided that this is what the user wants. I always want my tables just where I put them, and I certainly don't want new macros to suddenly change the page layout of old books or papers. I'm all for having this capability available, but let's make sure it doesn't ``break'' existing documents. Even a heuristic such as ``flow data around the table if the text before doesn't end a sentence'' may not be what someone wants. Perhaps a different macro, or a new argument to .TS to invoke the behavior is what we want. Or am I just misunderstanding what you're asking for here? jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] moving TOC to start
On Thu, Sep 29, 2005 at 08:11:53AM +0200, Werner LEMBERG wrote: > > > Uh, oh, I wasn't aware that you use this indeed very nasty strategy > within pdfroff. As Tadziu suggested in another mail, groff should > behave like LaTeX (and I was incorrectly assuming that the ms macros > already do something similar), this is, writing out the table of > contents piece by piece into a separate file so that the created > auxiliary file can be read in by a second pass at any location. This > not only fixes the nasty collation problem, it also fixes possible > page numbering issues -- it even allows that the table of contents > ends on the same page as the main body starts (this may be useful for > mini TOCs which are located at the beginning of each chapter, listing > the sections and subsections to come). > > I do exactly what Werner is suggesting for my TOC, and it works out very well. My chapter and section macros write out title and page information to a file. This file is processed by a script to generate exactly the type of TOC needed for the document in question (rather than a one type fits all). This does, of course, take two passes, but so what? The whole thing is controlled by a makefile so I just type ``make book'' and everything is taken care of automagically. I also generate cross references in a similar way, so I need a total of 3 passes, but typesetting a 450 page book takes less than 30 seconds. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] moving TOC to start
On Thu, Sep 29, 2005 at 10:53:59AM +0100, Keith MARSHALL wrote: > > The problem with groff's `write' requests is that they don't work, > if the user fails to specify the `-U' flag, when invoking groff. > > This flag activates the so called `unsafe' mode. While it probably > isn't the case, this carries the connotation that it makes groff in > some way harmful, and therefore, some users may be reluctant to use > it. If the ms' `XS', `XA' and `XE' macros are reimplemented, so as > to rely on `write' requests, then they appear broken, in the event > that the user either forgets, or refuses to specify `-U'. > > Not a big deal, I know, but `unsafe' is a rather unfortunate choice > of name for this `extended functionality' mode of groff's. > For my TOC I write the files to stdout with .tm, so I don't even need the .write request (although I do use it for cross references). I'm not sure what the big deal is; it's not like we're typesetting unknown documents. My makefile just specifies the -U when I'm working on my documents. For other stuff I just specify groff on the command line, so the -U doesn't come into play. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
On Sat, Oct 15, 2005 at 02:53:04PM -0400, Zvezdan Petkovic wrote: > > It does work. I use OpenBSD 3.7 every day for all my work. > He has messed up something on his system. > Perhaps he didn't source his .profile/.bashrc after he changed it. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On Tue, Oct 18, 2005 at 08:49:50PM +0100, Deri James wrote: > > I am not persuaded a gui would improve groff adoption (has LyX helped > LaTex?). Even if such a GUI were available, who would use it? As Deri says, LyX is available for LaTeX, and LaTeX probably does a better job at typesetting than [gt]roff. The whole point of troff is that it is a *markup* language for those who prefer to work that way. I, and I'd guess other groff users, use groff instead of TeX/LaTeX because we like the markup language better than we like that of TeX or LaTeX. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On Wed, Oct 19, 2005 at 10:14:28AM +0100, Keith MARSHALL wrote: > > I've tried various editors in my time, Emacs among them. But, I > keep going back to vi, (or (g)vim), for personal choice. > In the end, there can be only one. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Need some troubleshooting help
On Thu, Apr 13, 2006 at 09:16:44PM -0400, Larry Kollar wrote: > 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. > I've seen something like this recently on Linux. I'm running groff 1.19.1 and have been for some time. Recently my distribution upgraded gv to 3.6.1 and things stopped working. Specifically, gv wouldn't display groff postscript output at all. If I convert to PDF with gs2pdf, gv displays the document fine. If I use groff 1.19.2, then things start working again. One more datum: I don't think this is a ghostscript problem because displaying the document with gs works fine. I believe that the new gv introduced some sort of incompatibility (probably in the prologue). I haven't done any more analysis because my distribution will soon "release" 1.19.2 and in the meantime the ps->pdf conversion is allowing me to get work done. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Setting different page lengths for troff and nroff
On Wed, May 31, 2006 at 11:32:00AM +0930, Greg 'groggy' Lehey wrote: > I have a design document that I need to output in two forms: as a > properly typeset PostScript file (troff) and in plain text (nroff). I > want the latter not to have page breaks. I've tried a number of > things, but I have two problems: > > 1. I can't find a number register than I can tweak to change the page > height. The ones I find are read-only and can only be set from > the command line. > > 2. The document contains footnotes. If I do set a large page size > from the command line, I have to guess it exactly, or I end up > with a footnote separated from the rest of the document by a lot > of white space. > > Any ideas? I'm looking for a solution to my original problem, but it > would also be nice to know how to reset page height from within a > document. > Add a if n .pl 5000 (or whatever number is large enough to contain your entire document) to the beginning of the file. Now the problem is that you will have a bunch of blank lines at the end. Fix this by adding a .if n .pl \n[nl]u to the end of the file. This last trick is from Werner. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Status of the portability work, and plans for the future
On Mon, Jan 08, 2007 at 10:02:11PM -0500, Eric S. Raymond wrote: > > Gunnar, Linux man(1) can do this *now*. I added the code myself over a > year ago. All that's needed is for HTML pages to be in the right > places under /usr/man and it's game over. Of course, if you were > insistent on a crappy presentation, you could always set BROWSER=lynx > and get behavior almost as primitive as man(1). Sorry about the > working hyperlinks. [...] > > But the preference for man(1) is not, in fact, a preference for > reading nroffed output on an xterm -- it's a preference for a > *retrieval protocol*, a set of reflexes about how to *find* stuff. > The display channel is nearly irrelevant to that preference. > Let me start by saying that I think that the project we are discussing is great and that we all owe ESR a debt of gratitude for all the work he has done and will do. I agree with Eric that most, or at least many, users would probably prefer HTML rendered man pages. I do not think it's correct, however, to conclude that only Unix troglodytes stuck in the eighties would prefer to read man pages in an xterm or similar window. As a Vim user, I use the K command to pop up a man page in an editor window when I need to check the exact usage or parameters. I know that emacs users can do similar things with the M-x man command. Most serious developers use either emacs or Vim, so I'd be willing to bet that they prefer to read most of their man pages this way. To be sure, these commands could just as easily bring up the man page in a browser, but this exacts a serious penalty for *most* users. As a long-time reader of ESR, I know that he prefers to have a *single* window on his desktop with an emacs window and (presumably) a browser side by side. With this arrangement, having the man page render in the browser exacts no extra cost and has all the benefits that we've been discussing. Most of us, though, have several windows on our desktops. For example, I have a window dedicated to my browser, which takes up the whole desktop. If I'm editing and want to pop up a man page in the browser, I would have to change windows, a serious interruption of focus (so to speak). One could argue, I suppose, that this just shows that ESR is correct and we should stick to a single window, but there's a whole bunch of us who disagree. At the end of the day, there's no reason we can't have both worlds. In those situations where it makes sense to render the man page in a browser the system does so. In those cases where it's most convenient to pop it up in an editor window or other viewer, it can do that. The important thing is that the behavior be configurable for each user, and that we don't dismiss a desire for the current behavior as indicative of arrested development. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Status of the portability work, and plans for the future
On Tue, Jan 09, 2007 at 12:03:14PM -0500, Eric S. Raymond wrote: > > Your thinking is intelligent and cogent -- but your factual > premise is wrong, leading you to an incorrect model of my > assumptions. On my usual desktop arrangement, rendering man > pages in a browser *would* in fact have the cost of popping up > a browser. It is indicative that I don't have one up right > now. > I stand corrected on your desktop set up, but I'm willing to concede only half the point. With your desktop, calling up a man page from your editor would cause a browser to pop up. That's a little distracting, perhaps, but not nearly so much as having to switch desktops. > > One could argue, I suppose, that this just > > shows that ESR is correct and we should > > stick to a single window, but there's a > > whole bunch of us who disagree. > > Heh. For the record, "ESR" himself wouldn't make that > argument. :-) > I was a sloppy here. What I meant is a single *virtual desktop*, not a single application window. > > You skipped a step. You have a good point about calling up > manual pages within an editor, but not all character-cell > displays are equivalent; it doesn't follow from this that > man(1) through xterm has any value that lynx(1) through xterm > wouldn't. I'll be interested to see if you can make that > argument, especially since Gunnar ducked it. > I think someone made (almost) that argument earlier. That person posted that man with less was more convenient and powerful (?) than a browser because of navigation and searching issues. Regarding man/less vs. lynx, I would have to agree. Let's face it, lynx navigation sucks and the only benefit that I can see is that you get hyperlinks. I'm not sure (admittedly because I haven't had the ability) that hyperlinks make up for the loss of easy navigation and searching. But, really, I think that misses the point. I doubt anyone would prefer lynx/xterm over, say, firefox for viewing man pages. The question is whether there are some situations in which a traditional man page rendered in a character display makes sense. For me, and I think many others, getting a man page in an editor window does make sense and I wouldn't want to lose that ability. When I'm looking at a man page for, say, bogofilter, then a browser based display would probably be preferable because I'm not already in my editor. > Until somebody meets that challenge, I'll stick with my > diagnosis of arrested development. It's not arrested development to prefer to retain a useful capability (man pages in an editor) rather than move to a browser based system whose main benefit is hyperlinks. Especially if you don't think hyperlinks are particularly valuable for the types of man pages you typically bring up in an editor. > It's not one I make casually -- I've been thinking *hard* about > Unix UI, from a position deep within Unix culture, for half a > decade now. I know you have; let me say again that I approve of this project and appreciate your efforts on its behalf. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Status of the portability work, and plans for the future
On Tue, Jan 09, 2007 at 02:26:38PM -0500, Eric S. Raymond wrote: > > For me, and I think many others, > > getting a man page in an editor window does make sense and I > > wouldn't want to lose that ability. > > I agreed with you about this last time. I still don't see how it's > relevant to the question of man's default behavior. I readily concede > that I like M-x man in some circumstances -- but what in the heck does > that have to do with what happens when I type 'man foo' in an xterm? > > To put it more directly: suppose man went to using a browser as > a default when you call it from an xterm. You seem to believe > that implies M-x man going away. Why do you believe that? > > One of us is missing something basic here. You're right, I think we're talking past each other. My main point is that there are *some* situations for at least some people for which a traditionally rendered man page makes sense. That doesn't mean that I object to having man foo invoke a browser in some fashion. My example (and main concern) was with man pages in an editor, but that doesn't mean that other folks have other situations in mind that you and I haven't thought of. Thus, my real point is that each user should be able to configure things to his own liking. If Gunnar wants to look at nroff rendered man pages in an xterm, who are we to say he shouldn't? I'm fine with having man foo launch a browser by default, but there's really no reason (other than increasingly cheap hard disk space) why someone can't set an environment variable or config file item and get the traditional behavior. If someone wants to use w3m and emacs to read man pages rendered with HTML that's fine; if someone else wants to use Vim K and the traditional man pages, that fine too. Just to demonstrate that I'm not stuck in the eighties, but actually much farther back, I'll simply repeat the mantra, ``Different strokes for different folks.'' Most folks will probably prefer what you're suggesting, but it doesn't cost anything to support those who disagree. And just to be clear: (1) I'm not saying that man in an xterm is preferable to man in a browser, only that someone else may think so. (2) I don't think you're taking the position that everyone should have to live with what you're suggesting. I think that we've both focused on the parts of our respective posts that we disagreed with (because, after all, that's the interesting part) rather on the vast majority that we do agree on. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Choosing a portability target
On Wed, Jan 10, 2007 at 08:49:37PM -0700, Clarke Echols wrote: > [...] > I was somewhat hesitant to really accept the longer names > allowed by groff because I usually prefer "backwards > compatibility", but after taking advantage of it, I find it > very nice in terms of keeping macros readable when I create or > modify them. > [...] > > HOWEVER, if groff can be compiled and run on HP-UX, > groff-oriented man pages will also need to be installed in the > usual directories on HP-UX systems, and HP-UX users will expect > to be able to run the man command on those pages. > > THEREFORE, I think it would be wise to avoid using macro, > string, or other entity names in gnu man page macros that > violate the 2-character rule. Same applies to me and ms > macros. If you want to use expanded-length names in a macro > package, it should have a different name so the user doesn't > expect it to run under nroff(1) on HP-UX/Solaris/AIX systems. > I used to believe something similar to this myself, but I have since reevaluated those beliefs. There really isn't any reason to be using (much less paying for) the traditional DWB these days. There are at least two much better solutions. There is, of course, groff, with which we are all familiar. Additionally, Gunnar has taken the traditional troff and turned it into a really spectacular tool, It does long names like groff, and can also format a paragraph at a time, like TeX, as well as other improved typesetting functions. Both of these are free and compile on HP-UX/Solaris/AIX; why would anyone want to still be using AT&T troff? Of course, people *are* still using it, but my guess is that those installations are pretty much hidebound and won't be updating their man pages, much less using the type of browser-base man page viewing that Eric is advocating. Those HP-UX/Solaris/AIX installations not experiencing heat death need merely install one of the (much improved) typesetters to take advantage of the improved functionality that we've been discussing. In terms of the present discussion, *if* they have groff man pages installed *then* they will almost certainly have groff installed and the System Administrator can configure man to use it. I don't think we should go out of our way to break compatibility with these systems, but I also don't think we should take extraordinary measures to ensure that the new macros will be compatible with those installations that probably won't use them anyway. In practical terms, this means that we should use two-character macro names in the new general purpose macros we define (like SY and OP) but not worry about changing long macro names in existing man pages. Let's face it, the systems using the traditional troff won't be displaying those pages anyway. jcs ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] RE: Small bug in groff 1.19.2 footnote number contro
On Mon, Sep 17, 2007 at 06:57:06PM +0100, Keith Marshall wrote: > On Mon, 2007-09-17 at 17:33 +0200, Werner LEMBERG wrote: > > > So I ask the question of the group: > > > > > > Do we want to implement "backward compatibility" of > > > undocumented things like the number register :p in > > > the groff package? > > > > > > I vote no. > > As do I. > I'm with Gunnar on this: I don't much care (especially since I don't use -mm). In general, I am *very* much in favor of backward compatibility, but as others have pointed out, the feature was undocumented, so anyone using it is probably prepared to deal with it's unportability. > > Exactly as you would in any other situation, where you found it > necessary to exploit an undocumented feature; go ahead anyway, but > prominently include a comment in the document, to the effect that: > > .\" This document makes gratuitous use of the undocumented `:p' > .\" register, defined by the XYZ implementation of `mm'; it may > .\" not be readily portable to other troff implementations. > . > .\" The equivalent, but also undocumented, feature in groff `mm' > .\" is controlled by the `ft*nr' register; thus > . > . aln :p ft*nr > . > .\" should suffice, to allow groff to emulate this undocumented > .\" register usage. > If it were me, I'd do exacted as Keith suggests here and fix it up in the files that are affected. jcs
Re: [Groff] Signaling diagrams?
On Sun, Nov 23, 2008 at 11:07 PM, Larry Kollar <[EMAIL PROTECTED]> wrote: > Is there a program to generate signdling diagrams out there? I sure could > use one right now > > -- Larry > > > What kind of signaling diagrams? Trains, cells, ...? For some applications, I've found Graphviz makes an excellent front end to pic (or you can generate ps, etc. directly). jcs
Re: [Groff] changing .em behaviour?
On Tue, Apr 21, 2009 at 2:50 AM, Werner LEMBERG wrote: [snip] > What do you think about enabling this bizarre behaviour of `em' only > in compatibility mode? As already mentioned, I can't think of any > useful application. This would save us from introducing the proposed > `em1' request. It makes sense to me. Clearly, most of us weren't even aware of the behavior so I see nothing wrong with relegating it to compatibility mode. jcs
