-man fails to use ANSI commands
Hello, all `groff -man -Tutf8' does not seem to handle font styles on my terminal. I have made sure that plain `groff' works as expected: This is .ft B strange .ft R indeed. .pl \n[nl] The word `strange' above is typeset in bold, which on my terminal looks both bright and bold. A test man-page, however, is output all in the same default font style and color: .TH 3 test .SH Section This is .B strange indeed. whereas `man -l` renders the same source correctly, with the words `Section' and `strange' highlighted and bold. The incorrect output from -man shows that it tries to make characters bold by typing them over, e.g.: s^Hst^Htr^Hra^Han^Hng^Hge^He instead of using ANSI control codes, and this has no intended effect. How can I cause `-man -Tutf8' to use ANSI codes?
Re: -man fails to use ANSI commands
I accidentally replied to Brandon my mail, because of my client (Sylpheed), which insists on replying to this message my mail instead of by NNTP (via Gmane). This does not happen with any other messages I have tried. I am sending this to the mailing list, but the threading may be broken... G. Branden Robinson to Anton Shepelev: > > instead of using ANSI control codes, and this has no > > intended effect. How can I cause `-man -Tutf8' to use > > ANSI codes? > > Check your environment for variables named "GROFF_SGR" (a > Debianism) and "GROFF_NO_SGR". Unset them both and try > "groff -man -Tutf8" again. `export | grep -i sgr' finds nothing, unfortunately. Where else can I look for the reason of -man treating my virtual terminal as a printer? Once I find it, I will bring it up with the administrator of that system, and then perhaps with the distro maintainers.
Re: -man fails to use ANSI commands
G. Branden Robinson to Anton Shepelev: > > `export | grep -i sgr' finds nothing, unfortu- > > nately. Where else can I look for the reason of > > -man treating my virtual terminal as a printer? > > Once I find it, I will bring it up with the ad- > > ministrator of that system, and then perhaps > > with the distro maintainers. > > If you're still using groff 1.22.4, some distribu- > tions used a device control command to tell > grotty(1) to shut off SGR support. Indeed. /etc/groff/man.local contains: . if '\V[GROFF_SGR]'' \ .output x X tty: sgr 0 so the solution is to define a GROFF_SGR evironment variable. I wonder what Debian user or developer disliked those SGR sequences emitted by groff...
Re: -man fails to use ANSI commands
G. Branden Robinson to Anton Shepelev: > > I wonder what Debian user or developer dis- > > liked those SGR sequences emitted by groff... > > Well, here's one of them. > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312935 > > ...with my lengthy rebuttal and defense of groff's > behavior. > > The more I learned, the more I realized just how > wrong that guy was. I have read it and agree with you. `grotty' is not an appendix to a pager, but a program for printing direct to the terminal. Most terminals support those basic ANSI control sequences, and many console programs freely use them. If a pager cannot trans- parently forward them to the terminal, it is a prob- lem of the pager, not of `grotty', and having a bro- ken -man configuration by default to just to appease `less' is stupid.
Re: GNU groff in articles
Jim Hall: > Several weeks ago, I interviewed Dr. Marshall Kirk > McKusick about how he writes his books using groff: > https://technicallywewrite.com/2023/10/13/groffbooks McKusick writes about orphan elimination, end-of- line tweaking, and balancing of text on facing pages. Does that mean he wrote an exptermal tool that looks for those defects and runs *roff in sev- eral passes to eliminate them? It seems in possible in a single *roff invocation...
Re: -man fails to use ANSI commands
Anton Shepelev wrote to G. Branden Robinson: > > Check your environment for variables named "GROFF_SGR" > > (a Debianism) and "GROFF_NO_SGR". Unset them both and > > try "groff -man -Tutf8" again. > > `export | grep -i sgr' finds nothing, unfortunately. > Where else can I look for the reason of -man treating my > virtual terminal as a printer? I forgot whether I reported my solution, and if I did, I do not see my answer here, so here it is for the record. The culprit is: /usr/share/groff/site-tmac/man.local which has the following: . \" Debian: Disable the use of SGR (ANSI colour) escape sequences by . \" grotty. . if '\V[GROFF_SGR]'' \ .output x X tty: sgr 0 This means that one must /set/ rather than unset GROFF_SGR to restore the normal nroff behavior. See also: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750202>
Documenting a set of functions with -man
Hello, all What is the covenstional way of documenting a set of C functions with -man? Have you any recommendations or examples about typesetting function declaraions, their return types and aruguments in a classic man-page? The .SY macro does not seem to work well for C, because its function declarations start with the return type.
Re: -man fails to use ANSI commands
G. Branden Robinson to Anton Shepelev: > > This means that one must /set/ rather than unset > > GROFF_SGR to restore the normal nroff behavior. > > This advice, while still applicable to groff 1.22.4, is > becoming stale. Distributors that introduced the > GROFF_SGR Debianism have now started to withdraw it when > packaging groff 1.23.0. I like coming up with solutions to semi-stale problems. > I managed to remain ignorant of "GROFF_SGR" for something > like 20 years because (1) for much of that time, as the > Debian bug report notes, it was undocumented; and (2) > unlike a startling number of people, I lacked a prurient > desire to decorate man page renderings with all the colors > of the ANSI X3.64 rainbow, I thought it rather the guilty pleasure of clueless and tasteless composers of HTML e-mail. > and certainly not via the exercise of less(1) features > that were _also_, at the time, undocumented!) I was exposed to it when I decided to write a man page that looked right on screen, in plain text, and on paper; and direct `nroff' output to the console did not look like the output of the `man' command, which nowadays seems sometimes to rely on some man-specific formtter rather than a bona fide `nroff'.
Re: Documenting a set of functions with -man
G. Branden Robinson: > People frequently run into trouble because they usually > don't want the text of function prototypes filled, but the > prototypes can also get lengthy, and they don't know how > to make the text adapt to the available terminal width in > the absence of filling. (Short answer: you don't.) I dislike long lines in code as well as in documentation, which made me ponder a tabular approach, where each function is presented and documented in parts, e.g: char *strtok char *restrict str, const char *restrict delim In my sources, I tend to format the declarations of my functions in similar manner, e.g.: void sort (void * data, /* pointer to data to sort */ intlen, /* length of data to sort */ comp_f comp, /* comparison function */ swap_f swap, /* swap function */ void * extra /* user-supplied parameter to comp */ ); > My guess is that this didn't seem like a problem when Doug > McIlroy designed man(7) in about 1977, because C function > prototypes didn't yet exist. Glad to see Doug still around and about this list. > You'd declare a function like this. > > FILE *freopen(filename, type, stream); > char *filename, *type; > FILE *stream; Yes, and the K&R style is good at least in that it is "bookish" -- tall and narrow. > It took a decade for ANSI C function prototypes to become > standard,[2] and much, much longer than that for "old- > style", "K&R" function declarations to fade away. What with the varous new modifiers in addition to types! > > The .SY macro does not seem to work well for C, because > > its function declarations start with the return type. > > Funny you should mention that. > > Just 2 months ago I proposed a revision to groff man(7) to > solve this very problem. > > https://lists.gnu.org/archive/html/groff/2024-04/msg00115.html As an occasional visitor rather than a regular reader, I did not see that post. Thanks. I will give my (belated) comments in a follow-up to it. > > Have you any recommendations or examples about > > typesetting function declaraions, their return types and > > aruguments in a classic man-page? > > I'm not sure what you mean by "classic" here -> I meant the standard `man' package without the GNU extension, and specifically not `mdoc', which seems more advanced. > -> but my recommendation would be to employ the solution I > proffered above. It survived Alex Colomar's peer review, > and he's familiar with one or two man pages. ;-) Thank you. > [1] I would have set the formal argument names in italics > to break up the tedium and emphasize that the name of > a parameter was a matter of the user's discretion. I thought you were typesetting your e-mails in `groff' (as I do, in -mm, with macros for nested quotations), but having failed to find the source of this footnote, I concluded you are[1] using a WYSWYG editor directly. Yes, typesetting the arguments in italics is a good idea both esthetically and syntatically. > [2] I observe that London and Reiser explicitly lobbied > for them in July 1978; see their UNIX/32V paper. > > https://lists.gnu.org/archive/html/groff/2024-06/msg00022.html Advocacy by example? I see they have program names and C functions in italic, inline assembly intructions, C macros, and C types in bold, and never use monospace font. AFAIK, the `man' package is unaware of it as well, save the example macro, but it is an extension. What I have come up with so far does not use .SY either: .FN void* a_newl elem_sz len create a new array of length \*(a2 and with elements of size \*(a1. My .FN macro uses .TP internally to format the above as: [/.../ denotes italic] void* a_newl(/elem_sz/, /len/) create a new array of length /len/ and with elements of size /elem_sz/. It is not aligned by return type (yet, I might fix that) and deliberately omits types, because they are introduced in a preceding section: Since the majority of parameters are common to the majority of functions, we shall describe them below to avoid repetition: void* /a/ Pointer to a dymamic array, henceforwared referred to as the array, for each function operates on a single array. ptrdiff_t /len/ Array length. size_t /elem_sz/ The size of an array element, in bytes. I have a dedicated macro .AR to format argument documentation, which also relies on .TP . I mean parameters, and will rename the macro accordingly. 1. or `were'? (pray pardon mine English)
Re: Proposed: next-generation alignment and adjustment control
G. Branden Robinson, just quick commentincle on this: > So if "adjustment" is, as I claim, "the widening of > the spaces between words until glyphs abut both the > left and right margins", well, that's clearly not hap- > pening here. No, it is not. What you describe is "both" adjustment, whereas there is also left-, right-, and center adjust- ment, and only one kind of adjustment is effected by widening interword spaces. For some reason or other, `justification' is a synonim for Groff's both-adjust- ment. I will answer your other post as His Majesty Time per- mits, and I am beggin Him.
Re: [Groff] PDF doesn't work on Windows
hj.oertel: > by default groff generates PS, using the flag > -Tps. In Linux you can convert it to PDF using > the ps2pdf tool. Ditto on Windows, just install Ghostscript for this OS: http://ghostscript.com/download/gsdnld.html . -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: [groff] [Groff] groff MM problem with AU/AT
I wrote seven years ago: > OK, I have modified the patch (attached). > > But I am not sure how mm is supposed to handle > long signatures if they spread across the page > boundary: should it treat the .FC + .SG combina- > tion as an indivisible keep or not, e.t.c.; so I > did it the simplest way and with the least changes > possible. And now a user writes me to about the same problem and says the patch helped to solve it: > I tested groff on Ubuntu 19.10 which has groff > 1.22.4 It did not have this patch for m.tmac in- > cluded. Before it still had the same problem > where the title did not appear after the name. > Applying the patch you wrote fixed the issue. I > did have to manually apply it since patch seemed > to reject it. > > Thank you for your help. You saved me a lot of > time. Will you consider applying the patch lest my contri- bution be lost? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: groff_mm : problems with .DS
Damian McGuckin: > I went back to a very old document using troff and > MM. It is a tutorial on using troff at the macro > package level without needing to know much about > the low level troff. I was contemplating updating > it and putting it out there. > > I am trying to use a display with fill mode on, > i.e. > >.DS 1 1 > > The left margin is indented slightly. Unfortunate- > ly, the right margin is not shrunk by the same > amount with groff_mm. > > I know that the original MM package handled it > flawlessly. > > Does anybody have a fix for this or do I need to > sort out the bug? Does not the current behavior agree with the groff_mm manpage, which states for .DS that: `rindent shortens the line length by that amount. If you don't pass the `rindent' as the third parame- ter, you get the same line length, but indented to the right. If it is not the intended behavior, then it is a very long-standing bug in Groff's implemen- tation of MM that I have taken for granted more than ten years. I think I can fix it if you can't once I am sure it *is* a bug.
Re: groff_mm : problems with .DS
Damian McGuckin: > I went back to a very old document using troff and > MM. It is a tutorial on using troff at the macro > package level without needing to know much about > the low level troff. I was contemplating updating > it and putting it out there. > > I am trying to use a display with fill mode on, > i.e. > >.DS 1 1 > > The left margin is indented slightly. Unfortunate- > ly, the right margin is not shrunk by the same > amount with groff_mm. > > I know that the original MM package handled it > flawlessly. > > Does anybody have a fix for this or do I need to > sort out the bug? It did this for me in Groff. I have always specified the `rindent' paramenter, i.e.: .DS I F \n[Si] where `Si' is an MM register storing the left shift indent. The invocation above produces the following text: Thou art nothing. And all thy desires and memo- ries and loves and dreams, nothing. The little dead earth-louse were of greater avail than thou, were it not nothing as thou art nothing. For all is nothing: earth and sky and sea and they that dwell therein. Nor shall this illusion comfort thee, if it might, that when thou art abolished these things shall endure for a season, stars and months return, and men grow old and die, and new men and women live and love and die and be for- gotten. For what is it to thee, that shalt be as a blown-out flame? and all things in earth and heaven, and things past and things for to come, and life and death, and the mere elements of space and time, of being and not being, all shall be nothing unto thee; because thou shalt be noth- ing, for ever.
Re: groff_mm : problems with .DS
Damian McGuckin: > The bug is that while > > .DS 1 > > uses the standard indent, > > .DS 1 1 > > does NOT use the standard indent. Let us maybe share some examples of a) the current and b) the expected behavior. This e-mail is for- matted using mm, with 52 characters per line and the `Si' number register set to 3. With the latest[1] version of mm, the problem I described earlier is not longer present. For `.DS 1` I get: payload payload payload payload payload payload payload payload payload... -- a single long line, indented on the left by \n(Si. The right indent makes no sense because there is no filling. And for `.DS 1 1` I get: payload payload payload payload payload payload payload payload payload payload payload payload payload payload payload payload -- a block of text indented by \n(Si on the left with the line length decreased to maintain the right margin. As you see, in both cases mm respects \n(Si in the determination of the left indent. There is no contradiction. Do you observe the same results? If not, please retest with the latest version. 1. http://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz
Re: groff_mm : problems with .DS
Damian McGuckin to Anton Shepelev: > As you noticed, that 1.22.4 version of '-mm' solved the > fill-mode problem with '.DS'. > > However, when you use > >.DS 1 >.EQ (X) >... equation >.EN >.DE > > it places put the equation number (X) indented from the > right margin, which is wrong. > > I note that 1.22.3 does not have that problem. Since I am not the one who introduced, nor fixed, this bug in .DS, for now I can only venture a conjecture as to what happened. In order to make .EQ work with the broken .DS, a crude crutch had to be introduced that should compensate for the erroneously increased line length. Whatever kind soul fixed the .DS bug in 1.22.4 was unaware of the .EQ crutch and left it in. As a result, it continues shortening the line length. I have assmed you shouldn't mind if I forwarded your valu- able report to the mailing list.
[Groff] Problem with -me package
Hello all! I can't figure out how to make nroff with the -me package output text without inter-page space. Whatever I do, it keeps putting one empty line between pages. I have set the tm value to zero, and when I try to zero the bm (bottom margin) value, nroff exits with a crash saying: input stack limit exceeded, possible infinite loop. Since nroff itself doesn't insert extra emtyline between pages, I suppose this has something to do with the me package. Here's an example: .nr tm 0v .nr bm 0v .pl 5v .nf g h h j j g f d d s s d With it nroff crashes. And if I don't set the bm value, the output contains extra empty lines between pages: g h h j j g f d d s s d Thanks in advance, Anton
Re: [Groff] Problem with -me package
Hello, Ralph I don't know -me so can't answer on your specific problem. But have you tried making the page length very long instead of trying to remove the inter-page Yes, that was the first thing I did. Although I works, the "functinality" of this method is a bit scantier bacause there's no division into pages. And I wonder why setting bm to zero results in groff crashing. Anton
Re: [Groff] Problem with -me package
Ralph Corderoy: I don't know -me so can't answer on your specific problem. But have you tried making the page length very long instead of trying to remove the inter-page gap? And there's another annoyance to this method: the output file will containt at leat one whole page, Imagine writting an email and outputting into a file with about 1000 lines. Or I'll have to adjust the page length every time. It's similar to using static arrays when the exact size is not know beforehand. Anton
Re: [Groff] Problem with -me package
Mike Bianchi To format a document of arbitrary length as _one_ nroff page I use this trick. First, set the page length _very_ long. .pl 9 And then make the last two lines of input a line break and setting the page length to the _current_ page length. .br .pl \\n[nl]u Thanks for pointing out the real nroff way of doing it! Walter Harms: hi Anton, can you please post the groff version and the code that caused the bug ? groff version 1.19.2 Code: -- .nr tm 0v .nr bm 0v Hello, Josephine; How do you do; Do you remember me, baby; Like I remember you? -- Not sure I am doing it right, maybe I just didn't understand what the bm value means... Anton
[Groff] Hyphenation with Russian
Hello all, Is there a way to make nroff process Russian documents cor- rectly and with hyphenation? Anton
Re: [Groff] Hyphenation with Russian
Thank you for the reply, Werner! I have found all the files: koi8-r.tmac, ru.tmac and hyphen.ru (in the koi8-r encoding). The koi8-r.tmac file consists of lines like: .trin \[char186]\[u2568] and I believe it maps UTF-8 to KOI8-R, hence I cocluded the input file should be in the UTF-8 encoding. But alas! it didn't work, reporting errors like this: can't find special character `u2568' But these characters are mentioned in the koi8-r.tmac file, so I don't understand what happens... Anton PS: I have made sure that the koi8-r mapping file is used by renaming it and calling nroff with -mru. > . Select an 8-bit encoding you want to use for the Russian > hyphenation. Only characters in the ranges 0x20-0x7e and > 0xa0-0xfe can be used. Convert your hyphenation patterns to this > encoding; expanding all macros. Use `hyphen.cs' as a template. > > . Set up a mapping from groff input characters (and implicitly vice > versa) to this Russian encoding. Use `latin2.tmac' as a template. > > . Write a language support file which defines a hyphenation > language, activates the characters used for the hyphenation > patterns, and loads them. Use `cs.tmac' as a template. > > That's it! For, say, UTF-8 encoded Russian input files use groff's -k > option to use the new `preconv' preprocessor.
Re: [Groff] Hyphenation with Russian
I have made a break-through! I have made hyphenationn work by just referring to latin1.tmac instead of koi8-r.tmac from ru.tmac. Can anyone explain me how and why it works? With koi8-r.tmac I keep getting that "Special symbol" er- ror... > > I have found all the files: koi8-r.tmac, ru.tmac and > > hyphen.ru (in the koi8-r encoding). The koi8-r.tmac file > > consists of lines like: > > > > .trin \[char186]\[u2568] > > > > and I believe it maps UTF-8 to KOI8-R, hence I cocluded the > > input file should be in the UTF-8 encoding. > > > This is not correct. groff has a fixed set of built-in entities like > \[aq] or \[em] -- this list won't be changed any more. All other > entities get algorithmic names of the form \[u] and some other > forms based on the Adobe Glyph List conventions; please look this up > in the groff info manual if you are interested. It has *no relation* > to the used input encoding except the fact that such glyph names in > its simplest form are using the Unicode character code as part of its > name. > > Werner
[Groff] Filtering our control characters
Hello all, I have read that the easiest way to convert groff output to text is to filter it using the col command. I tried this: groff -man -Tlatin1 test.man | col -bx, but in the result section names still con- tained color-setting characters: 1mSection one0m Is one of the tools (groff or col) doing something wrong? Thanks in advance, Anton
Re: [Groff] Filtering our control characters
Thank you, Werner and Ralph. And I was using sed :P
[Groff] A question about vertical indentation of displays
Hello all, I was experimenting with displays in groff (nroff mode) and found found a problem. Whenever I begin a new paragraph after a display, the vertical in- dent after the display is twice the normal size. Below is an example for the MS macro's .LD dis- play: .LP Test paragraph. The following display will be indented normally .LD The display. The following paragraph will be indented twice. .DE .LP The paragraph. And here's the result: Test paragraph. The following display will be indented normally The display. The following paragraph will be indented twice. The paragraph. A similar behaviour is found in ME's quotation display (.(q. ... .)q). Am I doing something wrong? Thanks in advance, Anton
Re: [Groff] A question about vertical indentation of displays
Ted Harding: > If you are using ms macros, then there are two number registers > to watch out for: \n[PD] "paragraph drop" and \n[DD] "display > drop". \n[PD] defines how much vertical space will be inserted > before starting a new paragraph. \n[DD] defines how much vertical > space will be inserted before *and after* a display. > > So your .DE followed by .LP will insert \n[DD]+\n[PD] between > the bottom of the display and the top of the new paragraph. Hello, Ted, and thank you for your reply. According to what you have said, it is impossible to have the same vertical space before and after a display unless the PD register be set to zero. It doesn't seem quite right to me. Why the asymmetry? Secondly, I couldn't find where the DD register is documented. It's present neither in the MS man page nor in the groff online manual... Anton
Re: [Groff] A question about vertical indentation of displays
>> Ted Harding: >> >>> If you are using ms macros, then there are two number registers >>> to watch out for: \n[PD] "paragraph drop" and \n[DD] "display >>> drop". \n[PD] defines how much vertical space will be inserted >>> before starting a new paragraph. \n[DD] defines how much vertical >>> space will be inserted before *and after* a display. >>> >>> So your .DE followed by .LP will insert \n[DD]+\n[PD] between >>> the bottom of the display and the top of the new paragraph. >> >> Hello, Ted, and thank you for your reply. According to what you >> have said, it is impossible to have the same vertical space before >> and after a display unless the PD register be set to zero. It >> doesn't seem quite right to me. Why the asymmetry? > > It is not an asymmetry. Rather, it is a symmetry (same space above > and below the display, due to \n[DD]). The extra space is coming > from the \n[PD] associated with .LP > > <...> A big-big thanks for the detailed explanation. Anton
[Groff] MS: Keeping the TOC
Hello all, I want the headers (.NH) automatically create TOC entries, for which reason, right in my document's file, I defined the following macro: .de HD .NH \\$1 \\$2 .XS \\$2 .XE .. which creates both a header and a TOC entry for it, so I would no longer bother about the actuality of my TOC. My problem is that even an empty document like this: .TC creates one empty TOC entry, as if groff interprets the .XS ... .XE pair inside the definition of .HD like actual commands... Am I doing something wrong? Is it incorrect to define additional macros inside the document's file? Where to define it then? Thanks you in advance, Anton
Re: [Groff] MS: Keeping the TOC
> In the GNU ms macros, the name "HD" seems to be reserved > for a user-supplied page header and/or footer macro, which > (if it exists) gets called at some place during the page > initialization. Since you have defined HD, this gets called, > and in turn calls XS and XE but with no useful text (since > \\$2 is empty if HD is called without arguments), thus > creating the empty TOC entry. > > So, to answer your question: it is okay to define macros > in the document, but you have to be careful to choose names > which are not already used (unless you want to overwrite a > particular macro on purpose). Thank you very much, Tadziu. Anton
[Groff] Hanging headings in MS
Hello all, Is it possible to modify the MS macro package (by adding some macro (re)defintions) so it would make all headings stick out to the left by the same abount of space? 1. Heading One text text text text 1.1 Heading One.one text text text text text text 2. Heading Two text text more text I can emulate such behaviour using .RS .. .RE but I'd like to make it automatical. Of all the standard packages, MS is the closest to my needs and this is the only change that has to be done. Thanks in advance, Anton
[Groff] Questions about the MM macro package
Hello all, I am learning the MM macro package and have met a couple of problems I couldn't solve after reading the man page: (1) Is it possible to omit the standard page headers without using .LT? (2) My test document begins with a call to the .PGFORM macro, setting a different page width, but the stan- dart header on the first page is still centered as if the page width was default. Is it the right be- haviour? Thanks in advance, Anton
Re: [Groff] Questions about the MM macro package
Mike Bishop: > Anton, > > Everything I learned about MM I learnt from the SystemV/AT > documentation from Microport. I have never found a copy of > that documentation as source on the net. I *did* find a > scanned image of the docs however, at > http://www.tenox.tc/docs/ > under the > Microport SystemV/AT Text Preparation System. Thank you, Mike. I have downloaded the doc and will look into it. Tadziu Hoffmann and Mike Bianchi: I have followed you instructions and still couldn't eliminate the vertical margins. This is my document: - .de TP .. .de EOP .. .PGFORM 30n 19v 0u 1 .PH .VM 0u 0u . Hello, let's test some lists: .AL .LI One .P The first element it was. .LI Two .P Now we approaching a horrible and fearful margin -- the bottom margin of the page, beyond which unknown things await us. Let us close the list. .LE .P List closed. - And here's the output (not the 5-line space between the contents of the first page and the second): Hello, let's test some lists: 1. One The first element it was. 2. Two Now we approaching a horrible and fearful margin -- the bottom margin of the page, beyond which unknown < This is < the empty < space I < am talking < about. things await us. Let us close the list. List closed. Anton
Re: [Groff] Questions about the MM macro package
Tadziu Hoffmann: > >> I have followed you instructions and still couldn't eliminate >> the vertical margins. [...] > >> .VM 0u 0u > > Use ".VM -T 0u 0u". Without the "-T", the arguments specify > *extra* space to add. Thank you, and sorry for the bothering. I did read it in the man-page but misunderstood. Thought 'extra' meant 'additional to the page height'. If it wasn't due to my bad English, may I suggest a different wording: Increments the top and bottom margins by _top_ and _bottom_ accordingly. If option -T is specified, sets those margins to _top_ and _bottom_. I think that would be clearer. Anton
Re: [Groff] Questions about the MM macro package
Mike Bianchi: > Let's try again: > > I've commented out .PGFORM, .PH and .VM. > > I've replaced them with the nroff/troff/groff basic commands > .pl page length > .ll line length > .po page offset > Thank you, Mike. Tadziu HOffman has pointed out my mistake: I was incorrectly using the VM macro -- To set the margins to zero it had to be called with the -T key: .VM -T 0u 0u While the man page says: "No argument resets the margin to zero or the default (7v 5v) if -T was used.", neither '.VM' nor '.VM -T' does set zero vertical margins and the only way to do it seems to use the above call with -T and with arguments. Anton
Re: [Groff] Questions about the MM macro package
> > If it wasn't due to my bad English, may I suggest > > a different wording: [...] > > I've committed something along your suggestion, thanks. > > > Werner Thanks to you, Werner :)
[Groff] Headers in MM
Hello all, When I saw how MM formats headers the first thing that stroke me was the lask of hanging indent for multiline headers, so I did these little modifica- tion: .de HY .length a \*(}0 .in +\nan .ti -\nan .nr ;0 2 .. .de HZ .in 0n .. It produces headers like this: 1. This is a very long hearer. Note the hanging indent. I'd like to ask you whether this modification is ideologically correct and whether it won't produce undesirable side effects. Thank you in advance, Anton
[Groff] Re: Headers in MM
Me: > Hello all, > > When I saw how MM formats headers the first thing > that stroke me was the lask of hanging indent for > multiline headers, so I did these little modifica- > tion: Sorry, I forgot to escape slashes in the source code, so all double slashes turned to single ones. Here's the correct code: .de HY .length t \\*(}0 .in +\\ntn .ti -\\ntn .nr ;0 2 .. .de HZ .in 0n .. Anton
Re: [Groff] Headers in MM
Mike Bianchi: > Anton, > > Since HX, HY and HZ are initialized as empty, and hence no-ops, using them to > do anything that works for you is just fine. > > The one thing to be careful of is using knowledge of the implementation > obtained by reading the code. Any of that can be changed. > > In this case, you use the }0 string, which is documented in the code > (file m.tmac) as being available for use within a user-provided HX macro. > I'd say you are very safe there. > > Using a as the name of a number register is more risky as it could easily > conflict with another temporary register elsewhere. groff supports long > names and that helps avoid collisions. (See register temp_indent_ below.) > (I always use the \*[name], \n[name], etc. style of reference, even for > 1- and 2-character references. They stand out better and all references > look alike.) > > In playing with your example, I found that it was nroff specific, since > .length gives a character count and your indent and outdent are in terms > of n units. The following also works in troff/groff. It obtains the > width of the }0 mark in troff/groff's "units" (aka "scaled points") > from the \w'string' escape sequence, and then uses it that way. > Thank you very much, Mike Anton
[Groff] Groff 1.19.2 and 1.20.1 differences
Hello all, I have found a difference in groff's behaviour on my home computer (groff 1.19.2) and at work (groff 1.20.1). Note the vertical spacing and the merging of paragraphs: Here's the first test file: .de TP .. .de EOP .. .PGFORM 60n v 0n 1 .de HY .length antI \\*(}0 .in +\\n[antI]n .ti -\\n[antI]n .nr ;0 1 .. .de HZ .sp -1v \" To get the spacing right (at least, for groff 1.19.2) .. .VM -T 0v 0v .nr Ej 1 \" .nr Hb 5 .nr Hs 0 .nr Hi 0 .nr Dsp 1v \" Vertical space around static displays .nr Si 2 .H 1 "NAMING CONVENTIONS" .H 2 "Capitalization" .P Short .P Short .AL .LI Hey .LI Hey Now, in Groff 1.20.1 there'll be no space between this paragraph and the next. .LE .P Short paragraph .PGFORM 40n \n(nlu Result in groff 1.19.2: 1. NAMING CONVENTIONS 1.1 Capitalization Short Short 1. Hey 2. Hey Now, in Groff 1.20.1 there'll be no space between this paragraph and the next. Short paragraph Result in groff 1.20.1: 1. NAMING CONVENTIONS 1.1 CSahpoirttalSihzoarttion 1. Hey 2. Hey Now, in Groff 1.20.1 there'll be no space between this paragraph and the next. Short paragraph Second test file: .de TP .. .de EOP .. .PGFORM 60n v 0n 1 .VM -T 0v 0v .P Short .P Short .H 1 "NAMING CONVENTIONS" .P Short .P Short .PGFORM 40n \n(nlu Result in groff 1.19.2: Short Short 1. NAMING CONVENTIONS Short Short Result in groff 1.20.1: Short Short 1. NAMING CONVENTIONS Short Short I'd like to know which version works correctly. Thank you in advance, Anton
Re: [Groff] Groff 1.19.2 and 1.20.1 differences
Thanks to everybody )) and especially to Mike Bianchi for volunteering to fix the bug. By the way, what about Jurgen Hogg, the author of m.tmac whose e-mail is still in the file as the address to sent bug reports to? Anton
[Groff] Hanging paragraphs in MM
Hello, all I often need to typeset single hanging paragraphs like: PS: Example of a post-scriptum, it has a hanging indent. I have created a macro for this, which 1. Calculates the length of the label and increments it by one, 2. Begins a variable-item list (MM's .VL) with the calculated indent, 3. Typesets the desired paragraph as one list item (MM'c .LI), 4. Ends the list (MM's .LE). But to use it, I have to pass both label and text as macro parameters, while I'd like to pass only the label and have the text on the next input line (like it is done in MAN's .TP macro, for example). Could you please suggest a way of doing it? Maybe I better emulate it using groff's requests (and take care not to meddle with MM's inner logic)? Thanks in advance, Anton
Re: [Groff] Hanging paragraphs in MM
Ted Harding: > One "hack" which might lead to what you want is to calculate an > indent based on the width of the tag "PS: ", and then increment > the line-indentation once the paragraph has been started (but > you would need to reset it at the end of the paragraph): > (Note the use of the unstretchable space "\ "). With Type 0 para: > > .nr indnt \w'PS:\ ' > .P > PS:\ This is a hanging paragraph. > .in +\n[indnt]u > This is a hanging paragraph. I have made your code a bit simpler: .nr indnt 120 .in +\n[indnt]u .ti -(\n[indnt]u) PS:\ Example of a post-scriptum, it has a hanging indent. .in -\n[indnt]u But I was asking how to do it using a macro just like you mentioned it was made in MS. Anton
Re: [Groff] Hanging paragraphs in MM
Mike Bianchi: > Anton, > Could you just use \ to continue the macro onto your next line? > > .MyMacro FirstArg \ > All the text that is processed by MyMacro FirstArg follows. Thanks for the hint. I thought about it and con- sidered it a sort of 'quick and dirty' (not encouraging structured style)... Maybe I am wrong? Anton
Re: [Groff] Hanging paragraphs in MM
Me: > > I have made your code a bit simpler: > >.nr indnt 120 >.in +\n[indnt]u >.ti -(\n[indnt]u) >PS:\ Example of a post-scriptum, it has a hanging indent. >.in -\n[indnt]u I forgot to escape the \w request (first line). Here's the corrected verstion: .nr indnt \w'PS:\ ' .in +\n[indnt]u .ti -(\n[indnt]u) PS:\ Example of a post-scriptum, it has a hanging indent. .in -\n[indnt]u Anton
Re: [Groff] Hanging paragraphs in MM
Mike Bianchi: > When I do need something special or "improved" then I make my own macro > and carry it around with me. I have my own MM macros that I > have carried around for decades, going back to my days at Bell Labs. I wonder, how do you 'deploy' your own MM macros? Just pick the ones you need and copy them to the beginning of your .mm file? > I worked two floors up from the folks that created MM and was one of the > earliest users. (stories upon request) I sure would like to hear them! > > So if you don't want to use the \ idea, > by all means create something of your own. I can manage a two-part macro like .(MyPS and .)MyPS, so I could reset the indent upon exit. But I don't know how to do it using only one macro. I probably have to 'subscribe' to some 'call-back' macro that gets called every time a paragraph (in groff's sense) ends. Does groff or MM have such a macro? Thanks for your feedback, Anton
Re: [Groff] Hanging paragraphs in MM
Ralph Corderoy: > Hi Anton, > > > I can manage a two-part macro like .(MyPS and .)MyPS, so I could > > reset the indent upon exit. But I don't know how to do it using only > > one macro. I probably have to 'subscribe' to some 'call-back' macro > > that gets called every time a paragraph (in groff's sense) ends. Does > > groff or MM have such a macro? > > Are you aware of the .it request; input trap? `.it N xx' calls macro > xx after N lines of input have been read, excluding control and request > lines. Thanks for the suggestion. It will work only for source texts without hard line breaks within para- graphs. But to GROFF, as I understand, a paragraph is a sequence of non-empty lines not beginning with certain control commands, which means I have to know the number lines my paragraph will occupy before it has actually been typeset. Or I have to stick to long lines (one per para- graph), but then what about formatting on word level (like make one word bold)? Anton
Re: [Groff] Hanging paragraphs in MM
Tadziu Hoffmann: > >> I can manage a two-part macro like .(MyPS and .)MyPS, >> so I could reset the indent upon exit. But I don't know how >> to do it using only one macro. I probably have to 'subscribe' >> to some 'call-back' macro that gets called every time a >> paragraph (in groff's sense) ends. Does groff or MM have such >> a macro? > > I don't think you can do it with just one macro if you don't > want to give the whole paragraph text as a macro argument. > (How is the code to know when the indent should be over?) > But, as you suggested, you can implicitly reset the indent > when a "normal" paragraph is started. I don't think mm has > a hook for this, but you can "wrap" mm's paragraph macro with > additional code: <...> Thank you, Tadziu. I understood your example. Now I am prying into the implementation of the .TP macro in MAN... Anton
Re: [Groff] Hanging paragraphs in MM
> Ah, yes. In the manpage macros, this works similarly: all > paragraph macros reset the indent to what it "should" be > (so that any ".in" invocations within a paragraph will be > undone at the beginning of the next paragraph). That is, > ".TP" absolutely sets the indent to "something" + "extra", > and ".PP" sets it back to "something". > > The biggest difference is that ".TP" does not get the tag > as an argument, but instead reads it from the next line of > input: an input-line-count trap of one line is set and text > read for the tag is temporarily diverted, for the purpose of > determining whether the tag is wider than the extra indent > (the tag is set on a line by itself if it is). > > Since the input-line-count trap only counts "real" lines of > input, you can do fancy stuff such as special formatting of > the tag: Thank you. I think I am beginning to understand this macro. I got a connected question about traps. The .SH macro can handle the section head- ing both as a parameter and the next input line, and in both cases the an-trap trap is invoked afted that line has been typeset. The trap is set by .it 1 an-trap, so I why is it fired after the section text even is it was passed to .SH as parameter? Are macro parameters handled as input lines? Anton
Re: [Groff] Hanging paragraphs in MM
> Ah, yes. In the manpage macros, this works similarly: all > paragraph macros reset the indent to what it "should" be > (so that any ".in" invocations within a paragraph will be > undone at the beginning of the next paragraph). That is, > ".TP" absolutely sets the indent to "something" + "extra", > and ".PP" sets it back to "something". > > The biggest difference is that ".TP" does not get the tag > as an argument, but instead reads it from the next line of > input: an input-line-count trap of one line is set and text > read for the tag is temporarily diverted, for the purpose of > determining whether the tag is wider than the extra indent > (the tag is set on a line by itself if it is). > > Since the input-line-count trap only counts "real" lines of > input, you can do fancy stuff such as special formatting of > the tag: Thank you. I think I am beginning to understand this macro. I got a connected question about traps. The .SH macro can handle the section head- ing both as a parameter and the next input line, and in both cases the an-trap trap is invoked afted that line has been typeset. The trap is set by .it 1 an-trap, so I why is it fired after the section text even is it was passed to .SH as parameter? Are macro parameters handled as input lines? Anton
Re: [Groff] Hanging paragraphs in MM
On 3 Jun 2010 at 10:01, Ralph Corderoy wrote: > > Hi Anton, > > > The trap is set by .it 1 an-trap, so I why is it > > fired after the section text even is it was passed > > to .SH as parameter? Are macro parameters handled > > as input lines? > > No, I think you'll find it's this line, > > . if \\n[.$] \&\\$* So input is not just the source file. Thank you! Anton
Re: [Groff] Replacing groff with troff?
Maybe this document will be of interest for the readers of this thread: http://2009.asiabsdcon.org/papers/abc2009-P6B-paper.pdf Anton
[Groff] Problem with bottom page margin in MM
Hello all, I have found a problem with pagination in MM. In the following example, the bottom margin is dif- ferent for the first page (which ends with a filled line of text) and the second page (which ends with a non-filled line of a footnote). To the left is the source and to the right the result: --- .de TP What the white whale was to Ahab, has been hinted; .. what, at times, he was to me, as yet remains .de EOP unsaid. Asidefrom those more obvious .tl ''- % -''considerations touching Moby Dick, which could not .. but occasionally awaken in any man's soul some .PGFORM 50n 20v 0i 1 alarm, there was another thought, or rather vague, .VM -T 0v 2 \"Doesn't work with bottm margin 2v nameless horror concerning him, which at times by causing infinite loopits intensity completely overpowered all the rest; .and yet so mystical and well nigh ineffable was .P it, that I almost despair of putting it in a What the white whale was to Ahab, has been hinted; comprehensible form. It was the whiteness of the what, at times, he was to me, as yet remains whale that above all things appalled me. But how unsaid. Aside from those more obviouscan I hope to explain myself here; and yet, in considerations touching Moby Dick, which could not some dim, random way, explain myself I must, else but occasionally awaken in any man's soul some all these chapters might be naught. alarm, there was another thought, or rather vague,
[Groff] Re: Problem with vertical margins in MM
Hello all, Looks like my previous message's text was over- wrapped by the mailing list engine. It looks that way in the mailing list archieve. If was not a display problem and you recived the garbled ver- sion, I'll re-post my message. Sorry for the inconvenience, Anton
Re: [Groff] Problem with bottom page margin in MM
Tadziu Hoffmann: > Anyhow, the upshot of all this is that if you're only working > with character-cell devices with fixed baseline spacing, just > remove the "+1v" and all should be fine. If you're also using > high-res devices, you'll probably need to rethink mm's setting > of trap positions. (I'll leave that to those who actually use > mm.) Thank you, Tasziu, Could another solution be to modify MM so that it would add the 1v space conditionally based on whether it is t (troff mode) or n (nroff mode)? Anton
Re: [Groff] Problem with bottom page margin in MM
Tasziu Hoffmann:
> Yes, of course. But that "+1v" is also "wrong" in troff mode.
> Better to always use
>
> 'sp |\\n[pg*foot-trap]u
>
> (without the "+1v") in addr...@hidden, and
>
> .if n .wh \\n[pg*foot-trap]u addr...@hidden
> .if t .wh \\n[pg*foot-trap]u-1v+1u addr...@hidden
>
> in addr...@hidden
Thank you for your reply, Tadziu.
I didn't understand how your code will work. The
p...@footer trap performs a move to a position spec-
ified by an absolute distance, while you only pro-
pose to change the line at which the trap is trig-
gered. This will not change the way it prints the
footnotes, becuase it uses absolute addressing
inside. Or maybe I am misunderstanding something?
Here's my solution (I did't want to change m.tmac
itself):
.am p...@set-new-trap
. if n \{\
. if \\n[ft*note-size]>0 .nr pg*foot-trap -1v
. \}
..
which changes the position at which the footnotes
are printed. I have tested it in nroff mode.
Here I am re-calculating the height of the foot-
note block to compensate for the +1v in the
pg*foot-trap register, which needs to be done only
if there are footnotes.
Looks like the problem may lie not in the way
groff invokes traps, but in the calculation of the
pg*foot-trap register. I'll check how groff type-
sets the same example in PostScript.
Anton
Re: [Groff] Problem with bottom page margin in MM
Tadziu Hoffmann:
> [...]
>
> > .am p...@set-new-trap
> > . if n \{\
> > . if \\n[ft*note-size]>0 .nr pg*foot-trap -1v
> > . \}
> > ..
>
> I think that leaves you with more space before the footnotes
> than necessary in nroff (but the bottom margin is okay),
> but in troff you still have the problem that the footnotes
> get printed 1v into the bottom margin.
Thanks for the explanation, Tadziu.
In nroff mode, both modified and unmodifed ver-
sions leave one line between text end and footnote
start (the separator), but I have found a
way to affect that as well:
.am p...@set-new-trap
. if \\n[ft*note-size]>0 \{\
. nr pg*foot-trap -1v
. \}
..
.am p...@enable-trap
. if \\n[ft*note-size]>0 \{\
. ch p...@footer (\\n[pg*foot-trap]u+1v)u
. \}
..
Again, I have only tested it in nroff mode. The
second 'append' causes the trap to fire one line
later thereby eliminating the abovementioned 1v
space.
Re: [Groff] Problem with bottom page margin in MM
Macro names containing the e-mail 'dog' symbol got
replaced with addr...@hidden. Here's an updated
version, where [dog] is used istead of the actual
symbol:
.am pg[dog]set-new-trap
. if \\n[ft*note-size]>0 \{\
. nr pg*foot-trap -1v
. \}
..
.am pg[dog]enable-trap
. if \\n[ft*note-size]>0 \{\
. ch pg[dog]footer (\\n[pg*foot-trap]u+1v)u
. \}
..
Anton
Re: [Groff] Groff 1.19.2 and 1.20.1 differences
Tadziu Hoffmann: The error must have been introduced between 1.19.2 and 1.19.3, and it's a bug in the mm macros, not in troff, as you can see by sourc- ing the 1.19.2 mm macros with troff 1.20.1 (and vice versa). If you edit the current mm macros and move the addr...@hidden call in the definition of the paragraph macro outside the conditional (as in the 1.19.2 mm macros) (and additionally delete the devtag macro calls because the seem to introduce unwanted empty lines), I think you get the correct behavior. I have determined that this bug was introduced in the version 2.33 of m.tmac. The difference between 2.32 and 2.33 is very little -- just one line that moves the call to par[at]doit inside the condi- tion. The patch's description says it immplements the skipping of .P after .H. I suggest that this patch should be undone because it introduced the bug. Anton
[Groff] MM's nested lists: AL inside BVL
Hello all, Nested lists work well in MM most of the time, but I have just found a situation wherein MM seems to have a problem: .de TP .. .de EOP .. .PGFORM 40n 20v 0u .BVL 2 .LI "Correct:" This item looks ok. .AL .LI One .LE .LI "Incorrect:" After .AL, our BVL list has broken. .LE Here's the result: Correct: This item looks ok. 1. One Incorrect: After .AL, our BVL list has broken. Note: The same example runs off well if .AL be changed to antoher list style, like .DL. Anton
Re: [Groff] MM's nested lists: AL inside BVL
Tadziu Hoffmann: > BVL's list type is "-1". When LE restores the > outer list's settings via l...@pop and m...@pop-nr, > the list type is reset as > >.nr \$2 \*[misc*pop] > > where \$2 ist the register name (in this case, > "li*type") and \*[misc*pop] is the saved type (in > this case, "-1"). But this gets interpreted as an > increment, not as the number itself. You can fix > it by changing the above line in m...@pop-nr to > >.nr \$2 0\*[misc*pop] Thanks. And I found this out myself some 10 mintes ago. My fix was to use round brackets: .nr \$2 (\*[misc*pop]) I was writing an e-mail to the mailing list when your reply came ) Anton
Re: [Groff] MM's nested lists: AL inside BVL
Hello all, I think, although it is not explicitly documented, it is inferrable from the desctiprion of the \n escape: Interpolate number register with name IDENT (one-character name I, two-character name ID). This means that the value of the register is expanded in-place while gtroff is parsing the input line. Nested assignments (also called indirect assignments) are possible. [Then some examples follow which it might be useful to supplement with a sample of the dis- cussed behaviour...] Now that the reader knows that \n performs textual expantion, it is logical how the assgnment of a neg- ative value can turn into a decrement. My humble opinion is that such behaviour is asymmet- rical (decrement for negative values, but assignment for positive ones) and not evident form the first sight, and that it could be changed by delegating the increment/decrement operation to a separate request (like .ir). Yes, this will render all existing sources incompat- ible and require their authors to replace all decre- ments and increments with the new escape :P Anton
Re: [Groff] MM's nested lists: AL inside BVL
Ted Harding: > That -- the asymmetry -- is also my feeling > exactly! However, I think the increment/decrement > operation is best left alone! Consider: So you show a way to make Groff do what you want it to do, but my mind either inattentive or lazy and therefore prone to human mistakes, which makes me incline to "Safe" programming languages (Pascal in preference to C, for example). So I might even write some "Safe" macros if I found myself bumping too often into this kind of error: \" Common wrapper for safe assign, increment \" and decrement operations, not to be used \" directly. .de cAS . nr \\$1 \\$2(\\$3) .. \" Safe assign .de NR . cAS \\$1 "" \\$2 .. . .\" Decrement register $1 by value $2 .de DR . cAS \\$1 - \\$2 . .\" Increment register $1 by value $2 .. .de IR . cAS \\$1 + \\$2 .. But where to stop? I might end up with a wrapper around groff... > and, later: "When interpolated, a number register > is converted into decimal (default), decimal with > leading zeros, lower-case Roman, upper-case Roman, > lower- case sequential alphabetic, or upper-case > sequential alphabetic, according to the format > specified by 'af'." I too thought about .af when saw it in Tadziu's example. My idea was to introduce a format that would expand into a value in parentheses, but it would be adding another dimenstion to formats, not just another format, which is wrong. > And, while you're at it, you might as well always > bracket it since the "+" prefix will still work as > before with the brackets,... So all one needs to be happy is just to be aware of the feature and do some extra writing to take it into account. Anton
[Groff] tbl: contolling table width
Hello all, I am trying to adopt tbl for typesetting tables and have found one problem that I don't know from which side to approach. It is connected with table width. How to make my tables' width dependent on the line length setting? For example, should I want to type- set my document with another line width, I'd prefer to change only one setting instead of modifying the format strings of all the tables. The problem is that tbl is a pre-processor and no register interpolations are made by tbl. In the simplest scenario it can be assumed that only the last column of my tables must be 'stretchable'. Is it possible to have its width automatically adjusted so that the table would take maximum possi- ble width (taking into account the current indent)? Thank you in advance, Anton
Re: [Groff] tbl: contolling table width
Mike Bianchi: > Are you using the expand global option? See > tbl(1). That makes the table as wide as the line. No. It doesn't allow me to decide which column to stretch. Anton
[Groff] tbl: contolling table width
Werner Lemberg: > Then what about the `x' column specifier? Thanks. I was 'fixed' on the 'w' specifier. Ted Harding: > Meanwhile, looking for something "clever"... May I ask you if you have found it? Anton
Re: [Groff] tbl: contolling table width
Hello, Ted > Well, this is an approximation to "something > clever", but it is definitely "work in progress"! See how your example can be rewritten using tbl's registers: The line below is the current line-length: .br \D'l \n[.l]u 0' .TS tab(#); |l2 | l2 | l2 | l |. _ Row 1, Col 1 A A A#Row 1, Col 2#\ Row 1, Col 3#Row 1, Col 4 Row 2, Col 1#Row 2, Col 2#Row 2, Col 3 AA#\ Row 2, Col 4\h'2m'X Row 3, Col 1#Row 3, Col 2 A#Row 3, Col 3#Row 3, Col 4 Row 4, Col 1#Row 4, Col 2#Row 4, Col 3#Row 4, Col 4 A A A\ \h'|\n[.l]u-\n[3w0]u-\n[3w1]u-\n[3w2]u-8n' _ .TE I don't know how to cope with the additional 8n decrement, but will look into it. One could probably write a while-loop that would add all 3w* registers and their corresponding inter-column spaces! Anton
[Groff] The \D request in nroff and troff modes
Hello all, I have found what may be a bug either in tbl or in groff's \D request. Or I don't understand how either works. The same piece of code typesets differently in troff and nroff modes: .ll 36n .br The line below should be the current line-length: .br \D'l \n[.l]u 0' .br Note how the left margin of this text corresponds with the left end of the above line in troff mode and is one symbol shorter in nroff mode. The table below has exactly the same problem with its rulers: .TS expand tab(@); l l. _ l...@right _ .TE When typeset in nroff mode, the lenght of the ta- ble's rulers, as well as of the line drawn with the \D request, is one syblol more than the actual line length, while in nroff mode they are well aligned. Below is the output of nroff: The line below should be the current line-length: - Note how the left margin of this text corresponds with the left end of the above line in troff mode and is one symbol shorter in nroff mode. The table below has exactly the same problem with its rulers: - Left Right - Is this the correct behaviour of \D? If so, then this should be comensated for somehow in tbl, for it uses the same request to tables' rulers. Anton
[Groff] Re: The \D request in nroff and troff modes
Here's a simpler example in which the length of the line produced by the \D'l' request differs twice in nroff and troff: .ll 36n .br The line below should by one symbol long (one "en"): .br .sp 1v N - this is for reference. .br .if t .sp -0.8v \D'l 1n 0' Here's the nroff result: The line below should by one symbol long (one "en"): N - this is for reference. -- The troff result is shown in the following screen- shot: http://a.imageshack.us/img196/981/troff.png Why is an nroff line always longer than a troff line drawn using the same request? Is it connected with character-cell quantization? Anton
Re: [Groff] The \D request in nroff and troff modes
Hello, Werner. Many thanks for the info. I see that the problem lies deeper than I had thought. > It's obvious that the values 0..23 are somehow > 'assigned' to character cell 0, and for orthogo- > nality we have to assign position 24 already to > character cell 1. This is indeed only meet and logical. The 24th unit is not a boundary between cells, but the first 'bit' of the next cell. The boundary has no size and is between the 23rd and 24th units. > Another complication is that everything which > specifies a length is rounded internally to be > multiples of either \n[.H] or \n[.V]. In nroff > mode this means that a horizontal length of 12u is > still one character cell, but 13u is rounded up to > be two character cells. H. But shouldn't 12u round to zero and 13u to one (this would make lines one symbol shorter). Does grotty 'see' the rounded values? > Does this explain why a single horizontal line is > one character cell too long? > <...> > BTW, if you always shorten horizontal lines by a > small correction value, the above tables look like > this: So this is done generally to help tbl draw tables properly? If it is so, then it keep tbl device-inde- pendent but makes the \D request tbl-dependent... Anton
Re: [Groff] The \D request in nroff and troff modes
Werner Lemberg: > I've just tested heirloom troff, and it doesn't > support \D'l ...' with nroff. Consequently, I > think AT&T nroff doesnt' do it either. Does this mean that tbl can't make horizontal rulers in its tables in nroff mode, or is the drawing of them implemented bypassing \D'l...'? Anton
Re: [Groff] How to disable page numbering
Ted Harding: > When you use the 'ms' macros, there is no macro > ".PO", so your ".PO 0" would have no effect. The lack of warning/error messages can be mislead- ing. At least, it had been so with me until I dis- covered that they must be turned on with the .warn request. Werner, would it be better to have warnings enabled by default? Anton
Re: [Groff] How to disable page numbering
Werner LEMBERG: > Mhmm. I don't think so. Compare this to gcc's -W > switches which are off by default too. I don't > see an immediate need to change a behaviour which > has been unmodified for more than 20 years. But there is a difference compared to gcc. Missing (undefined) macros are considered by groff not as errors but as problems that may or may not, depend- ing on the settings, be reported as warnings, but that in no way cause a "compilation error", which makes groff (with default settings) chew and swallow almost any input without a mumbling word. The question is, how to distinguish between a warn- ing and an error. As I understand, every problem that denies futher processing is considered an error, and everything else goes as warnings. This approach is useful for it would not interrupt pro- cessing at the first problem and, by means of warn- ing messages, let the user know about all the prob- lems in the source in one pass. But why would one want all warnings disabled I cannot imagine. Therefore, an undefined macro is not an error from groff's viewpoint, because the corresponding input line can be omitted, but it is an error from the user's viewpoint, because the result is a digression from what is intended. All macro packages that I have tried do enable warn- ings if they are not explicitly enabled from the command line. Chris Velevitch, the original poster, seems to have not included a macro package and all his calls to package-specific macros were silently ignored. Anton P.S.: Thought I'd just let you know my viewpoint.
Re: [Groff] R.I.P., Miklos Somogyi
May the earth be soft to him.
[Groff] Groff, Grohtml and Encodings
Hello all, I thought I had solved all encoding problems until I tried to export my documetns into the HTML format. It seems that my understanding of how groff maps input charactes into its internal charactes and then into output glyphs is incomplete. Below I have described what I was doing and what results I got. I have a KOI8-R encoded file that has the following letters, in the hex notation: F0, C5, D2, D7, D9, CA I am using the koi8-r.tmac file, which maps these letters as follows: -- Char hex Char dec Mapped char -- F0 240\[u041F] C5 197\[u0435] D2 210\[u0440] D7 215\[u0432] D9 217\[u044B] CA 202\[u0439] -- The values in the third column match the Unicode codes for the corresponding letters of the Russian language. When I process this file using the follow- ing MSDOS batch script type %1 | groff -mkoi8-r -t -Thtml > %2 groff outputs six (one per each symbol) warning mes- sages of the form: stdin:1: warning: can't find special character '', Where sequentially assumes the following values: u041F, u0435, u0440, u0432, u044B, u0438_0306, which is exactly what the corresponding input char- acters map to except for the last one, which turned into a composite code for a reason unknown to me. The resulting html file looks quite correct and con- tains the following: Первый These decimal values correspond to the values of the internal characters in the table above. The -mkoi8-r does work correctly, as I have tested by removing it. Here's what I do not understand and I would appreci- ate your help with: 1. I tried to define glyphs for the characters reported in the abovementioned warnings, in the ...\font\devhtml\r file like this: u041F 24 0 0x041F, but this did not affect either the output or the warning messages. Aren't these warnings about missing glyphs in the font file? If they are, then why didn't my defining the glyphs for those characers work? 2. Why did the last warning mention the composite character u0438_0306 instead of the original u0439, to which it is mapped by the koi8-r.tmac file? 3. I saw the line"unicode"inthe ...\font\devhtml\desc file, but the descrip- tion of the DESC format does not mention the possibility of such a line. What does it do? 4. How to set up groff to accept koi8-r-encoded files and output html pages a. with the same ecoding, b. with the UTF8 encoding? Thank you in advance, Anton
Re: [Groff] Arithmetic of Units
Michael Witten: > 7i/2u=> ((7i)/2)u => 3.5iu <--- WTF? Numeric registers are dimentionless, and the speci- fied unit of measurement only affects how the dimen- tionless value it follows is to be scaled. In this example: 1. 7i = 7 * 240 = 1680 (because 1i = 240u), 2. Then this value is divided by 2 yielding 840. 3. Finally, 840 is left unchanged (because 1u=1u) Anton
[Groff] Re: Groff, Grohtml and Encodings
Myself: > 1. I tried to define glyphs for the characters > reported in the abovementioned warnings, in > the ...\fontevhtml\r file like this: > [...] Now I am trying to understand a very simple case: for the latin1 device, no font definition contains a glyph named [`A], while it is this glyph that [char192] maps to (by latin1.tmac). And this works correctly without any warning messages. Where does groff take the definition for this glyph? Anton
[Groff] Re: Groff, Grohtml and Encodings
Another pecuilarity: When I use: troff -mkoi8-r -Thtml test.roff > test.out it works correctly and does not issue any warning messages, but the command pre-grohtml troff -mkoi8-r -Thtml test.roff > \ test.out does issue the "can't find special character" warn- ings. What is it that pre-grohtml does that causes them? The only difference in the ouput is that with pre-grohtml the line "F test.roff" turned into two lines: F - F ./test.roff Nothing else changed, and the glyphs reported as missing were still there... Why the warnings? Anton
[Groff] Re: Groff, Grohtml and Encodings
Myself: > Now I am trying to understand a very simple case: > for the latin1 device, no font definition contains > a glyph named [`A], while it is this glyph that > [char192] maps to (by latin1.tmac). And this works > correctly without any warning messages. Where does > groff take the definition for this glyph? Yeah, I confused octal and hexadecimal numbers in the font files for devlatin1 and devhtml. The glyph is there and works as expected. Sorry. I tried adding a new line to ...\font\devutf8\r: u0410 24 0 0x411 deliberately incrementing the device code by one, and it did work! Why doesn't the same action (when tested with the same input file) work for ...\font\devhtml\r? What is the difference? And where are the glyph definitions taken from when not defined in the font file? Thanks in advance, Anton
Re: [Groff] Groff, Grohtml and Encodings
Werner, > For me it works [...] Sorry, I checked it again and it had the expected effect. Must have been doing something wrong. > ??? I have this line in font/devlatin1/R: > > `A 24 0 0300 I already got it and wrote about it, but the post probably made it to the list too late. > These warning messages are harmless. Reason is > that grohtml processes the input twice: One time > with -Thtml for text and a second time with -Tps > for everything which grohtml can't handle. This > second run causes the warning messages. Thanks for the explanation. I have read about the double-pass method on the grohtml page but failed to attribute the warnigs to the -Tps pass. > Admittedly, this is badly documented if at all. I > would be glad if you could provide patches to > improve that. The two-pass method is described in the info file, but not in the man page, so I will add it to the man page and modify both man and info by: a. adding a note about such warnings, b. stating that grohtml has built-in glyphs for all non-composite unicode characters named u[X[X]]. > > 3. I saw the line "unicode" in the > > ...\font\devhtml\desc file, butthe > > description of the DESC format does not > > mention the possibility of such a line. > > What does it do? > > It is documented both in groff_font(5) and the > groff info manual: Ah, I was looking in the on-line manual: http://www.gnu.org/software/groff/manual/html_node/DESC-File-Format.html# index-g_t_0040file_007bDESC_007d-file_002c-format-2958 thinking it was up-to-date. Now I will prefer the off-line documentation shipped with the distribu- tion. Thanks you very much for the reply, Anton
Re: [Groff] Groff, Grohtml and Encodings
Werber Lemberg: > BTW, does my suggestion w.r.t. Cyrillic PS fonts > work? Yes. Anton
[Groff] Re: groff man-page incompatibility
Werner Lemberg: > Note that you are the first who reports this prob- > lem. Actually I did report it under the subject of ".SY macro of the Man package" on the bug-groff mailing list on the 12th of October, 2009. The solution was to delete an obsolette version of an-old.tmac from the "share/groff/site-tmac" direc- tory, so that groff started to use a correct one from: /share/groff/1.20.1/tmac/an-old.tmac I was using groff 1.20.1 from the GNU Win32 distri- bution. This seems to be a problem with the Windows distribution of groff. Anton
[Groff] Re: groff man-page incompatibility
Werner Lemberg: > Have you reported it to the GNU Win32 people? > Apparently, this hasn't been fixed yet. I done done it: In the groff 1.20.1 distribution the package an_old.tmac located at GnuWin32\share\groff\site-tmac\an_old.tmac is outdated, while the correct up-to-date ver- stion is located at: GnuWin32\share\groff\1.20.1\tmac\an-old.tmac Fix: In order to make groff "see" the correct file the old file in the site- tmac directory must be removed. Anton
[Groff] Re: groff man-page incompatibility
Werner Lemberg: > > I['ve just] done it: > > Thanks! This is the slang of the black proletarian people of America and can be heard on early blues and r&b re- cords: Oh see, see rider, Just see what you done done, You done made me love you, And now your man done come. Anton
Re: [Groff] Groff, Grohtml and Encodings
Werner Lemberg: > These warning messages are harmless. Reason is > that grohtml processes the input twice: One time > with -Thtml for text and a second time with -Tps > for everything which grohtml can't handle. This > second run causes the warning messages. > [...] > Admittedly, this is badly documented if at all. I > would be glad if you could provide patches to > improve that. Below is what I've added to the Description section of grohtml man page. This is the first time I have made a documentation patch, so I thought I better post it here so you could review it. I am not sure I did it correctly, maybe I should have added my text into a new section like "Operation" or "Details" instead of cluttering the succinct "Description"... grohtml invokes groff twice. In the first pass pictures, equations and tables are ren- dered using the ps device, and in the second pass HTML output is generated by the html device. grohtml always writes output in the UTF-8 encoding and has built-in entities for all non-composite unicode characters. However, groff may issue warnings about unknown spe- cial characters because they were not found during the first pass, when their absence is harmless unless they appear inside a table or equation. The second paragraph is also to go in the grohtml info manual, although it is a violation of the "Once and Only Once" principle -- I don't know why the documentation is maintained in two formats. Anton
[Groff] Problem with devtag macros?
Hello all,
I have returned to the problem with vertical indents
around headings in MM and found the cause of it. The
problem disappeared when removed the call to
.DEVTAG-EO-H macro from the definition of the .H
macro. The devtag macros seem to conflict with MM's
.SP macro.
Then I assembled a small example to demostrate the
effect of .DEVTAG on the output of the ascii device,
which should not exist at all:
.warn
.ll 40n
.\" This is the definition of MM's .SP
.de SP
.br
.if !r line*lp\\n[.z] .nr line*lp\\n[.z] 0
.if !r line*ac\\n[.z] .nr line*ac\\n[.z] 0
.ie \\n[.$] .nr line*temp (v;\\$1)
.el .nr line*temp 1v
.\"
.ie \\n[line*lp\\n[.z]]=\\n[.d] \{\
. \" go here if no output since the last .SP
. nr line*output \\n[line*temp]-\\n[line*ac\\n[.z]]
. if \\n[line*output]<0 .nr line*output 0
. nr line*ac\\n[.z] +\\n[line*output]
.\}
.el \{\
. nr line*ac\\n[.z] \\n[line*temp]
. nr line*output \\n[line*temp]
. \" no extra space in the beginning of a page
.\" This line was commented by me, but has no effect
.\" in the test:
.\" if (\\n[.d]<0):(\\n[pg*head-mark]=\\n[.d]) .nr line*output 0
.\}
.if \\n[line*output] .sp \\n[line*output]u
.nr line*lp\\n[.z] \\n[.d]
..
.\" module misc ###
.nr m...@adjust 14
.de SA
.if \\n[.$] \{\
. if \\$1-1 @error "SA: bad arg: \\$1"
. nr m...@adjust 0\\$1
.\}
.ie \\n[m...@adjust] 'ad
.el 'na
..
.ds dt \%.DEVTAG\-EO\-H
.mso devtag.tmac
After this line two .SP 1v follow
.SP 1v
.SP 1v
As you see, the indent is 1v, which is correct.
.SP 2v
And this paragraph is followed by .SP\ 1v, \*(dt and .SP\ 1v.
.SP 1v
.DEVTAG-EO-H
.SP 1v
It too should have generated a 1v space, but the call to
\*(dt hindered .SP from working correctly.
Output:
After this line two .SP 1v follow
As you see, the indent is 1v, which is
correct.
And this paragraph is followed by
.SP 1v, .DEVTAG-EO-H and .SP 1v.
It too should have generated a 1v space,
but the call to .DEVTAG-EO-H hindered
.SP from working correctly.
I couldn't investigate it deeper, but hope even this
helps.
Anton
Re: [Groff] Groff, Grohtml and Encodings
Werner Lemberg, > This looks fine. Are you going to send a real > patch? Yes. I posted this for review, because otherwise reviewing would require applying the patch... Sorry for the long delay, but even when making small patches a newbie finds it necessary to learn a lot about the things the patch is related to. Also I am having difficulties with makeinfo but hope to solve them. Anton
Re: [Groff] Groff, Grohtml and Encodings
> This looks fine. Are you going to send a real patch? Attached is the patch for grohtml.man. Anton --- grohtml_cur.man 2010-10-30 23:15:36.0 +0400 +++ grohtml_a.man 2010-10-30 23:29:22.0 +0400 @@ -99,6 +99,23 @@ .B \-P option. . +.PP +.B grohtml +invokes +.B groff +twice. In the first pass pictures, equations and tables are rendered +using the +.B ps +device, and in the second pass HTML output is generated by the +.B html +device. +.PP +.B grohtml +always writes output in the \%UTF-8 encoding and has \%built-in +entities for all non-composite unicode characters. However, groff may +issue warnings about unknown special characters because they were not +found during the first pass, when their absence is harmless unless +they appear inside a table or equation. . .SH OPTIONS .TP
[Groff] Re: Problem with devtag macros?
Myself: > The devtag macros seem to conflict with MM's .SP > macro. The problem is that the .tag request confuses the .br request Here's an example: .warn .mso devtag.tmac break before .tag: .br .br .DEVTAG-EO-H after .sp 1v break after tag: .br .DEVTAG-EO-H .br after Output: break before .tag: after break after tag: after Anton
Re: [Groff] Groff, Grohtml and Encodings
Werner Lemberg: Thanks! I've applied it, with slight modifications. Attached is the patch for groff.texinfo. Compared to the corresonding man patch with Werner's correc- tions, I've only added one clause to the end. Anton groff.texinfo.diff Description: Binary data
[Groff] Re: Problem with devtag macros?
Myself: > The problem is that the .tag request confuses the > .br request. I do not understand why the output of a tag-unaware device can depend on tags. I still think it is a bug or a design problem. I have successfully used input line traps to fix this for my particular task (no drawing requests, multicolumn output and complicated nested diver- stions), but I couln't derive a generic criteria to determine whether a .tag request has been called so it could be handled specially in .SP to stop it from generating excess vertical space... Anton
[Groff] Re: Problem with devtag macros?
I wrote: > I do not understand why the output of a tag- > unaware device can depend on tags. I still think > it is a bug or a design problem. Is it so stupid a question? Is this side effect of the .tag request documented anywhere? Anton
Re: [Groff] Re: Problem with devtag macros?
Werner Lemberg: > However, I haven't had time yet to even think > about your particular problem, sorry. All your > emails are sitting in my input queue... Then I wish you to have more time for groff and other joyful things that you like. Anton
[Groff] Re: not a bug but a question
Sergio Villone: > I wonder: is the groff manual written with > groff? if the answwer is "yes" is the source to > this manual available anywhere? just to have a > working example specially for the front cover and > the toc... thank you in advance and sorry for > bothering :-) It was written and is maintained in the TexInfo sys- tem: http://www.gnu.org/software/texinfo/ Also, there are several man pages, which are written in groff, of course. The sources of all this docu- mentation can be found in groff's source repository. For example: http://savannah.gnu.org/projects/groff Anton
Re: [Groff] Re: Problem with devtag macros?
Werner Lemberg: > the vertical effect of .DEVTAG-EO-H is cancelled; > this works just fine with your example. Can you > try whether this works with your documents as a > patch to to mm also? OK, I'll try it. I got a bit sick now and it's hard for me to work at the PC, but I'll do it shortly after the New Year's Day. BTW, wouldn't it be better to patch the tag-generat- ing macros (.DEVTAG-EO-H and others) instead of man- ually adding the code you've provided every time a tag is inserted? This way, neither mm nor any other macro packate that uses tags will have to be fixed. Thank you for looking into the problem, Anton
[Groff] Re: Problem with devtag macros?
Werner Lemberg: > I don't think so. .DEVTAG-EO-H is very low-level > (and since of its beta nature, neither .tag nor > .taga are documented at all); it's a bad idea IMHO > to hardcode any typographical behaviour with it. I still cannot agree with it, because the modifica- tion in question is the removal of a side-effect, not the addition of new behaviour. > Can you try whether this works with your documents > as a patch to to mm also? Yes. Now MM's headings work as expected: producing correct vertical space and even ignoring .P after .H, as per the man page. I have attached a patch to MM, in which a wrapper around tag-generating macros has been added, using the code you provided. Should you agree to patch devtag itself, this wrapper can be turned into a wrapper for the .tag request. Anton m.tmac.diff Description: Binary data
[Groff] Re: Problem with devtag macros?
Werner Lemberg: > I don't think so. .DEVTAG-EO-H is very low-level > (and since of its beta nature, neither .tag nor > .taga are documented at all); it's a bad idea IMHO > to hardcode any typographical behaviour with it. I still cannot agree with it, because the modifica- tion in question is the removal of a side-effect, not the addition of new behaviour. > Can you try whether this works with your documents > as a patch to to mm also? Yes. Now MM's headings work as expected: producing correct vertical space and even ignoring .P after .H, as per the man page. I have attached a patch to MM, in which a wrapper around tag-generating macros has been added, using the code you provided. Should you agree to patch devtag itself, this wrapper can be turned into a wrapper for the .tag request. Anton m.tmac.diff Description: Binary data
[Groff] Re: Problem with devtag macros?
Werner Lemberg: > > > I don't think so. .DEVTAG-EO-H is very low- > > > level (and since of its beta nature, neither > > > .tag nor .taga are documented at all); it's a > > > bad idea IMHO to hardcode any typographical > > > behaviour with it. > > > > I still cannot agree with it, because the modi- > > fication in question is the removal of a side- > > effect, not the addition of new behaviour. > > OK, let's fix this as you suggest. Attached is a patch for devtag.tmac. I wasn't sure about the naming of strings intended for local use (tag-request) and of the macro (TAG). The patch for m.tmac was attached to my previous massage, so use what you think is better. Anton devtag.tmac.diff Description: Binary data
Re: [Groff] Re: Problem with devtag macros?
Werner Lemberg: > This patch I actually dislike since it essentially > means that after DEVTAG there is always a line > break, which is too strong an assumption There's no such assumption. -- If a call to DEVTAG is followed by a break then its side effect is eliminated. -- If a call to DEVTAG is not followed by a break then there's no side effect. All the difference between the two patches is the area of application. The first one only deals with a couple of calls from m.tmac while the second one ensures that every call to DEVTAG or DEVTAG-NEXT does not produce said side effect. They work essen- tially the same way, using the fix you provided. I have tested both patches against the same test file in which both cases (with and without .br) are mentioned, and they gave identical resutls. Anton
Re: [Groff] Re: Problem with devtag macros?
Werner Lemberg: > This patch I actually dislike since it essentially > means that after DEVTAG there is always a line > break, which is too strong an assumption Sorry, you probably mean the resetting of the horisontal position. I now get it. Sorry for bothering, Anton
