[Groff] calling all automake'ers ...
I've been dealing with updates to contrib/gmkdiff within groff, and there is an issue that I could use some help with ... Over the years, the bash-isms of the original shell script have been removed, but the basic algorithm depends of Gnu's sed(1) and diff(1) . As I understand it, it _might_ be possible to have autoconf/automake apply the appropriate changes to the script to use the appropriate version of those commands when it shows up on non-Gnu environments. Solaris is the problematic OS of the moment, but my head swims when I ponder Makefile.am , Makefile.in , etc. Is there any autoconf/automake guru out there willing to help me get this right? Discussion can be found at http://savannah.gnu.org/bugs/?44768 -- Mike Bianchi
Re: [Groff] calling all automake'ers ...
Bertrand Garrigues wrote: > What exactly is the problem with Solaris' `sed' and `diff'? I don't know about sed. Peter Bray says there is a problem with sed. Solaris sed(1) is not up to the task of showing deletions but GNU sed(1) is. I know the current code uses diff -Dname option which is not universal. (forgive the rant please) And I don't have the interest nor time to figure those things out. To my mind the answer is (from the Discussion) ... Until there is a /bin/posix_sh from Gnu, this is going to remain a mess. M4sh illustrates that point, I claim. In my opinion, /bin/bash should be portable, a standard GNU offering, and therefore a reasonable requirement for shell scripts. Likewise, GNU groff insisting on GNU diff and GNU sed is a reasonable requirement. It is also my opinion that backward compatibility, while desirable and a virtue is another way of say "all bugs and limitations are preserved." (rant off) The proposed solution is to aways reference GNU sed and diff, and the suspicion is that is what autoconf and automake are all about. Again, I have no knowledge, let alone expertise, of those tools. I could use help, iff the suspicion is true. Otherwise, I'll just document the lack of universality and commit what I have. Mike On Sat, Apr 18, 2015 at 12:03:48AM +0200, Bertrand Garrigues wrote: > Hi Mike, > > On Thu, Apr 16 2015 at 08:23:21 PM, Mike Bianchi wrote: > > I've been dealing with updates to contrib/gmkdiff within groff, and there > > is an issue that I could use some help with ... > > > > Over the years, the bash-isms of the original shell script have been > > removed, > > but the basic algorithm depends of Gnu's sed(1) and diff(1) . As I > > understand it, it _might_ be possible to have autoconf/automake apply the > > appropriate changes to the script to use the appropriate version of those > > commands when it shows up on non-Gnu environments. Solaris is the > > problematic > > OS of the moment, but my head swims when I ponder Makefile.am , > > Makefile.in , > > etc. > > > > Is there any autoconf/automake guru out there > > willing to help me get this right? > > > > Discussion can be found at > > http://savannah.gnu.org/bugs/?44768 > > I've just read the discussion but I'm not sure to understand: do you > absolutely need the GNU's variant of `sed' and `diff' programs or do you > have a possible substitute for `sed' and `diff' (for example using > Solaris' `sed' and `diff' with different options) ? What exactly is the > problem with Solaris' `sed' and `diff'? Currently, how do you make work > the gdiffmk script on your system, you use -x and -s option with GNU > programs or something else? > > Werner has already given some explanations on how solve this problem: > > "1. In configure.ac (or in m4/groff.m4) a test for the `diff' program >is needed, probably using AC_CHECK_PROGS; autoconf doesn't provide >something in advance – note that the `configure' script itself >already needs the `diff' program, but it doesn't provide a macro; >it simply assumes that it is available in the path. `sed' is >covered by AC_PROG_SED. > > 2. In gdiffmk.sh, use @SED@ and @DIFF@ (or whatever symbols are >actually used in configure.ac) instead of `sed' and `diff'. > > 3. In the sub-makefile `contrib/gdiffmk/gdiffmk.am' you have to extend >the `gdiffmk' rule to substitute @SED@ and @DIFF@ with its real >values." > > The only thing is that AC_PROG_SED, according to autoconf's > documentation, "Set output variable SED to a Sed implementation that > conforms to Posix and does not have arbitrary length limits. Report an > error if no acceptable Sed is found". If Solaris's `sed' complies to > that configure will be happy to use it. So we might need to write macro > that tests the system's `sed' (provoking the problem you see in gdiffmk > on your system) and then make the appropriate substitution. > > Could you please describe what are the problematic `diff' and `sed' > commands on your system? > > Regards, > > -- > Bertrand Garrigues -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] calling all automake'ers ...
Thanks Ralph, but I'm still hoping someone with autoconf knowledge will know
what to do.
Mike
On Sat, Apr 18, 2015 at 03:57:56PM +0100, Ralph Corderoy wrote:
> Hi Mike,
>
> > I know the current code uses diff -Dname option which is not
> > universal.
>
> As an aside, I see POSIX has diff support -e for ed(1) output. And -s
> for running a script. How about turning -e's output into ed that
> inserts the cpp(1) commands and carrying on as before? Have a poke at
>
> --8<--snip--
> #! /bin/bash
>
> seq 10 >foo
> seq 12 | sed '3,4d; 6s/./&&/; 7p' >bar
>
> diff -Dfoo foo bar
> echo
>
> cp foo foo.new
> diff -e foo bar |
> awk -F, '
> copy {
> if ($0 == ".") {
> if (closing)
> print closing
> copy = 0
> }
> print
> next
> }
>
> # 42a -> 42,a
> /[acd]$/ {
> $0 = substr($0, 1, length - 1) FS substr($0, length)
> }
> # 42,a -> 42,42,a
> NF == 2 {
> $0 = $1 FS $1 FS $2
> }
>
> {
> print "\t=" $0
> }
>
> # 42,a
> $NF == "a" {
> print $1 "a"
> print "#ifdef foo"
> closing = "#endif /* foo */"
> copy = 1
> next
> }
>
> # 42,314,c
> $NF == "c" {
> print $1 "i"
> print "#ifndef foo"
> print "."
> print ($2 + 1) "a" # Bumped on by insert.
> print "#else /* foo */"
> copy = 1
> closing = "#endif /* foo */"
> next
> }
>
> # 42,314,d
> $NF == "d" {
> print $2 "a"
> print "#endif /* ! foo */"
> print "."
> print $1 "i"
> print "#ifndef foo"
> print "."
> next
> }
>
> END {
> print "w\nq"
> }
> ' >foo.ed
> cat foo.ed
> echo
>
> sed -i '/^\t=/d' foo.ed
> ed -s foo.new
> diff <(diff -Dfoo foo bar) foo.new && echo ok
> --8<--snip--
>
> It's not had much testing as I've just knocked it up, but it shows the
> idea. And you might want to ditch the cpp commands and switch to
> something that's nicer to handle in the rest of the script. Or maybe do
> the .mk-up directly.
>
> Cheers, Ralph.
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] Heirloom TBL problem
On Sun, Jun 21, 2015 at 08:35:34PM -0500, Blake McBride wrote: > On Sat, Jun 20, 2015 at 3:52 PM, wrote: > > The interface to .ll is \nW or .PGFORM. At first my plan was to implement > > .PGFORM. But *maybe* using W like MS's LL could also make sense. But for > > compatibility with groff .PGFORM should be prefered. (?) > > Adding .PGFORM is fine, but I would prefer just having .ll work like it > does on groff. This way the original docs work and produce as expected. Asking for .ll to work like it does in groff is an oximoron. The commands documented in groff(7) are the assembly language of groff. They are the commands on which all extensions to groff are built. So when you use the MM or MS macros, you are using extension macros that are built on the groff commands. Likewise, programs like tbl(1), eqn(1), pic(1), etc. process the input and emit the input combined with more groff commands that groff then processes to create the desired outcomes. Most macro packages, and certainly MM and MS, have preferred ways of specifying line length that ultimately emit .ll commands to implement the desired results. Using the groff commands within other macro packages often produces confusing and unexpected results. So the recommended practice is to stick strictly to the "higher-level" macros of the macro package, or packages, you are using. Mixing the package macros with groff macros is discouraged, except to those who imagine themselves to be experts in groff _and_ the macro packages. I am one such person, and have many sad tails to tell of my ignorance. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Heirloom TBL problem
On Mon, Jun 22, 2015 at 09:02:16AM -0500, Blake McBride wrote: > I have been using troff on and off since 1983. I know all that. > > The macro packages act as a higher level API but almost never completely > duplicates all of the lower level commands. Surely you don't want to > conflict with a macro package that assumes it has control over a certain > parameter, but likewise one must use the lower level API when attempting to > do something the macro package had no need to encapsulate. > > A. MM has no clear way to set ll I disagree. >From groff_mm(7) ... : PGFORM [linelength [pagelength [pageoffset [1 Set line length, page length, and/or page offset. This macro can be used for special formatting, like letter heads and other. It is normally the first command in a file, though it is not necessary. PGFORM can be used without arguments to reset every‐ thing after a MOVE call. A line break is done unless the fourth argument is given. This can be used to avoid the page number on the first page while setting new width and length. (It seems as if this macro sometimes doesn't work too well. Use the command line arguments to change line length, page length, and page off‐ set instead.) : W Line length, only for command line settings. > B. Tbl clearly understands ll with MM in groff, and it makes sense. Yes, tbl(1) does understand .ll , but within any macro package, such as MM, .ll will be set and manipulated by the macro package. Consider MM's .2C two-column macro. If there is something to be fixed in MM, it would involve making the warning within the .PGFORM dcoumentation unnecessary. -- Mike Bianchi
Re: [Groff] MIssion statement
On Wed, Jul 08, 2015 at 12:14:10PM -0700, Chad Roseburg wrote: > It looks scrambled in Chrome's PDF viewer but looks fine if you download it > and view it with Adobe Reader, Evince ...etc. I have reading found PDFs are sometimes problematic in Linux. They are not the "just works" documents they once were. Occasionally I use the hack of extracting the PostScript with pdf2ps(1) and then use ps2pdf12(1) to turn it back into PDF. I've no idea why it works; it is just a lazy get-around. -- Mike Bianchi
Re: [Groff] Trouble switching to groff, macro gives syntax error...
On Tue, Sep 15, 2015 at 12:38:56AM -0700, Marisa Giancarla wrote: > Im trying to convert my plain text documents to groff with -mm macro > so that i can generate plain text and pdf formats automaticly. When > processing it i get a syntax error. I can't post the details here > since the formatting is critical to the issue. Here is a link to the > details: > https://www.evernote.com/shard/s81/sh/d9932e53-3e62-4754-9f56-01ccb74ea4f3/d5176d965d72b7d77f67fac5afd13cd2 > > Here is the command I'm using: > > groff -p -t -mm -Tascii conimp.mm > > and i am trying to use the ".1C" macro. > > Any ideas? > > Marisa Try changing .1C to .DS and add the line .DE at the bottom. Does that get closer to what you want? -- Mike Bianchi
Re: [Groff] Groff - weird error with line spacing
On Thu, Oct 08, 2015 at 10:30:29AM +0100, Ralph Corderoy wrote: > Hi Hog, > > > When piping to gv: > > groff -mm oops|gv - > > The second page throws PostScript errors, the primary being "undefined in > > BP". > > > > Trying with output to a file: > > groff -mm oops>oops.ps > > Produces a properly formatted second page. I have not found any evidence that gv(1) is documented as taking '-' as an alias for the standard input. Interestingly gv /dev/stdin < manual.ps works. But ... cat manual.ps | gv /dev/stdin gv: Cannot open file /dev/stdin (No data available) cat manual.ps | ( sleep 1; gv /dev/stdin ) gv: Cannot open file /dev/stdin (No data available) I suspect a funny race condition involving pipes. All my shell code using gv employ files named /tmp/$$_something when I might have used a pipe. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Problem with MM spacing with macro immediately after a heading (H)
Damian, I find that \# works well outside of tables. .\# works well inside tables _AFTER_ the initial specification. >From man 7 groff ... \# Everything up to and including the next newline is ignored. This is interpreted in copy mode. This is like \" except that the terminating newline is ignored as well. Witness ... .H 1 "Here Is An Example" \# Adding text here avoids the problem, but this is not always feasible. .DS 0 This should be only one line under the heading. This is not so unless you uncomment the '.rm' above. .DE What is the real fix please? .TS center; r r l l. .\# Table comment right right leftleft .TE \# Finish of example Mike On Wed, Dec 23, 2015 at 07:03:41PM +1100, Damian McGuckin wrote: > > Around August 2014, there was a discussion started by Blake McBride > > Problem with MM spacing > > I looks like Werner fixed something but I cannot exactly figure out what > it was from that discussion. > > The problem I have could be related but it is subtly different. > > Let me know if I should really append to that thread. > > I am using the latest 1.22.3. I did not have this problem previously when > I was using a much older version of groff, the one which comes with RedHat > 6, or CentOS 6. But it is the first time I am using this new version with > some old files. > > If I have something like > > .H 2 "A Heading" > Some words of wisdom and ramblings ... > > everything just rocks. > > However, if I have > > .H 2 "A Heading" > .TS > .\" some table of something > . > .TE > or > .H 2 "Another Heading" > .DS 0 > .\" some display which needs to be done literally > . > .DE > > then the spacing gets messed up. Mind you, typing > > .rm misc@tag > > at the start of the document fixes it quick smart, but that is not a real > fix. And heaven only knows what that really does to other things. > > While I think a table or a display without some leading explanatory text > is pretty poor style, and something I normally avoid, I use this document > structure for staff CVs. > > This simple example highlights the problem. Any hints as to a fix is > welcome. > > .\" Start of Example > .S 12 14 > .\" .rm misc@tag > .ds HF 3 3 3 2 2 2 2 > .ds HP 12 12 12 12 12 12 12 > .H 1 "Here Is An Example" > .\" Adding text here avoids the problem, but this is not always feasible. > .DS 0 > This should be only one line under the heading. > This is not so unless you uncomment the '.rm' above. > .DE > What is the real fix please? > .\" Finish of example > > Regards - Damian > > Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 > Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here > Views & opinions here are mine and not those of any past or present employer > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Problem with MM spacing with macro immediately after a heading (H)
On Wed, Dec 23, 2015 at 04:44:40PM +0100, Carsten Kunze wrote: > Hello Mike, > > what do you mean here--Damian didn't use \#? > > Carsten His example was > .H 2 "A Heading" > .TS > .\" some table of something > . > .TE > or > .H 2 "Another Heading" > .DS 0 > .\" some display which needs to be done literally > . > .DE -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] *roff for desktop publishing - is it feasible?
On Wed, Oct 26, 2016 at 12:37:07PM +1100, Damian McGuckin wrote: > > Some trade journals which are funded by their advertising, often suffer, > or loose relevance because all the effort goes into creating the flashy > advertisements done by these graphic artists. far less work goes into the > content/arrangment/quality/readability/grammar of the articles and they > loose their readership. For a counter-example, one that the prizes readability over eye-candy, see The Economist magazine. There _is_ eye-candy in the ads, but they do not interfere with the readability nor the content. So I have used [ntg]roff all these years because I can concentrate on the content. The presentation (once I've picked and implemented a style) takes care of itself. I even use an nroff filter I wrote in the 1980s on my outgoing e-mail for exactly that reason. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Applying commands to all pages
On Thu, Nov 10, 2016 at 04:35:34PM +0100, Steffen Nurpmeso wrote: > ... Search > the internet for cstr#54-troff-revised.pdf -- some members of this > list have revised the original, and i think for the better. I cannot find anything searching for cstr#54-troff-revised.pdf or troff-revised.pdf Are you referring to the 1992 version by Brian Kernighan? THAT I can find. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] mom and toggling pagination
On Wed, Dec 07, 2016 at 12:10:37PM +0100, Tadziu Hoffmann wrote: > : > It's true for *roff in general. In classic [nt]roff a blank > input line would always produce a blank line in the output. > Usually, this is not really what you want. If (like in TeX) > you want blank lines in the input to stand for paragraph > breaks, you might only want half a vertical line-space in > the output as paragraph separation. Or maybe none at all, > and have paragraphs be indented instead. > : Long ago I developed the habit of putting lines consisting of only a . wherever I wanted some white-space to help my understanding of the document . \# for example content as opposed to the formated document appearance. . It sometimes makes editing the groff input much easier. Long ago I developed the habit of putting lines consisting of only a . wherever I wanted some white-space to help my understanding of the document content as opposed to the formated document appearance. It sometimes makes editing the groff input much easier. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Trying to use tabs and tab stops in groff
I cannot see what you are doing wrong (why the \t is not seen as a tab) but if you change all your \t to actual tab characters you get: Name Birthday Telephone John Smith1/1/70 (410) 555‐ Dave Jones2/2/63 (311) 800‐ Bob Williams‐‐3/3/56‐(999) 555‐ Mike On Wed, Apr 05, 2017 at 10:18:34AM -0400, T. Kurt Bond wrote: > Hello, > > I'm trying to use tabs and tab stops in groff to so some simple tables, and > can't figure out why it is not working. Here's the input: > > .\" groff -mm tabs.mm | ps2pdf - tabs.pdf > .P > A sentence to start the example. > .\" http://cmd.inp.nsk.su/old/cmd2/manuals/unix/UNIX_Unleashed/ch08.htm > .\" output should look something like: > .\" > http://cmd.inp.nsk.su/old/cmd2/manuals/unix/UNIX_Unleashed/art/08/08unx25.gif > .nf > .ta 3i 4.5i > Name\tBirthday\tTelephone > > John Smith\t1/1/70\t(410) 555- > Dave Jones\t2/2/63\t(311) 800- > .tc - > Bob Williams\t3/3/56\t(999) 555- > .fi > .P > A sentence to end the example. > > > I get a result with everything smashed together, as if the "\t"s weren't > there at all. > > Any idea what I'm doing wrong? > > -- > T. Kurt Bond, tkurtb...@gmail.com -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] ASCII Minus Sign in man Pages
Folk, I've been sort of watching from the sidelines here, but am going to toss in my 2 cents. First, I once heard troff/groff described as the assembly language of type setting. So to my mind it should be "simple" (as in not too complicated) and stable. The first goal is forever lost. Stable, to me, implies not changing much over time, and most changes should be backward compatible. troff/groff has by and large met that test. Having mastered troff at one time the stability has saved me. But my mastery has degraded as I have not kept up with all the improvements and never was a grand master. Backward compatible means that all code written to the existing definitions should turn out the same results as in the past when submitted to new assemblers. (I have nroff documents and C code from the 1970s that still work.) Thus when we have pieces of documented definitions that contradict each other the problem becomes which definition to change. The definitions for - \- \(mi \(hy \(em \(en (others?) should be clear and the implementations should implement them as defined. To my mind - in groff should always default to the ASCII, 7-bit, undistinguished character. When we have assemblers that contradict because of the documentation being inconsistent, what do we do about that? For me, I want the assembler I use, groff, to match the corrected documentation. If different assemblers knowingly disagree with each other it would be a courtesy to the community to document that fact. (Witness the documentation for many of the Linux/Unix/BSD implementations of "the shell".) So if the current definitions for - \- \(hy disagree with historical documents and implementations, they should be documented. If I am writing at the assembly level, I can always .char - \- Given those opinions, I feel it is for the macro packages, the "compilers", to implement the necessary features such as associating true minus-signs with numbers and true hyphens with word separators. And if -x is meant to be keyboard (7-bit ASCII) characters, the compiler should make that so. The unfortunate history is that the man pages and other ancient documents come from a time when the users of macros where expected to dive into the assembly language _frequently_ to get-around the things that the macros just did not address. And that history is still with us in WYSIWYG (What You See Is What You Get) word processors. Want that - to be a minus in WYSIWYG? Dive into the font table and pick out the character there, if you can find it. My impression is that some macros, such as Schaffter's Mom, go a long way towards eliminating the assembly get-arounds. Still macros take a programmers view of documentation, namely to compile our document source code rather than format the WYSIWYG input. Their advantage is that simple "commands" crank out a lot of assembler code. Calling something a TITLE implies a lot of specifics. All that said, the concept of having the complier decide whether a character should be a minus, hyphen, minus-hyphen, UTF8-something-or-other, etc. should be in the realm of a higher level component than troff/groff. And the fix for old documents, such as the man pages that depend on groff for their appearance, is to edit their source code so their specifics match the (corrected?) groff definitions. Mike On Tue, May 02, 2017 at 09:29:39PM -0400, Doug McIlroy wrote: > > Branden wrote > > Ingo's proposal would not mandate that + and \- come from the special > font. > > It also would not mandate that \(pl and \(mi come from the current font. > > > -- > > I was previously told that \(mi is the true minus sign. But the > true minus sign, at least in my mind, must come from the current > font, so that it comes out right wherever it occurs, even in a > bold headline like "Fairbanks shivers at -50". > > > I'll buy Branden's first assertion, but if + and \- come from the > current font as they originally did, and \(pl and \(mi come > from the the current font per the previous paragraph, they > become redundant. > > So I remain confused. > > Doug -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] ASCII Minus Sign in man Pages
On Wed, May 03, 2017 at 03:51:24PM +0100, Ralph Corderoy wrote: > : > : > - A hyphen for text, e.g. beer-flavoured ice-cream. > : > > To my mind - in groff should always default to the ASCII, 7-bit, > > undistinguished character. > > But it's always meant hyphen in pre-groff troff because it's a lot more > common to want a hyphen in writing than a minus sign. _I_ would claim this interpretation was a mistake. ((My opinion only here.)) The - character exists on all keyboards. It is not labeled minus or hyphen or endash. It generates the decimal 45 (hex 0x2D, octal 055) character. That any *roff processor would give it a different meaning is most unfortunate. Especially because hyphenation is a built in feature of *roff and once there was the concept of \(hy , hyphenated words should have used it. Note please that I am not saying that - should be interpreted as \(mi either. > : > \- A minus sign in the current font. > \(miA minus sign in the special font. I would claim that \- makes sense, but \(mi coming from the special font is a hold-over from the _first_ troff at Bell Labs that was tailored to the first support photo typesetter that supported 4 102-character fonts. They were Roman, Bold, Italic, and Special (R B I S). Special was the Greek alphabet and other needed characters. Us old-timers fondly remember the Bell System bell. See https://en.wikipedia.org/wiki/Troff "CAT phototypesetter" https://en.wikipedia.org/wiki/CAT_%28phototypesetter%29 ((And interestingly, the current S (Symbol) font also contains the numbers, presumably so the they and the arithmetic and logic operators could all look alike in mathematical writing. I'm guessing that *roff does not take the digits from the Symbol font by default. I think that as an effective argument for not making \(mi draw from the S font by default.)) > \- A minus sign in the current font. > \(miA minus sign in the special font. > \(hyAnother name for plain `-', so a hyphen for text. > \N'45' Glyph 45 in the current font. Once fonts distinguished between minus and hyphen with distinctive glyphs then \(mi and \(hy have should come from the current font, especially if neither is \N'45' . BUT that is MY opinion. What I am pushing for is that all the groff documentation speak truth on this matter. > ... paste from a man page, viewed as UTF-8 > TTY, PostScript, PDF, browser, ..., it needs to be character 45. > Writing «wc \N'45'l» isn't going to gain support. :-) > How to produce it is the issue. Absolutely. I propose wc -l if - was \N'45' It would make sense for future generations. As a first generation UNIX citizen it is interesting to contemplate how much longer the man pages groff documents will be relevant. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] ASCII Minus Sign in man Pages
On Thu, May 04, 2017 at 11:30:20AM +0100, Ralph Corderoy wrote: > > > But - has always meant hyphen in pre-groff troff because it's a lot > > > more common to want a hyphen in writing than a minus sign. > > > > _I_ would claim this interpretation was a mistake. > > Well, 7th Ed. documents that have `.if n' and `.if t' use - for an > English hyphen and \- for a numeric minus, e.g. > : Just to be clear, I am _not_ saying that wasn't how it was documented and implemented. I am just saying that it has made the world more complicated than _I_ would like. Typing \(hy for hyphen would have been a heavy burden, especially in the absence of the .char groff extension. Probably the best solution available now is fixing any incorrect documentation so as to speak truth. -- Mike Bianchi
Re: [Groff] mom : unicode in .INCLUDE'd files
On Sat, Jul 22, 2017 at 05:00:37PM +0200, E. Hoffmann wrote: > Am Fri, 21 Jul 2017 16:28:04 -0400 > schrieb Peter Schaffter : > > [...] > > > $ soelim foo | preconv | groff -Tutf8 | grep . Is there a reason the preferred solution isn't $ groff -k -s -Tutf8 foo ? see man 1 groff : -k Preprocess with preconv . ... -s Preprocess with soelim . That way groff knows the crucial ordering, etc. -- Mike Bianchi
Re: [Groff] mom : unicode in .INCLUDE'd files
Woops. Never mind. Mike On Sat, Jul 22, 2017 at 12:08:29PM -0400, Mike Bianchi wrote: > On Sat, Jul 22, 2017 at 05:00:37PM +0200, E. Hoffmann wrote: > > Am Fri, 21 Jul 2017 16:28:04 -0400 > > schrieb Peter Schaffter : > > > > [...] > > > > $ soelim foo | preconv | groff -Tutf8 | grep . > > > Is there a reason the preferred solution isn't > $ groff -k -s -Tutf8 foo > ? > > see man 1 groff : > -k Preprocess with preconv . ... > -s Preprocess with soelim . > > > That way groff knows the crucial ordering, etc. > > -- > Mike Bianchi
Re: [Groff] mom : unicode in .INCLUDE'd files
On Sat, Jul 22, 2017 at 06:19:29PM +0100, Keith Marshall wrote: > On 22/07/17 15:06, John Gardner wrote: > > ... Can I semi-seriously implore the world to only use UTF-8, and > > pretend other encodings don't exist? > > Not really going to happen, for as long as MS-Windows remains the > dominant OS for personal computer platforms. I have documents, nroff, troff and others (plus sh/ksh/awk/sed/... scripts), dating back to the mid-1970s. Many of those *roff documents still format correctly. The thing I _like_ about the *nix OSs is they don't demand I upconvert just because a "better way" comes along. Remember when the "modern" way to archive was to put everything onto microfiche? -- Mike Bianchi
Re: [Groff] mom : unicode in .INCLUDE'd files
This library purports to be a way to approach the problem ...
https://www.autoitconsulting.com/site/development/utf-8-utf-16-text-encoding-detection-library/
UTF-8 and UTF-16 Text Encoding Detection Library
by Jonathan Bennett | Aug 23, 2014 | Development |
This post shows how to detect UTF-8 and UTF-16 text and presents a fully
functional C++ and C# library that can be used to help with the detection.
I recently had to upgrade the text file handling feature of AutoIt to better
handle text files where no byte order mark (BOM) was present. The older
version of code I was using worked fine for UTF-8 files (with or without BOM)
but it wasn't able to detect UTF-16 files without a BOM. I tried to the the
IsTextUnicode Win32 API function but this seemed extremely unreliable and
wouldn't detect UTF-16 Big-Endian text in my tests.
Note, especially for UTF-16 detection, there is always an element of ambiguity.
This post by Raymond shows that however you try and detect encoding there will
always be some sequence of bytes that will make your guesses look stupid.
Here are the detection methods I'm currently using for the various types of
text file. The order of the checks I perform are:
BOM
UTF-8
UTF-16 (newline)
UTF-16 (null distribution)
:
:
--
Mike Bianchi
Re: [Groff] parallel text processing ; vertical and horizontal mode
On Thu, Sep 07, 2017 at 09:45:47AM +0100, Ralph Corderoy wrote: > Hi Erich, > > > Of course it would be a hypertrophy changeing the distances each and > > every page...no, the idea is to have two parts of text on each page. I don't have the groff chops to address this in general, but I will point at the .2C .1C .NCOL macros within the mm macro set; groff_mm(1) /usr/share/groff/1.22.2/tmac/m.tmac This hand-made test does most of the work automatically. See the comments. = = = = = = = = = = mm_2C_test \# ragged right formatting .na . \# start 2 column format .2C . sladfklkj sd sdfjk ljksdfa jklsdfa jklsdfa lsdf l ljksdfa lkjsdfa lkjsdf lk .sp sladfklkj sd sdfjk ljksdfa jklsdfa jklsdfa lsdf l ljksdfa lkjsdfa lkjsdf lk . \# force formatting to the next column .NCOL . SLADFKLKJ SD SDFJK LJKSDFA JKLSDFA JKLSDFA LSDF L LJKSDFA LKJSDFA LKJSDF LK SLADFKLKJ SD SDFJK LJKSDFA JKLSDFA JKLSDFA LSDF L LJKSDFA LKJSDFA LKJSDF LK .sp SLADFKLKJ SD SDFJK LJKSDFA JKLSDFA JKLSDFA LSDF L LJKSDFA LKJSDFA LKJSDF LK .br . \# return to 1 column format 1 == no page break .1C 1 . \# determined by experimentation .sp 4 . \# line of # characters \l'\n[.l]u#\c .sp 1 . .sp . \# start 2 column format .2C . ouiqwe owerq oerw oiuerwqoi oiuerwqo iuerwq oo erwq oerwq owerq oerwq oiu ouiqwe owerq oerw oiuerwqoi oiuerwqo iuerwq oo erwq oerwq owerq oerwq oiu .sp ouiqwe owerq oerw oiuerwqoi oiuerwqo iuerwq oo erwq oerwq owerq oerwq oiu .br . \# force formatting to the next column .NCOL . IUERWQ OO ERWQ OERWQ OWERQ OERWQ OIU OUIQWE OWERQ OERW OIUERWQOI OIUERWQO .sp IUERWQ OO ERWQ OERWQ OWERQ OERWQ OIU OUIQWE OWERQ OERW OIUERWQOI OIUERWQO IUERWQ OO ERWQ OERWQ OWERQ OERWQ OIU OUIQWE OWERQ OERW OIUERWQOI OIUERWQO . \# determined by experimentation .br . \# return to 1 column format 1 == no page break .1C 1 . \# determined by experimentation .sp 1 . \# line of # characters \l'\n[.l]u#\c .sp . .sp 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 = = = = = = = = = = nroff -mm mm_2C_test ‐ 1 ‐ sladfklkj sd sdfjk ljksdfa SLADFKLKJ SD SDFJK LJKSDFA jklsdfa jklsdfa lsdf l JKLSDFA JKLSDFA LSDF L ljksdfa lkjsdfa lkjsdf lk LJKSDFA LKJSDFA LKJSDF LK SLADFKLKJ SD SDFJK LJKSDFA sladfklkj sd sdfjk ljksdfa JKLSDFA JKLSDFA LSDF L jklsdfa jklsdfa lsdf l LJKSDFA LKJSDFA LKJSDF LK ljksdfa lkjsdfa lkjsdf lk SLADFKLKJ SD SDFJK LJKSDFA JKLSDFA JKLSDFA LSDF L LJKSDFA LKJSDFA LKJSDF LK ouiqwe owerq oerw oiuerwqoi IUERWQ OO ERWQ OERWQ OWERQ oiuerwqo iuerwq oo erwq OERWQ OIU OUIQWE OWERQ OERW oerwq owerq oerwq oiu ouiqweOIUERWQOI OIUERWQO owerq oerw oiuerwqoi oiuerwqo iuerwq oo erwq IUERWQ OO ERWQ OERWQ OWERQ oerwq owerq oerwq oiu OERWQ OIU OUIQWE OWERQ OERW OIUERWQOI OIUERWQO IUERWQ OO ouiqwe owerq oerw oiuerwqoi ERWQ OERWQ OWERQ OERWQ OIU oiuerwqo iuerwq oo erwq OUIQWE OWERQ OERW OIUERWQOI oerwq owerq oerwq oiu OIUERWQO 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 1324 098438099438 0984 089431 09843 08943 089 09814 08943 098431 0894132 0 = = = = = = = = = = -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] pic.ps
On Wed, Sep 27, 2017 at 11:43:40AM -0400, Doug McIlroy wrote: > The Fedora system I have access to lacks /usr/share/doc/groff, and > in particular the wonderful tutorial /usr/share/doc/groff/pic.ps. On Debian 8 locate pic.ps returns /usr/share/doc/groff-base/pic.ps.gz -- Mike Bianchi
Re: [groff] * SL * Gpresent version 2.4 Released
The PAUSE sometimes does not work? The file demo.pdf in the package reads in part ... You can also use the PAUSE macro in a table. AT&T Common Stock Year Price Dividend x X ps: exec PAUSE 1984 15-20$1.20 x X ps: exec PAUSE 519-25 1.20 x X ps: exec PAUSE 621-28 1.20 x X ps: exec PAUSE 720-36 1.20 Mike On Thu, Nov 16, 2017 at 10:04:57AM +0100, Bob Diertens wrote: > Hi All, > > Long overdue but finally there. > > Gpresent v2.4 is available from > https://staff.fnwi.uva.nl/b.diertens/useful/gpresent/ > > DESCRIPTION > gpresent is a package for making presentations with groff and > acroread. It consist of a set of macros to be used with groff > and a post-processor for manipulating the PostScript output of > groff. Without the use of the PAUSE macro, it can also be used > for making slides. > > Enjoy, > Bob -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] Gpresent version 2.4 Released
Also, the piclink buttons in the lower left corner does not seem to work. Mike On Thu, Nov 16, 2017 at 10:04:57AM +0100, Bob Diertens wrote: > Gpresent v2.4 is available from > https://staff.fnwi.uva.nl/b.diertens/useful/gpresent/ -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] Problems redefining macro $c for -me macros
> I also find it funny if I ever need to talk about money in dollars: a > dollar sign ($) is obviously needed. Tried escaping the $ like `\$', but > that ..obviously.. didn't work. But it seemed ..so.. close, so I tried this: .char \[$] "$ Dollar \[$] The special character \[$] is defined as the string "$" . NOTE that the .char statement _requires_ that the trailing " not be present. Mike On Sun, Dec 03, 2017 at 08:50:04PM +0700, Stephanie Björk wrote: > That seems very reasonable an explanation. Thank you. :) > > I didn't know that the problem had something to do with EQN's inline > equation. It wasn't so obvious, but it makes sense nonetheless. > > I also find it funny if I ever need to talk about money in dollars: a > dollar sign ($) is obviously needed. Tried escaping the $ like `\$', but > that ..obviously.. didn't work. I guess the only way to use $ signs > properly is to use a different delimiter or tell EQN, ``delim off''. > > On Sun, Dec 3, 2017 at 8:08 PM, Ralph Corderoy > wrote: > > > Hi Stephanie, > > > > > using the eqn "delim" request with dollars seems to start an inline > > > equation for ".de $c"! > > > > Yes, Steffen's right. The `$' in `$c' is looking to the preprocessor > > eqn as part of the inline equation delimeters set beforehand with `delim > > $$'. Moving the `.de $c' definition to before the `.EQ' to `.EN' block > > would seem the simplest solution. > > > > -- > > Cheers, Ralph. > > https://plus.google.com/+RalphCorderoy > > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] How does one recreate the \(bs symbol?
> .char \(bs \X'ps: import ATandTlogo.ps 9 4 109 104 1'\h'1m' > .\" > .sp 3c > This is the AT&T death star: \(bs. Back in the day (read "the 1970s") \(bs was the "Bell System" logo. It was a glyph in the Symbol font. And it looked like: https://upload.wikimedia.org/wikipedia/commons/e/ed/Bell_System_hires_1969_logo_blue.svg Is there a way to turn that into a glyph in a groff font? Mike On Wed, Jan 10, 2018 at 01:01:27AM +0100, Tadziu Hoffmann wrote: > > > Sorry if the context is out of the ordinary, but I would > > like to have some specifications of the \(bs symbol, which > > does not seem to exist on Groff. I am quite certain that > > it can be recreated using Troff's drawing primitives, but > > I can't seem to get it quite right. Perhaps someone has > > the exact or an almost exact specification saved somewhere? > > If you're okay with Postscript, then I'd suggest embedding > this as an external graphic, instead of trying do draw it > with groff primitives. See the attached files as an example. > I copied the drawing instructions for the logo verbatim from > the Troff User's Manual (the Plan 9 edition, I think, since > it's set in Lucida Sans), so I guess it's somewhat of an > "official" rendering, although the coordinates are probably > munged a bit as a result of embedding in the PDF. > > > .\" > .\" > .char \(bs \X'ps: import ATandTlogo.ps 9 4 109 104 1'\h'1m' > .\" > .sp 3c > This is the AT&T death star: \(bs. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] How does one recreate the \(bs symbol?
On Wed, Jan 10, 2018 at 10:44:10PM +, Keith Marshall wrote: > On 10/01/18 22:02, Stephanie Björk wrote: > > Huh? Why does it look so different? The many variations on the theme of Bell System logo can be found at https://www.google.com/search?tbm=isch&q=bell+system+logo&chips=q:bell+system+logo,g_3:vintage -- Mike Bianchi
[groff] Macros in their own package ...
I'll vote for having the macros in their own packages. The possibility of having macro packages which were compatible with more than one *roff is appealing. Having the Z macro set where the differences between the Aroff and Broff versions were clearly documented would be useful. To have a Z macro package containing both Z_Aroff.tmac and Z_Broff.tmac is something to be hope for. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] Macros in their own package ...
On Wed, Mar 21, 2018 at 03:55:32PM +0100, Pierre-Jean wrote: > : > As far as I know, Neatroff is not based on any other troff. It has > been written from scratch. Neatroff can be found at http://litcave.rudi.ir/ https://litcave.rudi.ir/neatroff.pdf Neatroff Ali Gholami Rudi Updated in March 2018 Neatroff is a new implementation of Troff typesetting system in C programming language, which tries to address, as neatly as possible, some of the shortcomings of the original Troff based on the ideas and features available in Plan 9 Troff, Heirloom Troff, and Groff. He has an ambitious hobby :) -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] groff as the basis for comprehensive documentation?
On Wed, Apr 25, 2018 at 03:58:33PM -0400, Steve Izma wrote: > When I write, I only want to think about the words ... > and the structure of my argument ... May I add a big Amen! -- Mike Bianchi
[groff] Brian Kernighan on the evoution of eqn, pic, grap, into troff
True confession: Brian Kernighan is my hero. (stories upon request) In this talk, starting at about 41:45, he talks about the history of creating the eqn, pic, grap "little languages". I offer it for those who might want a sense of how groff wound up where it is and why it survives. Interestingly, Brian repeatedly says "troff's time has past". For some of us, the response is "not for me". Computer Science - Brian Kernighan on successful language design https://www.youtube.com/watch?v=Sg4U4r_AgJU "How to succeed in language design without really trying." -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] placement of const is _not_ a matter of style ...
The placement of const is _not_ a matter of style! >> For example, >> in C code, it is very common to see: >> >> const char *foo; >> >> which means something very different from: >> >> char const *foo; > > Actually, it doesn't. Try it. Actually it does. AND char *foo const; Also means something! See https://stackoverflow.com/questions/890535/what-is-the-difference-between-char-const-and-const-char To my mind this confusion points to a weakness of C and C++. It would be much less of an issue if I could ask a compiler. What is the type of foo ? to be certain excacty what I was dealing with when referencing foo . ((Or is there something out there I am not aware of?)) ((Where is Dennis Ritchie when you need him? RIP)) GCC has a typeof keyword, but that _duplicates_ a type. http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Typeof.html -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] placement of const is _not_ a matter of style ...
On Sat, May 05, 2018 at 05:27:39PM +0100, Ralph Corderoy wrote:
> > >> const char *foo;
> > >> char const *foo;
>
> No, those two have identical meaning.
Not according to:
https://en.wikipedia.org/wiki/Const_(computer_programming)
This is a rather through discussion of the topic.
Well worth the read.
These examples are found there.
(( reformatted for emphasis ))
void Foo( int * ptr,
int const * ptrToConst,
int * const constPtr,
int const * const constPtrToConst )
{
*ptr = 0;// OK: modifies the "pointee" data
ptr = NULL; // OK: modifies the pointer
*ptrToConst = 0;// Error! Cannot modify the "pointee" data
ptrToConst = NULL; // OK: modifies the pointer
*constPtr = 0;// OK: modifies the "pointee" data
constPtr = NULL; // Error! Cannot modify the pointer
*constPtrToConst = 0;// Error! Cannot modify the "pointee" data
constPtrToConst = NULL; // Error! Cannot modify the pointer
}
int *ptr; // *ptr is an int value
int const *ptrToConst; // *ptrToConst is a constant (int: integer value)
int * const constPtr; // constPtr is a constant (int *: integer pointer)
int const * const constPtrToConst;
// constPtrToConst is a constant (pointer)
// as is *constPtrToConst (value)
const int *ptrToConst; //identical to: int const *ptrToConst,
const int *const constPtrToConst;
//identical to: int const *const constPtrToConst
Please note that I am not trying to pick a fight here.
A thorough understanding of any programming language, such as C and C++,
is essential to writing code that needs to live through the ages and
be passed along through many hands.
In my experience it is confusions such as these that lead to long-standing
if hard-to-experience bugs.
Seeing the placement of the const keyword as an element of "style" is exactly
the sort of thing that makes me say "I can make this look better" when
in fact I am making it mean something different.
Not fun.
Believe me.
I speak from experience.
An open question is:
Is there a path by which the confusions such as these can be
avoided in the design and implementation of C-like language?
--
Mike Bianchi
[groff] Forwarded: Re: placement of const is _not_ a matter of style ...
I wrote: > > >> const char *foo; > > >> char const *foo; > > No, those two have identical meaning. Not according to: https://en.wikipedia.org/wiki/Const_(computer_programming) : : I was wrong. Those two lines _are_ identical. The example code I lifted even illustrated that. const int *ptrToConst; //identical to: int const *ptrToConst, My apologies to [groff]. ((more to come)) -- Mike Bianchi
Re: [groff] hyphen, minus sign and hyphen-minus
On Mon, May 28, 2018 at 03:24:05PM +0200, Pali Rohár wrote: > On Monday 28 May 2018 15:16:53 Pali Rohár wrote: > > On Monday 28 May 2018 02:48:09 Ingo Schwarze wrote: > > > Pali Rohar wrote on Sun, May 27, 2018 at 11:52:44PM +0200: > > > : > > > PS name TR# Unicode > > > --- --- --- > > > asciicircum 0x00 U+005E > > > asciitilde 0x01 U+007E > > > Scaron 0x02 U+0053 U+030C > > > : > : > Here is simple fix results to have hyphen-minus (U+002D) for command > line switches in postscript output via man -Tps: > > man -Tps groff | sed 's:/minus:/hyphen:g' > groff.ps >: Hummm ... How about a character named asciiminusU+002D ? -- Mike Bianchi
Re: [groff] Spooky action at a distance in line adjustment...sometimes
On Tue, Jun 26, 2018 at 03:09:57PM +0100, Ralph Corderoy wrote: > Hi Branden, > > > Can someone tells me why this happens? And, more mysteriously, why it > > only _sometimes_ happens? > > Two lines become three, disturbing parity. NOTE: font -> font_name > > - afmtodit [-ckmnsvx] [-a n] [-d desc_file] [-e enc_file] > > -[-f internal_name] [-i n] [-o out_file] afm_file map_file > > font > > + afmtodit [-ckmnsx] [-a angle] [-d desc_file] [-e encoding_file] > > +[-f internal_name] [-i n] [-o output_file] afm_file > > map_file > > +font_name > > : > : -- Mike Bianchi
Re: [groff] Groff & tbl as a report generator
Blake McBride wrote:
> :
> Then, a few years ago, I thought of generating groff/tbl input
> instead and then calling those tools to generate the final PDF output.
On Wed, Jul 25, 2018 at 09:47:49AM +1000, Robert Thorsby wrote:
> :
> Using shell scripts heavily reliant on awk which are then piped through
> groff ...
Since the dawn of troff, the idea of _computing_ good-looking documents has
been a major strength. The tbl/pic/eqn/... style of tools amplified the
utility of such. Those of us who see the words/data of a document as more
important than the appearance quickly realized the value of separating the
those two concerns.
The prevalence of What-You-See-Is-What-You-Get documentation ("... Is All You
Get": Brian Kernighan) has hidden the possibilities from the popular mind.
It is good to see the idea of computing documents being rediscovered.
--
Mike Bianchi
Re: [groff] How to show all hyphenation points?
> > [...] with the help of a few diversions and traps, as in the > > attached example macros. It's somewhat hackish and perhaps not the > > most compact code possible, but at least it's reasonably easy to > > understand and to modify. Maybe there should be a macro package and/or document that collects tricks and techniques such as this one that would be part of the groff package? www.gnu.org/software/groff/#documentation does not list much in the way of documentation www.gnu.org/software/groff/manual/html_node/ could add a "Tricks and Techniques" section that would collect gems such as this one. or maybe add this trick to www.gnu.org/software/groff/manual/html_node/Manipulating-Hyphenation.html It, and many like it, deserve a better fate than "lost in folk-lore". -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] Release Candidate 1.22.4.rc3
On Thu, Nov 29, 2018 at 12:15:35PM +, Deri wrote: > : > You can get a preview of what I have done by downloading the groff book here:- > http://chuzzlewit.co.uk/groff_book.pdf Wow! Just a quick glance and I learned about \n[.F] ! Never knew that. ((Also never saw a number register with string content.)) page 113 \n[.F] This string-valued register returns the current input file name. What a resource! Thank you. Suggestion. You use the word "currently" to mean the "this release", as in: 5.1.7. Input Encodings Currently, the following input encodings are available. According to the first page, here "currently" means Edition 1.22.4 Autumn 2018 It would be more helpful if "Currently" was replaced with or had a footnote reference to "Edition 1.22.4". That way this could become a living document! A perpetual current resource! -- Mike Bianchi
Re: [groff] mom manpage
> ... scrapping the alphabetic listing of macros and strings entirely. All it > does is partially duplicate the mom Quick Reference Guide (macrolist.html) > : IMHO One complete, up-to-date, easily-acquired reference is preferable to duplicates. The exception is when the duplicated information is from a single source so all duplicates always contain the same information. Long ago I was part of a team that built both the documentation and the code from a single source file so both always spoke a single truth. The one improvement on _that_ idea was another development group which managed to close the loop. There were two documents (alphabetical and by-concept written in nroff with comments) plus two forms of code (PL/I and IMS database declaration, with comments) that were interlocked by UNIX shell scripts. If you needed to make a change or addition, you could do it in _any_ one of the 4 forms and then generate the other 3. They were laughed at for being obsessive but never had that form of consistency bug in the long-lived project. ((Bless you Leon Levy, where ever you are.)) On Thu, Nov 29, 2018 at 09:57:27PM -0500, Peter Schaffter wrote: > I revisited groff_mom(7) recently. I didn't write it and I've > always felt it was there for the sake of completeness. I'd > like to revise it, scrapping the alphabetic listing of macros and > strings entirely. All it does is partially duplicate the mom Quick > Reference Guide (macrolist.html) and arranges it by alphabet, which > isn't an improvement. > > If getting rid of the section entirely is too radical, > macrolist.html could be converted to man markup and inserted in its > place, although I can't see how it would be useful. Mom macros > really need the documentation that's in the html/pdf docs. It's > enough for the manpage to give the entry points, IMO. > > Since groff_mom(7) isn't actually my baby, I'm asking for opinions > before I go ahead. > > -- > Peter Schaffter > http://www.schaffter.ca -- Mike Bianchi
[groff] Design and Implementation of *roff
I asked Brian Kernighan if he had recollections and/or documents from the early
days of nroff.
Hi, Mike --
All of the roff programs originate from Jerry Saltzer's Runoff, done for
CTSS. [nt]roff was unusual in having programmable layout (the trap
mechanism). I don't recall any place where this was all written down
in an orderly fashion, though it's interesting and maybe some enthusiast
could take it on. Maybe Doug McIlroy remembers -- he did a roff-like
program, as did I, and several others.
Brian
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [groff] mom manpage
> On Wed, Dec 05, 2018 at 03:29:36PM +0100, Tadziu Hoffmann wrote: > : > The manpage is a reference, not a tutorial. > : Which suggests a solution. Whenever possible include a TUTORIALS section with pointers to such. Which suggests another solution. Establish man(8) as the section for TUTORIALS. Which suggests another solution. Have linux/unix/bsd courses create "homeworK" such as: Write a tutorial on basic and advanced uses for the cp , mv and ln commands. Teamwork is encouraged. Finding an existing one on the internet is acceptable, especially if you can get the author's permission to submit it to the man pages collection as a man(8) entry. If one already exists, see if you can find improvements. Extra credit. The same for rm . Extra-extra credit. The same for ed . -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] ... the point of ascii ...
>: > The point of -T ascii is to get intelligible output on stunted devices, ... In my opinion the point of -T ascii is to preserve the behaviour of groff -T ascii from back then until forever. The proposed changes do not correct bugs. (We are not talking core dumps here.) They propose to changes to match personal preferences. I carry with me 40 years of nroff/troff/groff shell scripts that serve me well. Most have not had to change during that time because the UNIX/Linux/BSD communities (by and large) to not make "improvements" to achieve a sense of style. So if someone wants to have a new -T txt mode with a style that looks good when confined to one of the typewriter fonts, please have at it. In fact build a generalize tool where the choice of font can implies a set of desirable (to me) character substitutions and renderings that can easily be changed via a personalized configuration file. Say .groff-Ttxt.rc . Just don't go changing the definition of existing groff options such that what was rendered yesterday is different to what rendered today. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] modernize -T ascii rendering of opening single quote
> ... that doesn't look like a consensus yet, and unfortunately, > i don't see how to argue further, ... > : > Any ideas how to resolve this clash of priorities? Rephrasing what I said before: ... build a generalize tool where the choice of font or device implies a set of desirable (to me) character substitutions and renderings that can easily be changed via a personalized configuration file. Say .grofftool-txt.rc where txt is a font name or dev (or both?). Some history here ... The issue of how a specific a ASCII code is rendered goes back to >before< troff. In the 1970s (my youth) there were so-called "daisy wheel" printers/typewriters/terminals where the font was implemented via an easily substitutable part. en.wikipedia.org/wiki/Daisy_wheel_printing The IBM Selectric "ball" (88 glyphs) served the same purpose. en.wikipedia.org/wiki/IBM_Selectric_typewriter They were quite popular in the days of nroff. So the question of how the single and double quotes would be printed was answered by the specific typing element in the machine at the time of printing. Programmers had their favorites; document writers theirs. -- Mike Bianchi
[groff] modernize -T ascii rendering of opening single quote
> "Stamp out US-specific, internationally non-portable usage of ASCII > that is incompatible with Unicode, ..." > Is that something we can agree on? I don't agree because it cannot be done. Documentation, still valuable today, was written with "US-specific, internationally non-portable usage of ASCII" and must be understood in that context. It is the very nature of history. Otherwise we burn the books and rewrite them "as they should have been written if we knew then what we know today". Again I make the case for producing a way to tie the specific font and character-code-to-glyph-graphic map to a document so it can be reproduced as the author intended. Said another way "modernise" groff to add that capability and make UTF-8 the modern character-code-to-glyph-graphic map. (Is anyone working on a UTF-8 keyboard? We have the technology. www.nkkswitches.com/nkk-smartswitch-lcd-36-x-24-pushbutton-display-enhanced-accommodate-low-voltage/ Certainly an extension keypad of programmable glyph keys would be doable!) -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] [patch] modernize -T ascii rendering of opening single quote
On Thu, Feb 21, 2019 at 10:01:07AM +, Jeff Conrad wrote: > > We still have the question about what is (or was) a Genuine ASCII™ > device, I don't think "Genuine" is a question. There ain't no such thing. Just look at your various keyboards. I have keycaps (unshift ") with straight and angled glyphs. Once again, is anyone working on a UTF-8/Unicode keyboard? I see a need coming. -- Mike Bianchi
Re: [groff] anyone seen ".ny0" ?
> .ny0 look for a macro definition: .de ny : .. In the old days, no macro name was more than 2 characters so nroff/troff would understand .ny0 to be macro ny with argument 0 . Mike On Sun, Mar 24, 2019 at 07:16:07PM +0100, Walter Harms wrote: > Hello list, > while looking at the xorg man pages there came > a question what this .ny0 may mean (i shorted that of cause): > > > > .ny0 > .TH XtAppNextEvent __libmansuffix__ __xorgversion__ "XT FUNCTIONS" > .SH NAME > > . > > I could not find this in the groff manual. It seems to do nothing. > Any ideas ? > > re, > wh > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] A poor mans Excel
> If there is interest, I'll post the script and an example.
Yes please.
Mike
On Thu, Oct 10, 2019 at 01:21:31PM +0200, Ulrich Lauther wrote:
> Hi all,
>
> I have written a small perlscript, that preprocesses tables
> and allows to
>
> - add the values in selected collums
> - to replace a table entry by the result of an expression
>
> Lines between
> .(
> and
> .)
> are processed.
>
> The ".(" line may contain the numbers of collums in which addition
> is requested, e.g.:
> .( add 2 5 7
> or just
> .( 2 5 7
>
> ".(" ".)" blocks my be nested; sums calculated at a lower level are
> propagated up.
>
>
> Table entries of the form E. are repaced by the result
> of the expression rounded to n digits after the decimal point.
> "expression" is any valid perl expression.
> Variables used in the expression are
> - any valid perl variable (starting with "$")
> - $, the value in column n in the current line
> - $S, sum of values in the column (where $S is placed) seen so far
> If $S or E. is precedet by an "!", addition is suppressed for this
> table entry.
>
> As all tables of a document are processed by one perl-instance and perl
> variables can be created on the fly, values can be tranported from one
> table line to a later one or even to another table.
>
> Code size: 130 lines of perl
>
> Limitations: Multiline table enties are not supported.
>
> If there is interest, I'll post the script and an example.
>
> Kind regards,
>
> ulrich lauther
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Jean Louis wrote on Mon, Oct 28, 2019 at 11:12:51AM +0530:
> From: Ingo Schwarze > >> I'd like to know if it is possibile translate the entire groff manual > >> in italian obtaining some money for this kind of work. > > > It is good idea. You could hire somebody to translate it. > > Note that there is no consensus about this opinion. > For example, personally, i consider translating documentation > a waste of time if not outright harmful. I completely agree with Ingo; there is _no_ consensus. I'm glad someone took the time and effort to translate the UNIX and C-language documents into the many languages where they exist. As to groff, et. al., they are stable enough that any translations would remain useful, especially for those approaching them for the first time. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] Re: Space After A Heading with groff -mm
> When using the 'mm' macros, I try ... Look at groff_mm(7) , for the documentation of the .H macro. The .H macro is highly customizable. In particular, the Hs register says: Heading space level A blank line is inserted after the heading if the heading level is less or equal to number register Hs. Default value is 2. Text follows the heading on the same line if the level is greater than both Hb and Hs. Mike On Sun, Dec 22, 2019 at 05:03:11PM +1100, Damian McGuckin wrote: > > When using the 'mm' macros, I try > > .H 1 "A Heading" > .AL 1 > .LI > My List > > under 1.18.1.4, if gives me a single space between the space and the list. > > 1. A Heading > > My List > > This is the correct behaviour and has been since the days of DWB/MM. Some > of use are that old to remember that. Sad! > > Anyway, then I try it under 1.22.3, I get 2 spaces between the two. > > Before I go fishing for the problem, has anybody else experienced this and > have a fix? > > Thanks - Damian > > Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 > Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here > Views & opinions here are mine and not those of any past or present employer > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: GNUism in groff tests, was: pic anomalies
On Fri, Jan 03, 2020 at 12:45:22PM -0500, Doug McIlroy wrote: > > C is one of the worst possible foundation languages conceivable for > > automated formal verification > > Yet the Mars rovers run on a wholly checked code base written > in C, ... I sometimes think that C would be greatly improved if it just added: Strings as first-class objects (instead of a collection of array side effects) Hardened memory management Hardened pointer management -- Mike Bianchi
[groff] An alternative to info(1) ?
On Sun, Feb 16, 2020 at 07:55:31PM -0800, Larry McVoy wrote: > I *hate* info. It has made Linux less available to a lot of people. BUT info sometimes has information that man(1) lacks. So _maybe_ an approach would be to make an info2(1) command that had access to the same information with a different terminal interface. Or a dialog interface. So my question is does any have experience with a terminal walk-the-decision-tree interface they like? Could it serve as a model for info2 ? -- Mike Bianchi
Re: amusing bug
I nominate Brian Kernighan. Mike Bianchi On Tue, Mar 17, 2020 at 12:30:21PM -0400, Eric S. Raymond wrote: > Doug McIlroy : > > Please excuse my antediluvian hangover. > > *snort* > > If I had to make a list of the top three people who never, *ever* need > apologize for "antediluvian hangover", the other living designee > besides yourself would be Ken Thompson. Sadly Dennis Ritchie is no > longer available to fill the third slot. I suppose Don Knuth will do. > > :-) > -- > http://www.catb.org/~esr/";>Eric S. Raymond
Re: amusing bug
On Tue, Mar 17, 2020 at 01:37:22PM -0400, Steve Izma wrote: > : > For a description of a real antediluvian habit, there's a short > video somewhere (I can't find it now) of him talking about why he > doesn't need the Internet while crossing the Atlantic by ship. See https://youtu.be/6v6wdK2EbIQ?t=298 -- Mike Bianchi
Re: weird \s
> What do folks think? I would add that where \s[nnn] is legal it would be the preferred syntax. It is what I use all the time, even for \s[9] . Unambiguous. Witness in groff: .sp 8 .ps 8 \ .ps 8 \s10 10 \s40 40 \s(20 20 \s[40] 40 \s[120] 120 attachment: witness.png Mike On Tue, Mar 31, 2020 at 12:32:04PM +1100, G. Branden Robinson wrote: > At 2020-03-30T19:16:56-0400, Doug McIlroy wrote: > > Does anyone else see the following behavior? > > Version 1.22.4 handles \s correctly up to \s39, but > > truncates a size of 40 or greater to its first > > digit. Here are two screen shots, with ^D edited in > > to show where input ends and output begins. > > Hi Doug! > > This appears to be for backward compatibility. The 1992 revision of > CSTR #54 says in �2.3: > > "Note that through an accident of history, a construction like \s39 is > parsed as size 39, and thus converted to size 36 (given the sizes > above), while \s40 is parsed as size 4 followed by 0. The syntax \s(nn > and \s�(nn permits specification of sizes that would otherwise be > ambiguous." > > As Robert Thorsby noted, this is documented in the groff Texinfo manual; > however, it is not noted in the groff(7) man page, something I'm > inclined to fix in the near term. > > To the broader group, I would furthermore suggest that, being GNU roff, > it might behoove us to preserve the above "accident of history" only in > compatibility mode, and have the \sn form accept only a single-digit > argument for consistency with other escape forms. Doug still would have > gotten into trouble, but it would have been a more easily understood > trouble. > > What do folks think? > > Regards, > Branden -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: weird \s
On Tue, Mar 31, 2020 at 09:57:08AM +0100, Ralph Corderoy wrote: > : > The point of being able to format historical documents is that they can > be formatted without examination and editing to fix what today might be > considered bad style. In an ideal world, preserved historical documents would be generated from preserved historical source processed by preserved historical processing programs running on preserved historical systems. "Backward" compatibility has always been fraught with pain. Designing for forward compatibility requires a genius we rarely, but do occasionally, see. I think UTF-8 encoding may be such. -- Mike Bianchi
Re: weird \s
Bjarni,
Nice, tight analysis and proposed solutions. Thank you.
Mike Bianchi
On Thu, Apr 02, 2020 at 11:58:01PM +, Bjarni Ingi Gislason wrote:
snip
> 1) The missing part is information.
> Solution:
> a) Provide a message (warning, error), if "\snn" is in the input.
> b) Augment the documentation to tell the readers,
> that "\snn" is deprecated, obsolete, out of date, etc.
> and what they should use instead.
>
> 2) About the "\snn" problem.
> The current executing code is not the problem.
> The current existing roff-files are not the problem.
> The problem is the people who (still, will) write "\snn"
> instead of "\s(nn" (portability) or "\s[nn]" (for "groff" and
> compatibles).
snip
> 3) Other things.
> a) A missing part of messages is the name of the culprit,
> in this case the s-escape (\s).
> Solution: Provide the name ("\\s escape" is already used once in the
> subroutine).
> b) Adding details of the argument of the escape in messages is not
> necessary.
> c) Adding specific code to report specific syntax errors is not
> necessary.
snip
Re: * RL * code review and strategy for macros set?
On Wed, Aug 12, 2020 at 06:07:21PM +0200, Marc Chantreux wrote:
> hello Mike,
>
> first of all: pardon my lack of culture but i don't get what "RL" means
> in this case. i suppose it's a way to say you replied intentionally to
> me and not to the mailing list but have no confirmation of that�.
RL has to do with the mail filtering I have.
It means nothing to anyone else.
> it is sad that the rest of the mailing list can't read this very
> interesting answer.
That was a goof on my part. I'll add the groff mailing list to this response.
> On Tue, Aug 11, 2020 at 10:44:53AM -0400, Mike Bianchi wrote:
> > I would suggest you turn the list upside down and start with something that
> > _works_ even if not to your liking.
>
> i gave roff a try in circa 2000 and i hated it. i started again since
> the begin of the year because i love the man command and wanted to write
> my own manuals.
>
> it quickly appeared to me that
>
> * compared to the other typesettings systems (including the very
> overated TeX), troff isn't that bad.
> * my only sine qua none is fixed by the -k flag
> * now understand that some syntax "limitations" actually really
> ease many automations
> * nothing compares when it comes to be fast and lightweight.
>
> so i started using mm, me and ms and got results that are far enough
> for me but if i want to go further, i should be abble to tune the
> documents to comform the visual chart of my employees for exemple.
>
> if i can be good enough at it, maybe i can introduce roff in the
> communities i work for.
> > The *roff commands are an _assembly_ language with lots of hidden states,
> > arcane rules and interactions. It's value is that it works and that _lots_
> > of
> > smart people mastered it to such a degree that some _really_ clever things
> > have
> > been done with it. Macro sets are the means of doing the clever things.
>
> to explicit one question i have: should a high level macro set rely on
> lower level ones like ms (as it seems ms is't as rich and opiniated than
> me, mm and mom)?
I strongly recommend you pick one macro set, read and become fluent in the
the concepts in the command macros manual for that set and use the built-in
tuning features to make them look the way you want. You are _not_ the first
person to want it "just like that, but different" and you will find that the
macros sets are built with fine-tuning in mind. I have used the mm package
since it's invention and have always used a set of its fine-tunings to make
it specific to my needs.
export GROFF_TMAC_PATH=${HOME}/lib/tmac
groff -Kutf8 -GtpeR -U -rW6.5i -mm -mFm ...files...
where Fm refers to the "Foveal macros" that tune the mm macros. They are
found in ${HOME}/lib/tmac/Fm.tmac .
There I have things like:
\# A mark list of checkoff boxes.
.de CheckList
.ML "\s+8\(sq\s0 " 7
..
.de CheckListEnd
. LE 1
..
> > Said another way, many have gone before you and pushed the rock far up the
> > mountain.
>
> i'll take my time on it as i'm convinced mastering troff is worth it.
>
> > Skim and then re-read the *roff command manual of your choice.
> > I suggest groff.
> > ... [you describe a interesting path there ] ...
>
> thanks for this widsom. I just copied m.tmac as ike.tmac and will
> modify/tune it until the documents i already written fit the look
> i acheived in my demo.
I advise _against_ modifying the standard *.tmac files, especially with the
sets like me , ms and mm . They rarely change, but when they do you loose
the benefit of the fixes.
> > When you think you have the basics down, go to the macro package of your
> > choice
> > and attempt to understand the simple macros for the simple concepts. I use
> > mm so I would start with
> >
> > .P Paragraphs
> > .SP line SPacing
> > .HU Header Unnumbered
> > .R Roman font
> > .B .I Bold Italic
>
> i'll do that one by one.
>
> > ((From someone who has been writing nroff/troff/groff since the late
> > 1970s.))
>
> impresive :)
No. Just old.
> in a sense, i envy you: it feels to me that computers were about for and real
> hobbists back then so the digital culture was much more inspiring than
> nowadays.
I was fortunate enough to be at Bell Labs when the UNIX Programmer's Work Bench
was happening and in one of the first groups to do our PL/I code development on
a UNIX PWB machine that took the place of a card puncher, punch card reader and
printer. Said another way, it was a work environment making use of a new
Bell Labs innovation. It led into a career.
> �: The New Hacker's Dictionary definition of RL is "Real life"
>(http://www.catb.org/jargon/html/R/RL.html)
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: * RL * code review and strategy for macros set?
On Thu, Aug 13, 2020 at 10:57:45AM +0200, Marc Chantreux wrote:
> :
> thank you for your patience while reading my broken english.
You do me the honor of speaking my language. It is I who should thank you.
> > export GROFF_TMAC_PATH=${HOME}/lib/tmac
> > groff -Kutf8 -GtpeR -U -rW6.5i -mm -mFm ...files...
>
> > where Fm refers to the "Foveal macros" that tune the mm macros. They
> > are
> > found in ${HOME}/lib/tmac/Fm.tmac .
> :
> cool. what i had
> in mind was a bit different: having a ock.tmac that starts with
> something like `mso mm`.
That is the equivalent.
In the UNIX/Linux world there are many correct solutions.
Enjoy the journey!
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: Learning troff - where to start?
> Isn't it sad that nothing more modern is available? Since it is open source, it might make sense to have a team produce a groff version? Mike Sent from my Adesso PCK-308UW. On Wed, Oct 14, 2020 at 10:26:27AM +1100, Greg 'groggy' Lehey wrote: > On Tuesday, 13 October 2020 at 22:49:03 +0200, J.-J. wrote: > > Le mardi 13 octobre 2020 � 14:41 +0200, Johann H�chtl a �crit : > >> * What would be a good starting point (tutorial) into troff and its > >> core principles? > >> > >> * What is the canonical documentation of troff all the existing > >> implementations seem to derive from and describe their deltas in > >> their respective documentation? > > > > Here is in my opinion the best book on the subject > > (and it's now FREE!) : > > > > https://www.oreilly.com/openbook/utp/ > > An excellent book, and one that I have used a lot. But nobody can > claim that it's up-to-date (it predates groff), and there are many > features in groff that weren't in the troff version described. Isn't > it sad that nothing more modern is available? > > Greg > -- > Sent from my desktop computer. > Finger g...@lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: UTP Revisited: scoping the project
> Should we talk about newer groff macro packages like -mom? > What about utilities and preprocessors? Absolutely. I imagine this turning into a collaboration of many authors and editors, with most concentrating on just the chapters where their expertise is greatest. Mike On Tue, Oct 20, 2020 at 12:55:57AM -0400, Larry Kollar wrote: > To be honest, I can’t believe over a fourth of my life has gone by since we > started the > transcription. > > Now, with sources where everyone can grab them, maybe we should talk about > what we > want to do for UTP Revisited. These are just off the top of my head: > > - Update Chapter 3 to cover Vim (including gvim) > - Update Chapter 4 to cover groff (and Heirloom and Neatroff, listing the > most significant >differences)* > - Update Chapter 5 (-ms) and Chapter 6 (-mm) with groff extensions. > - New chapter: Ways to work with other file formats, with the goal of > getting content into >[gt]roff. Cover conversion utilities such as pandoc and lowdown. I’ll take > this one at least >to first draft… maybe I’ll throw in a plug for Tines as a groff-friendly > outliner, LOL. > - Where DWB is mentioned, point out that some utilities (like pic) are part > of the standard >distributions now, and mention replacements for other DWB utilities. (Or > has DWB been >liberated?) > > Should we talk about newer groff macro packages like -mom? What about > utilities and > preprocessors? I think preconv is a must, do we want to at least mention grap > or groffer? > > Do we want to cover lighter editors, such as pico, nano, or joe? > > What about “upstart" scripting languages such as Perl or Python? > > OK, that’s all I have, and I’m up way past bedtime. Does anyone else have > ideas about > what should be in an updated UTP? > > — Larry > > --- > *This implies updating the macros to work with non-groff formatters, and that > implication > is deliberate on my part. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: UTP Revisited: scoping the project
On Tue, Oct 20, 2020 at 05:56:46PM +1100, Damian McGuckin wrote: > On Tue, 20 Oct 2020, Larry Kollar wrote: > > > To be honest, I can?t believe over a fourth of my life has gone by since > > we started the transcription. > > The scarier thought is when you realize that you wrote your first tutorial > for using the antecedents of groff more than half your lifetime ago! OK! Everyone line up in the order of their first exposure to *roff. Mr McIlroy all the way on the right ... -- Mike Bianchi
Re: [groff] 03/06: roff(7): Develop History section a bit more.
> ... what is the evidenvce
> that Mike Lesk is the author of the man(7) macros?
I asked Michael about man(7) and ms(7) ...
Subject: I did not write the "man" macros.
I did write -ms.
My best guess at the author of the "man" macros is Doug McIlroy.
tx
Michael Lesk
--
Mike Bianchi
Re: [DRAFT] Revised groff ms manual for review
> Overall, let’s (both of us) focus on trimming anything that doesn’t > help a reader get a -ms document together. YES! But don't throw away the trimmings. They often contain info that the more involved readers might value. So maybe there can be an Appendix called "Color Commentary"? ;) Mike On Tue, Nov 10, 2020 at 11:40:26PM -0500, Larry Kollar wrote: > > G. Branden Robinson wrote: > > > Happy Halloween! > > > > Ready for something on the gory and disturbing side? > > I got six staples in my head, day before Halloween. They’re out now, > but I had a live-action creepshow going for the day. Bring it. :D > > > I feel like I'm about 40% of my way through a huge update of Larry > > Kollar's ms.ms document, as promised earlier this year. I've done most > > of the work over the past 2-3 weekends; the promise of a release kicked > > my rear into gear. > > I’ve looked it over. I’m not sure if the chatty parts are yours or mine > at the moment. When I get a chance, I’ll run a diff and see which of us > said what. > > Overall, let’s (both of us) focus on trimming anything that doesn’t > help a reader get a -ms document together. > > > … I started discovering just how much is of our > > s.tmac is undocumented, and how much confusion there has historically > > been over what, _exactly_, constitutes the historical ms interface. > > I have mixed feelings about this. What’s the goal, here? Unless people > are trying to resurrect older documents, they shouldn’t have to care about > the “historical” interface — just use what’s there. But… > > There was once “the” *roff. Then it sunk, and Groff took its place. But > thanks to Plan9, the “the” *roff resurfaced with a lot of nice updates, then > got forked to Neatroff and Heirloom. Fortunately, the differences are > small enough that one can write a -ms extension package for both, using > “.ie g / .el” or “.if g / .if neat" in a few places. > > The whole point of ms.ms was *not* to get into internal details. It was > mostly “here’s how you use Groff and -ms to put a document together, > and here’s how you can control the formatting.” Yes, the end of the > document does describe differences from the original -ms, and that’s > probably helpful for the Plan9 derivatives. > > But unless you’ve unearthed a 35 year old document that assumes it’s > using “the” *roff, and is doing all sorts of creepy things under the hood, > it shouldn’t matter much. My college roommate sent me a book he wrote > in -mm, back in the 80s, and I got Groff to format it by adding “\&” to > the beginning (he had a custom cover). The same should apply to -ms > documents. > > If we want to support data archaeologists, maybe we should write a > separate document for them. :D > > — Larry -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Long text in tbl won't wrap, maybe related to mom
I don't know what the intended appearance was supposed to be, but
this sort-of works; substitute a tab-character for each ...
.TS
expand;
cb s s s
c | c | c s
ltiw(1i) | ltw(2i) | lp8 | lw(1.6i)p8.
Some Interesting Places
_
NameDescriptionPractical Information
_
T{
American Museum of Natural History
T} T{
The collections fill 11.5 acres (Michelin) or 25 acres (MTA)
of exhibition halls on four floors. There is a full-sized replica
of a blue whale and the world's largest star sapphire (stolen in 1964).
T}Hours 10-5:45 S M Tu Th, 10-9 W Sat. Sun.
LocationT{
Central Park West & 79th St.
T}
AdmissionDonation: $1.00 asked
SubwayAA to 81st St.
Telephone212-769-5100
_
.TE
The characters used to delineate columns disappears in normal printing.
Mike
On Fri, Feb 05, 2021 at 11:05:58AM -0300, Bento Borges Schirmer wrote:
> Hello
>
> I'm having great joy composing little documents for some homework and
> assignments using groff and the mom package. Yesterday I wanted to learn how
> to
> make tables so I read through mom's excellent documentation and
> reproduced all tables except the last one from L. L. Cherry and M. E.
> Lesk's Tbl -- A Program
> to Format Tables, when I encountered a problem where the lines wouldn't wrap:
>
> .PRINTSTYLE TYPESET
> .START
> .TS
> expand;
> cb s s s
> c | c | c s
> ltiw(1i) | ltw(2i) | lp8 | lw(1.6i)p8.
> Some Interesting Places
> _
> NameDescription Practical Information
> _
> T{
> American Museum of Natural History
> T} T{
> The collections fill 11.5 acres (Michelin) or 25 acres (MTA)
> of exhibition halls on four floors. There is a full-sized replica
> of a blue whale and the world's largest star sapphire (stolen in 1964).
> T} Hours 10-5:45 S M Tu Th, 10-9 W Sat. Sun.
> \^ \^ LocationT{
> Central Park West & 79th St.
> T}
> \^ \^ Admission Donation: $1.00 asked
> \^ \^ Subway AA to 81st St.
> \^ \^ Telephone 212-769-5100
> _
> .TE
>
> This is a minimal version of the last example from the tbl document that
> reproduces the funny behavior. It breaks the line as in the source, but the
> table grows beyond the page and doesn't stay as nice as seen e.g. on the troff
> FAQ or when using groff -Tpdf -t -ms. Am I missing something? Is there any
> workaround? I don't mind manually breaking the lines, of course.
>
> Best regards,
> Bento
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: problem with mm macros
Andreas has found a true bug. The .AT macro does not act as advertised in groff_mm ... The title _does_not_ show up after the name in the signature block. Search /usr/share/groff/1.22.2/tmac/m.tmac (the copy I am using at present) fgrep 'cov*at!' /usr/share/groff/1.22.2/tmac/m.tmac and I find .\" author(s) title stored in cov*at!x!y . ds cov*at!\\n[cov*au]!\\n[cov*i] "\\$[\\n[cov*i]] which shows that cov*at!N!N is created as cov*at!1!1 but never referenced. Witness: If I give nroff -mm the following ... .ND "January 1, 1999" .AU "Dr. Gray Hound" .AT "Project Leader" .MT 5 .nf \*[cov*au!1!1] \*[cov*at!1!1] it yields ... Dr. Gray Hound Project Leader Does anyone maintain m.tmac these days? Mike On Thu, Feb 25, 2021 at 09:55:59AM -0500, Robert Goulding wrote: > I get the same result; and then tried variants with .LT instead of .MT, and > the signature is not produced at all! > > On Thu, Feb 25, 2021 at 9:44 AM Andreas Eder wrote: > > > > > Hello, > > > > I'm a newcomer to roff and have just begun reading the book 'UNIX > > Document Processing and Typesetting'. There is an example of a letter in > > there thay I enclose here, necause it shows the poblem: > > > > .ND "January 1, 1999" > > .AU "Dr. Gray Hound" > > .AT "Project Leader" > > .MT 5 > > .DS > > Our Reference: prog/001 > > Your Reference: xyz/100 > > .SP 4 > > Mr. William Smith > > Chief Advisor > > Consult the Consultants > > Penny House > > Graceland > > .DE > > .SP 3 > > Dear Mr. Smith > > .SP 2 > > .ce > > Recruitment of a Programmer > > .fi > > .SP 2 > > .P > > With reference to our discussion over lunch at the West Gate Club, > > the requirements of the programmer are as follows: > > .P > > The programmer should be conversant in all computer programming languages > > and be ready to develop any kind of software using different computers. > > The programmer must also be willing to do administrative and paperwork > > to get his/her pay. > > .P > > Although the requirements may seem to be unusual, I am sure > > that with your company's expertise in head hunting, finding a > > suitable person for the above-mentioned position will be a trivial matter. > > .P > > Hope to hear from you soon. > > .FC Sincerely yours > > .SG > > > > Now the problem is that groff doesn't show the author's title below the > > author's name. Both heirloom and neatroff do, so it is maybe a bug in > > groff? Also both heirloom and neatroff show name and tile in bold, > > whereas groff only shows the name an does not do so in bold. > > > > Maybe someone with more experience in roff can explain what goes wrong. > > > > Sincerly, > > > > Andreas Eder > > > > > > > > > > -- > Robert Goulding > Director, John J. Reilly Center for Science, Technology, and Values; > Director, Program in History and Philosophy of Science; > Assoc. Professor, Program of Liberal Studies, > Fellow, Medieval Institute, > University of Notre Dame. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] Re: Modernising UNIX manpages.
> I would like to investigate the possibility of using Markdown as an > alternate format for UNIX man-pages. For what it is worth ... This is a very old story and I might not have all the details correct, but the basic message fits here. And the basic message is: Once you have a stylized markdown for man-pages that produces a stylized output of groff, mandoc and/or html create back-converters to turn changed output into the source form. The story is from the mid 1970s. A friend worked on a project that used a "data dictionary" (https://en.wikipedia.org/wiki/Data_dictionary) and a specification language (spelling out the functionality of the code in stylized English) to drive translator programs that produced: IBM IMS (Information Management System) database specification language andCOBAL code and functions for accessing the databases. The inputs AND outputs were _so_ stylized that making changes in any of the outputs were translated back into the input specification language and data dictionary with reverse-translator programs. The translation paths thus became a circle. Changes could be made in any of the output forms and reflected back into the other input forms. All the input forms were human-readable. Someone who could only read the data dictionary could change the code in a predictable way. Likewise for someone who was IMS-knowledgeable. Over time the project became very stable. Changes were reliable. When bugs were found the bug-fixes were often in the translators. Thus finding one bug would often fix many more un-found bugs. IFF such a thing could be accomplished for the man-pages, then maintaining them would be something that could be passed along down the generations. ((I am 73 years old. I grew up with nroff/troff/groff. I think I have written my last man-page.)) I imagine pairs of translators, like maybe: markdown <-> mandoc mandoc <-> groff groff<-> html The <-> translators might be macro packages (for groff, or may mom) or could be written in a Python, Ruby, or something else. It would have to be a team effort with team consensus. Mike On Wed, Apr 21, 2021 at 05:46:58AM +0200, JM Marcastel wrote: > Dear all, > > I would like to investigate the possibility of using Markdown as an > alternate format for UNIX man-pages. > (Cf. https://github.com/marcastel/marcastel/discussions/7) > > Rather than re-inventing the wheel I would ideally like this to > become part of an existing tool (mandoc, groff, ...). > > I would like to devote time to this in the second semester of 2021 > and would appreciate sharing this. > > I believe the first step is to provide a proof of concept what > demonstrates the expected outcome and that desired command line > interface. > > I have a clear idea on how to build that POC once the requirements > have been set. > > Has this already been studied? Would this be an initiative you > would support? > > Best regards, > JM Marcastel > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Introducing mu, my new macro package
> http://ankarstrom.se/~john/mu.html With just a quick glance, I like what you've done. I can see myself using it sometime soon. One suggestion, give the Inline, Environment and Other macros 2 or 3 character names with a common theme so they stand separate from the groff commands and macros. May I suggest ... .\" Inline macros -- .\" U" -- inline quotation .\" Ub -- bold font .\" Uc -- constant-width font .\" Ui -- italic font .\" Ux -- bold italic font .\" Environment macros - .\" Ud -- centered date .\" Uh -- heading .\" Ul -- literal display .\" Up -- paragraph .\" Uq -- quotation .\" Us -- subheading .\" Ut -- centered title .\" Other macros --- .\" U( -- begin footnote .\" U) -- end footnote .\" Uw -- want space or .\" Inline macros -- .\" _" -- inline quotation .\" _b -- bold font .\" _c -- constant-width font .\" _i -- italic font .\" _x -- bold italic font .\" Environment macros - .\" _d -- centered date .\" _h -- heading .\" _l -- literal display .\" _p -- paragraph .\" _q -- quotation .\" _s -- subheading .\" _t -- centered title .\" Other macros --- .\" _( -- begin footnote .\" _) -- end footnote .\" _w -- want space I have so many documents where _all_ the groff actions are in lower case and I don't know where to look when I need to understand the action and syntax. Is it native groff? Or the mm macro package? Or something I wrote? Now when writing my own macros I tend to make them start with a capital letter or be all capitals. Again, very nice! Mike On Thu, Jul 01, 2021 at 08:09:25PM +0200, John Ankarström wrote: > Hi all! > > I've been working on my own troff macro package for the last couple of > weeks, and I thought I'd share it with you here: > > http://ankarstrom.se/~john/mu.html > > The package is called "mu". In summary: > > It is simple, flexible and small: u.tmac is only 417 lines. > It has footnotes and tables of contents. > It has no special registers or strings! > > For an example of an advanced document written with mu, see > http://git.ankarstrom.se/mu/plain/README.pdf. > > I hope you find it interesting and perhaps even useful. Feel free to > write any questions or feedback. > > Best regards > John -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Introducing mu, my new macro package
> So if you see a one-letter macro, it's definitely a macro and not a > standard troff request. True. But I must memorize that .x is a font-change macro. If it were .Ufont bi I am more likely to remember that the font will change to Bold Italic. And it is from the U set. And someday it could take the cbi argument. Constant-Width Bold Italic But I say again, very nice! Welcome to the Macro Writers Guild. Mike On Thu, Jul 01, 2021 at 09:44:13PM +0200, John Ankarström wrote: > Den 2021-07-01 kl. 21:15 skrev Mike Bianchi: > > With just a quick glance, I like what you've done. > > I can see myself using it sometime soon. > > > > One suggestion, give the Inline, Environment and Other macros 2 or 3 > > character names with a common theme so they stand separate from the groff > > commands and macros. > > > > [...] > > > > I have so many documents where _all_ the groff actions are in lower case > > and I don't know where to look when I need to understand the action and > > syntax. Is it native groff? Or the mm macro package? Or something I > > wrote? > > > > Now when writing my own macros I tend to make them start with a capital > > letter > > or be all capitals. > > Thanks a lot! The neat thing about the one-letter lowercase macros, > though, is that all built-in troff macros are two letters (or more). So > if you see a one-letter macro, it's definitely a macro and not a > standard troff request. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[Groff] Test of connectivity ...
My ability to send e-mail to groff@gnu.org was broken. It should now be fixed. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax [EMAIL PROTECTED] http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Is this a bug?
On Wed, Aug 20, 2008 at 07:29:16AM -0500, Clarke Echols wrote: > I ran into an interesting "behavior" this morning... > > > Here is the offending text: > > .H3 "\f2.\^.\^.including 21 examples" > > Macro H3 is defined as: > > . de H3 > . ce 1 > . ft HB > . ce 1 > \\$1 > . ft 1 > .. > > I get an error because groff is interpreting the first dot > in .\^.\^. as the first character in the argument to H3, apparently > ignoring \f2. If I put a \& sequence in front of the first dot, > it's happy and everything works. > > Is this what I should expect? > > Clarke Yes, it is what you should expect. The \f2 and \^ are processed before the argument is passed to H3 . You could place the \& in front of the \\$1 inside the macro so you don't have to remember about the \& in the argument. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax [EMAIL PROTECTED] http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] comments in non-fill mode
On Wed, Sep 03, 2008 at 08:50:04AM -0400, Louis Guillaume wrote: > Hi! > > It appears that comments are "counted" in non-fill mode. Is this by > design for some reason? > > 8<---8<--- > .nf > text text text text text text text > \".ps 14 > \".vs 15 > \"\v'-3.05'TEXT TEXT TEXT TEXT > \"\v'-3.05'\n[year]\(bu\n[mo]\(bu\n[dy] > TEXT TEXT TEXT TEXT > \n[year]\(bu\n[mo]\(bu\n[dy] > > >8--->8--- > > remove the comments and the text pushes up. > > Louis That's because the \" makes the _rest_ of the line a comment. I have long used '\" as my comment header for full-line comments and that works here. So does .\" . Recently I've preferred groff's \# as the comment marker. man 7 groff includes the following ... \" Beginning of a comment. Everything up to the end of the line is ignored. \# Everything up to and including the next newline is ignored. This is interpreted in copy mode. This is like \" except that the terminating newline is ignored as well. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax [EMAIL PROTECTED] http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Changing font in ".FG"
On Fri, Sep 05, 2008 at 12:20:25PM -0400, Randall Allemang wrote: > I am a casual user of release 1.18 and would like to change the font in the > figure title macro ".FG" . it is currently Times Roman and the normal font > registers used by headings and other macros don't seem to have any effect. > I have read through the pertinent sections of the MS and MM macros and also > looked through the TC and EQN references. > > As always, it will probably be a pretty simple fix or reference but I am at > a loss to figure it out. > > Help! > > Randall J. Allemang, PhD > Professor of Mechanical Engineering > Director, Structural Dynamics Research Lab > > 685 Rhodes Hall, University of Cincinnati > Cincinnati, Ohio 45221-0072 > > TEL: 513-556-2725 > FAX: 513-556-3390 I find that this works, especially if you simply want to format in something other than the Times fonts: R I B . Using groff -mm .fp 1 H .fp 2 HI .fp 3 HB .ftr R H .ftr I HI .ftr B HB .DS Fig test .FG "Fig test caption" .DE See .fp and .ftr in groff(7) . It shouldn't take both .fp and .ftr to make the change but looking into the /usr/share/groff/1.18.1/tmac/m.tmac , I find that there both references to fonts by position and by hard-coded R I B names. I'll take on the task of rationalizing that someday soon. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax [EMAIL PROTECTED] http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Changing font in ".FG"
Looking into the complaint about the fonts and MM .FG command, I discover
that this was fixed in 2006 and is in the current CVS download, but not in
the 1.18.1 version distributed with Ubuntu 8.04.
In fact, it was fixed by Werner in delta 2.29 2006-03-28, to
groff/contrib/mm/m.tmac,v ...
. Hardwire first four font positions with R, I, B, and BI -- the
documentation explicitly refers to this feature (cf. the `HF'
string register).
. Don't use `%' register in numeric calculations because it is
affected by `.af'.
Patches for both problems have been contributed by Nick Stoughton
<[EMAIL PROTECTED]>.
* m.tmac: s/@language/@country/.
s/\n[%]/\n[P]/ where appropriate.
s/\fR/\f1/.
s/.ft R/.ft 1/.
s/\fI/\f2/.
s/.ft I/.ft 2/.
s/\fB/\f3/.
s/.ft B/.ft 3/.
* mse.tmac: s/@language/@country/.
* groff_mm.man (Fonts): New subsection.
* groff_mmse.man: Load `sv.tmac'.
Reformatted.
examples/README: Cleanups and updates.
So the problem is that the fix is not currently wrapped up in a
distribution yet.
Werner, I'm new to all this. What's the procedure for getting the
latest-and-greatest out to the distributions?
Mike Bianchi
- Forwarded message from Mike Bianchi <[EMAIL PROTECTED]> -----
Date: Sat, 6 Sep 2008 10:29:04 -0400
From: Mike Bianchi <[EMAIL PROTECTED]>
To: Randall Allemang <[EMAIL PROTECTED]>
Cc: groff@gnu.org
Subject: Re: [Groff] Changing font in ".FG"
On Fri, Sep 05, 2008 at 12:20:25PM -0400, Randall Allemang wrote:
> I am a casual user of release 1.18 and would like to change the font in the
> figure title macro ".FG" . it is currently Times Roman and the normal font
> registers used by headings and other macros don't seem to have any effect.
> I have read through the pertinent sections of the MS and MM macros and also
> looked through the TC and EQN references.
>
> As always, it will probably be a pretty simple fix or reference but I am at
> a loss to figure it out.
>
> Help!
>
> Randall J. Allemang, PhD
> Professor of Mechanical Engineering
> Director, Structural Dynamics Research Lab
>
> 685 Rhodes Hall, University of Cincinnati
> Cincinnati, Ohio 45221-0072
>
> TEL: 513-556-2725
> FAX: 513-556-3390
I find that this works, especially if you simply want to format in
something other than the Times fonts: R I B .
Using groff -mm
.fp 1 H
.fp 2 HI
.fp 3 HB
.ftr R H
.ftr I HI
.ftr B HB
.DS
Fig test
.FG "Fig test caption"
.DE
See .fp and .ftr in groff(7) .
It shouldn't take both .fp and .ftr to make the change but
looking into the /usr/share/groff/1.18.1/tmac/m.tmac , I find that there
both references to fonts by position and by hard-coded R I B names.
I'll take on the task of rationalizing that someday soon.
--
Mike Bianchi
Foveal Systems
973 822-2085 call to arrange Fax
[EMAIL PROTECTED]
http://www.AutoAuditorium.com
http://www.FovealMounts.com
[Groff] Suggestions on how to trace this out ...
Folks, particularly mm folks. I'm looking for a suggestion on how to approach this problem. Consider the file i.mm .de xx yy .sp 2 .yy And the command line groff -mm i.mm You would expect, and in fact get, no output. -Tps is the default. BUT consider the command line groff -Tascii -mm i.mm You would expect the same but instead get ... i.mm:3: warning: `yy' not defined Huh? groff -Tlj4 -mm i.mm Nothing. groff -Tlatin1 -mm i.mm i.mm:3: warning: `yy' not defined groff -Thtml -mm i.mm Output, but no error. The version of contrib/mm/m.tmac does not seem to matter. I suspect the version of groff does, but the one that I know used to work is from about the year 2000, so ... I've not detected any obvious pattern, and am wondering how to proceed. Suggestions? -- Mike Bianchi
Re: [Groff] tbl is not flexible to adjust itself according to page layout
On Sat, Sep 13, 2008 at 12:01:53AM +0800, [EMAIL PROTECTED] wrote:
>
> Hello. One issue with tbl is it does not warp the line of text within
> table cells unless explicitly warped around using T{ and T}. If the page
> is too narrow to hold the table, the table simply expands to outside of
> the page. This is probably less flexible than HTML where the table is
> always trying to linewrap its content to fit in page narrow-ness.
>
> Is there no other way than wrapping content with T{ and T}? Having these
> wrappers makes the source code difficult to read for my super-large
> table, and I have to wrap every cell because I don't know which one
> might cause the table to expand outside of page right margin. My
> document is a 10 page table, difficult to manage. A try-and-error
> approach (print it out, check which cell is too wide, wrap only that
> cell with T{ T}) is too time consuming and is not following the basic
> principle of using a computer (to let computer does repetitive work
> instead of human).
>
> Searched tbl manual without luck yet.
>
> Thanks in advance for suggestions & comments.
To the best of my knowledge newline T{ ... T} newline is the only
mechanism that does what you want.
BUT I've written a quick preprocessor that you could use in front of
tbl(1) in your pipeline (or in front of groff -p ... ) to get the effect
you asked for.
I called the script tbl_pp (tbl preprocessor) and it reads:
-
#!/bin/sh
tab='_'
# NOTE: the \1/g and the T}/g lines must not be indented!
exec sed '
/^\.TS/,/^\.TE/ {
/^TT{/ {
s/^TT{//
s/.*/T{&T}/
s/'"${tab}"'/T}'"${tab}"'T{/g
}
s/T{\(.\)/T{\
\1/g
s/\(.\)T}/\1\
T}/g
}
'
-
My test script reads ...
-
#!/bin/sh
trap 'rm /tmp/$$' 1 2 3 15
tbl_pp <<\! | groff -t -mm - >/tmp/$$
.
.P
start
.
.na
.
.TS
tab(_) ;
l l l l .
.
asdlkfj_asdlfjk_dasjflldaskfj_ads
asdlkfjdasf_asdlfjk_dasjflldaskfj_ads
.
TT{ aaa aa _b bb b
bbb_ccc ccc c c ccc_dd d ddd
.
T{ 111 11 T}_T{2 22 2
222T}_T{333 333 3 3 333T}_T{44 4 444T}
.
.TE
.
done
!
gv /tmp/$$
-
I've defined a tbl tab to be _ in both the .TS ... .TE table
and the tbl_pp script. Clearly they need to match.
There lines in the groff test that are just a . to make reading the
script easier. They have no effect.
There are two ways to trigger the mechanism that turns tab-separated
columns into tab T{ newline ... newline T} tab delineated columns:
IF at line begins with TT{ that line is wrapped in T{ ... T}
and each tab (i.e. _ ) is turned into newline T} tab T{ newline .
IF any other tbl line contains any number copies of T{ ... T} ,
it is changed into T{ newline ... newline T} .
One of each trigger are illustrated in the test script.
I think one could reasonably make the case that any occurrences of
T{ ... T} should (optionally?) be processed as if the newlines were present,
as an enhancement to tbl .
But, the originators of UNIX and troff back in the day would argue that
this sort of preprocessor shows the value of small, simple algorithms
encapsulated in small, simple scripts and this is the right way to do this.
You don't have to wait for a change to the big tool, you can accomplish the
same thing on your own right now (if you know enough shell script tricks).
But I, too, find the newline T} tab T{ newline mechanism cumbersome and
would welcome an alternative.
Let's all go get a beer and discuss this somewhere ;)
Mike
--
Mike Bianchi
Foveal Systems
973 822-2085 call to arrange Fax
[EMAIL PROTECTED]
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] search order of tmac directories
On Fri, Oct 03, 2008 at 08:55:52AM +0200, Werner LEMBERG wrote: > Folks, > > the search order for tmac files (as documented in troff.man) is > > 1. directories given with the -M command line option > 2. directories given in the GROFF_TMAC_PATH environment variable > 3. the current directory (only if in unsafe mode) > 4. the home directory > 5. a site-dependent directory, e.g. /usr/local/lib/groff/site-tmac > 6. a local directory, e.g. /usr/local/share/groff/site-tmac > 7. the standard directory, e.g. /usr/local/share/groff/1.19.3/tmac > > I think there is a logical error, and 5 should be exchanged with 6 to > have an order with the decreasing priority. > > If noone objects, I'll reverse it accordingly. I'm guessing that the logic is that 6 and 7 are both rooted in /usr/local/share and 5 is not. To me that seems logical. Are there a definitions for site-dependent directory local directory ? -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax [EMAIL PROTECTED] http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] groff -mm output something I don't expect
On Fri, Nov 14, 2008 at 08:58:50AM +0100, Werner LEMBERG wrote: > > > I ``troff'' a simple file, hello.mm whose content is: > > > > .\" hello.mm > > Hello World! > > > > with the command line: > > > > $ /usr/local/bin/groff -mm hello.mm > hello.ps > > > > and opened it with ``evince'', then I found there are two short bars > > in topleft and topright corners of the page. > > This must be a problem with evince then. Here is the PS output of > your document (omitting the preamble) as processed with the current > CVS version of groff (and I doubt that this has changed recently): > > /F0 10/[EMAIL PROTECTED] SF > 2.5(-1-)277.006 48 S > (Hello W)69.336 96 Q > (orld!) -.8 E > 0 Cg > EP > > As you can see, no bars are created. Maybe those bars indicate the > left and right side of the paper, similar to the flashing lines in gv? Is it possible the "two short bars" are the - 1 - (meaning page 1) that mm places as the Page Header? -- Mike Bianchi
Re: [Groff] Problem with -me package
On Sun, Feb 08, 2009 at 10:57:41PM +0300, Anton Shepelev wrote: > 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 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 -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Creating Word/rtf output
On Tue, Mar 03, 2009 at 09:58:50AM -0600, Jeremy C. Reed wrote: > > "GNU troff?? What is that? These days the publishers really want either > > MSWord or TEX files. We can try the HTML result, but I predict lots of > > issues in the typesetting! You'll be correcting proofs for weeks. > > Maybe try troffcvt > http://www.snake.net/software/troffcvt/ Wow! ... and troffcvt is a standard Ubunutu offering. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] changing .em behaviour?
I agree with make the bizarre behavior a "compatible" feature. This discussion explains oddities I never figured out and got out of use brute force. Mike On Tue, Apr 21, 2009 at 08:50:28AM +0200, Werner LEMBERG wrote: > > Folks, > Joachim told me that in the original documentation of the AT&T troff > the addition > > ...but all processing ceases at the next page eject > > in the description of the `em' request is missing. He thus suspects > that this bug has been raised to be a feature; instead of fixing it > they just documented it. > > 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. > > Werner -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Re: [Groff] changing .em behaviour?
Denis makes a good point, but I wish to offer a counter argument.
If the model of groff was "compatibility over all" I would agree with him.
But, in my opinion, groff is not aiming for compatibility as the first
requirement. The very fact that the line
.sp1
yields
warning: `sp1' not defined (probable missing space after `sp')
(unless the -C option is invoked) illustrates that groff has moved beyond
historical troff.
To me that implies that the unexpected behavior of .em should not be
preserved.
The fact the .em will act differently in compatible mode, and that fact
will be documented, is good enough for me.
Mike Bianchi
On Wed, Apr 22, 2009 at 07:48:50PM +0100, Denis M. Wilson wrote:
> I think we have to be cautious about changing the behaviour
> of requests. We do not know whether someone out there has not
> made use of a particular feature of a request, documented or
> not. I know this from personal experience. I've carried out a
> large number of experiments to find what requests actually do,
> the old troff docs being *very* terse.
>
> I therefore support only the *new* .em1 request, and then
> only if there is a genuine need (I'm against feature bloat).
>
> Denis
--
Mike Bianchi
Foveal Systems
973 822-2085 call to arrange Fax
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] groff mm problems
Micheal, Please provide a specific example (input and output) and the command line you use to create it. A reduced example with just the .AL or .DL lists exhibiting the behavior you describe is best. Also provide the output from these commands: groff --version locate /tmac/mm.tmac Thanks. Mike Bianchi DOn Sat, Apr 25, 2009 at 07:33:27AM +0200, Werner LEMBERG wrote: > Please help this guy. > Werner > > == > > I am now trying to generate lists using .AL and .DL commands as I did > back at Bell Labs. As I remember and find in the GROFF/mm references, > one can single space lists by setting Li to 0 or '.LB 0 0 0 0 '; > however, in each case, my list output still comes out double-spaced. > Is there some other feature that I must set to get the single spacing > in .AL and .DL lists when processing 'groff -mm'? These features > always worked with the Bell Labs UNIX and with the groff I used at > Fermi Labs. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] groff mm problems
On Sat, Apr 25, 2009 at 05:55:33PM -0700, michael lindenmeyer wrote: > I doscoveret that the tmac directory was not in my PATH, so added it. The > results are the same, no single spacing > as requested by '.LB 0 0 0 0'. The PATH is used by the shell to find commands. It has no effect on where groff finds that file. I asked you to locate /tmac/mm.tmac to see the version number in the path name. Likewise for groff --version . I'm using groff 1.18.1 but your input still produces the output you describe. In my old Bell Labs Memorandum Macros documentation from 1980, section 5.3.3.1 describes the line spacing number register Ls . Ls is also described in the groff_mm(7) man page, under Number variables used in mm: Someone else on the groff mailing list (I've lost who) suggested adding .nr Ls 0 before the first .AL A macro. With that in your test file, I get ROYGBIV and Valve Metals ROYGBIV a. Colors of the rainbow. b. Frequency/Wavelength c. The Angstrom Observing ROYGBIV a. Refraction 1. The Prism 2. The Rainbow 3. Double Rainbow b. Interference/Diffraction 1. Reflection 2. Constructive Interference 3. The Second Pass Valve Metals a. Titanium, tantalum, zirconium, hafnium, niobium, aluminum b. Electrical current one-way, rectifier, AC to DC c. Oxide is electrochemically grown. 1. Like Rust, but: 2. Transparent, like glass 3. An Electrical insulator 4. Uses beside rectification -- Insulator, store charge, capacitor -- Thickness, trimmable resistor etc. > Thanks for your help and advice. > Mike (MichAEl) > 090425.1955 > > Link: [1]File-List > > GNU groff version 1.20.1 > > - > > ./uwin/usr/share/groff/1.20.1/tmac/mm.tmac (AHA! not in my PATH!, could that > be the problem??) I added it to > PATH, no improvement. > > - > > PATH=/home/tfilm:/home/tfilm/bin:/c/uwin/usr/bin:/c/uwin/usr/share/groff/1.20.1/tmac:/usr/bin:/sys:/win:. > > > --- > > groff -mm -Tascii roygbiv.$is > roygbiv.txt > > --- > > ***input, roygbiv.$is*** > > > .nr pl 55 > .DS C > ROYGBIV and Valve Metals > .DE > .AL A > .LB 0 0 0 0 > .LI > ROYGBIV > .AL a > .LI > Colors of the rainbow. > .LI > Frequency/Wavelength > .LI > The Angstrom > .LE > .LI > Observing ROYGBIV > .AL a > .LI > Refraction > .AL 1 > .LI > The Prism > .LI > The Rainbow > .LI > Double Rainbow > .LE > .LI > Interference/Diffraction > .AL 1 > .LI > Reflection > .LI > Constructive Interference > .LI > The Second Pass > .LE > .LE > .LI > Valve Metals > .AL a > .LI > Titanium, tantalum, zirconium, hafnium, niobium, aluminum > .LI > Electrical current one-way, rectifier, AC to DC > .LI > Oxide is electrochemically grown. > .AL 1 > .LI > Like Rust, but: > .LI > Transparent, like glass > .LI > An Electrical insulator > .LI > Uses beside rectification > .DL > .LI > Insulator, store charge, capacitor > .LI > Thickness, trimmable resistor > .LE > .LE > .LE > .SK > .LI > Anodization > .AL a > .LI > Electrochemical cell > .LI > Electrolyte, Acetic acid > .LI > Anode and Cathode > .LI > Cathode: Hydrogen release > .LI > Anode: Anodic Oxide > .LI > Voltage limited thickness > .LI > Wavelength of light > .LE > .LI > Interference of white light > .AL a > .LI > Double reflection, constructive interference > .LI > Oxide thickness, 1/2 wavelength > .LI > Oxide thickness, 1 wavelength > .LE > .LI > Generating the oxide > .AL a > .LI > Start, 35 volts > .LI > Continue, 40 by 20 to 140 > .LI > go to 150 > .LI > Continue, 160 by 20 to 240 > .LI > Go to 250, end of 7000 ang film. > .LE > .LE > - snip - > > --- On Sat, 4/25/09, Mike Bianchi wrote: > > From: Mike Bianchi > Subject: Re: [Groff] groff mm problems > To: "Werner LEMBERG" > Cc: groff@gnu.org, "michael e lindenmeyer" > Date: Saturday, April 25, 2009, 4:15 PM > > Micheal, > > Please provide a specific example (input and output) > and the command line you use to create it. > A reduced example with just the .AL or .D
Re: [Groff] option to set output file name
Woops.
"file descriptor" 0 is the standard input.
file descriptor 1 is the standard output
file descriptor 2 is the standard error output
On Wed, Apr 29, 2009 at 09:15:06AM +0100, Ralph Corderoy wrote:
>
> Hi Michail,
>
> > may be I am missing something trivial, but I can not find a
> > command-line switch in groff to direct output to file.
>
> No, I'm pretty certain there isn't one.
>
> > Output redirection is no problem in shell scripts, but if groff is to
> > be spawned from another program it becomes a problem, either you spawn
> > a shell runing a script or spawn groff and have to bother with piping
> > output. You can not just fire off groff and forget about it. What a
> > miss :(
>
> When you say "spawn a shell runing a script" I assume you know you can
> give the shell a command to execute with the -c option without a script
> file needing to exist on disc? For example, in C,
>
> ret = system("groff foo.tr >foo.ps");
>
> will cause sh(1) to be execve(2)'d with
>
> execve("/bin/sh", ["sh", "-c", "groff foo.tr >foo.ps"], [/* 55 vars */])
>
> So yes, that does involve a shell being started just to run groff, but
> then you're wanting the shell's I/O redirection syntax to be
> interpreted. As I think you're saying, you could avoid this by manually
> forking and setting up file descriptor 0 to be writing to foo.ps before
> execing groff but it's hassle and system() is just easier.
>
> An option shouldn't be added to groff to do this. By that logic, awk,
> sed, make, date, and wc should all grow an --output option too.
>
> Cheers,
>
> Ralph.
--
Mike Bianchi
Re: [Groff] Handling '...'
On Mon, Jun 22, 2009 at 10:54:27PM +0200, Tadziu Hoffmann wrote: > : > > [...] since typographers and designers had never been happy > > with the full word space [...] > > Any citations on this? The typophile forum seems divided > on the issue. Chicago apparently specifies a 1/3 em space > between dots. > : Ah, the differences of opinion. Ever it has been so. The trick is to construct the work so that when faced with the "required change" one keeps one's sanity. It is clear to me that this is another case where What You See Is What You Get (WYSIWYG) typesetting is fundamentally flawed. Advantage groff, latex and the like. The ellipsis in any particular work is usually used to convey some literal or stylistic meaning. That says to me that the _important_ thing is to use it consistently through out the work. He thought . . . and then acted. So the right thing (to me) to do, in the groff context, is to define an ellipsis object, such as .ds ellipsis ".\ .\ ." and then _always_ use _that_ object in the text when _that_ meaning is to be conveyed. He thought \*[ellipsis] and then acted. Better yet is to define the object in terms of the meaning, so it is clear to the author what the original meaning was. .ds long_pause ".\ .\ ." He thought \*[long_pause] and then acted. Then, when the editor insists that the typography for a particular meaning be different, the correction is both easy and localized to just those places that should be affected. -- Mike Bianchi
Re: [Groff] Arithmetic in groff
Joachim, 10^2 Thanks! I made one _little_ change. I always name my macros, etc. starting with a Capital Letter, so as to keep them distinct from the standard offerings. Mike Bianchi On Tue, Oct 20, 2009 at 08:41:39PM +0200, Joachim Walsdorff wrote: > Here is a little macro to enhance the restricted groff-arithmetics. It > uses the unix bc-command for arbitrary precision calculations (see the > bc-manpage). Maybe it's easier to use for people (like me) who are not > familiar with pic to use its numerical engine like suggested by Ted: > > .de calc > . sy echo -n ".ds *calc " > /tmp/calc; echo "\\$*" | bc -l >> /tmp/calc > . pso cat /tmp/calc; rm /tmp/calc > .. > > The argument of calc is the expression to be calculated; string *calc > returns the result. groff must be called with -U, because the register > .U is readonly and therefore it is not possible to change between > safe/unsafe-mode inside groff. > > Examples: > > .calc scale=5; 10^2 \" scale=5: 5 digits right from the decimal point. > .tm \*[*calc] => 100.0 > > The second example should yield the same result: > > .calc scale=5; e(2*l(10))\" e=exponential function, l=natural logarithm. > .tm \*[*calc] => 99.99898 > > This result is not exact, since bc /truncates/ (without rounding) the > values of e(2) and l (10) to 5 digits (value of scale). > > Joachim -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Re: [Groff] gro html problem
Chuck Robey:
Please send a specific example, including the commmand lines you use.
I'll take a look.
Mike Bianchi
On Wed, Dec 09, 2009 at 11:05:35PM -0500, Larry Kollar wrote:
> Chuck Robey wrote:
>
>> I was told this is the best place to ask grohtml questions ... I'm
>> having
>> problems, The macro set I use is mm (please don't just tell me to use
>> ms, I
>> LIKE mm), but a fairly basic thing in there doesn't seem to be
>> working: the use
>> of the list macros, like the .AL/.LI/.LE things. What comes out seems
>> to be
>> missing any line break between the last piece of text *prior* to the
>> introduction of the list mark (like, for ".AL A", the "A". I've tried
>> to force
>> things by adding .br nor .sp, but can't get the break to show up, and
>> such a
>> list is useless.
>
> Nobody has gone in and made the modifications to mm to work well with
> grothml. One thing you could do is to add this to the beginning of the AL
> definition:
>
> .if '\\*[.T]'html' \{\
> . ds mm:html:alclass decimal
> . if '\\$1'A' .ds mm:html:alclass upper-alpha
> . if '\\$1'a' .ds mm:html:alclass lower-alpha
> . if '\\$1'I' .ds mm:html:alclass upper-roman
> . if '\\$1'i' .ds mm:html:alclass lower-roman
> . nop \\X^html:^
> .\}
>
> You'll have to do similar modifications to .LI and .LE -- actually, for
> .LE you'll have to create a stack of which type of list is active (ul,
> ol, dl) and insert the proper closing tag. You can look at the ms, man,
> and mwww macros to see how it was done. I think in a lot of ways, mm
> would be easier to make work with grothml than ms was; there are a lot of
> similarities between mm markup and HTML. I suppose more people were using
> ms (and man, obviously) than mm, so that's where the effort went.
>
> If you need something quick, you might want to hunt down mm2html or
> maybe troff2html and see if you can get acceptable results (piping
> through HTML Tidy often helps a lot with that).
>
> Hope this helps,
>
> -- Larry
--
Mike Bianchi
Foveal Systems
973 822-2085 call to arrange Fax
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] grohtml
Chuck, As a fellow lover of mm (since the mid-1970s) I will try to help. Please send along: example files that illustrate your issues, both sources and results the simpler the examples, the better the command lines you use to create the results from the sources the output from groff --version output from uname -a I will take a look and let you know what I find. Mike Bianchi On Wed, Dec 23, 2009 at 09:43:52PM -0500, Chuck Robey wrote: > I'm a very long-term user of groff (with the mm macros), I have a problem with > my new attempts to get html output, and I'd appreciate either knowing if my > problem has already been attended to, or if I need to try to do it myself, > then > maybe a pointer telling me where the files that are most likely to hold the > problem are. > > Please note, all of my comments below are about use of grohtml and the mm > macros. If I missed saying this somewhere, believe it, I love the mm macros, > and can use them just fine in ps or pdf or ascii. I might mention that I'm > hugely happy with groff over troff, also (that shouldn't surprise you any). > > My problem is in trying to use mm macro's list macros, for html output only. > I'm currently working around this by using chapters instead, but that's a very > unsatisfactory solution. The problem is that when you begin the list, there > is > no line break going into it. No line break caused by the macro, but no line > break either if I go out of my way to force one via the .br, the .sp, of .SP > requests. Eaxmple is, when I put a centered title on top of the page, the > list > below it begins *immediately* at the last character of the centered title. > > Like I said, if there hasn't been any work on it, I'll have to give it a try > myself, and I'm willing to try that, but while I have written successful > macros > before, I can't claim to be any genius at it. I sure would appreciate any > comments at all on this, something which might give me a shove in the right > direction. > > Oh, btw, please don't bother telling me to try other macros sets (like ms) > because I like mm, it's got features I don't care to do without, and I'm being > stubborn (probably). -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Another hdtbl patch
On Wed, Feb 03, 2010 at 02:08:47PM -0500, Larry Kollar wrote: > : > This actually brings up something that has been bugging me for a while, > and I think deserves its own thread: we should come up with some > namespace guidelines for macro packages, especially for internal-use > macros, to prevent conflicts. Whatever we agree on could go in the > texinfo document. Yes, please. I would very much like that conversation. I'm willing to transform the mm macros to whatever we agree upon. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Another hdtbl patch
On Thu, Feb 04, 2010 at 09:43:40AM +1100, Robert Thorsby wrote: > On 04/02/10 06:08:47, Larry Kollar wrote: > > This actually brings up something that has been bugging me for a > > while, and I think deserves its own thread: we should come up with > > some namespace guidelines for macro packages, especially for > > internal-use macros, to prevent conflicts. Whatever we agree on could > > go in the texinfo document. > > As one who lacks the coding skills to contribute, but who often creates > ad hoc macros in specific documents, I would like the texinfo document > to contain suggestions for the naming of macros that are created within > documents. > > For example, I use caps+lc with * as a word separator for macros that > will only be called by other macros: > > .de My*Ad*Hoc*Macro > > but this suffers the obvious problem when the macros are intended to be > inserted into the body copy by $USER. I currently use: > > .de MAHM > > and > > .de Mahm > > for this purpose but live in fear that I have accidentally overridden > some tremendously important macro in a package that I am about to use. > > Perhaps, texinfo might address this point? Or have I missed something? > > Robert Thorsby > There is none so blind as they that won't see. > -- Jonathan Swift, "Polite Conversation" Suggestion: No macro, register, or string name within standard macro packages will ever end in * . Thus all user created names that end in * will never collide with any within the standard macro packages. E.g. .de MAHM* .nr pi* .ds address* -- Mike Bianchi
[Groff] names in groff -- was: Another hdtbl patch
On Thu, Feb 04, 2010 at 10:11:59PM +0100, Werner LEMBERG wrote: > > No macro, register, or string name within standard macro > > packages will ever end in * . Thus all user created names > > that end in * will never collide with any within the standard > > macro packages. > > Nice idea. Have you already verified that no macro provided by any of > the `big' macro packages end with `*'? No, I have not. I was just shooting from the hip. > It should be noted that such > user macro names must be longer than two characters. I'm thinking groff needs the concept of namespace . By default, everything lives in the top, unnamed namespace so all the bugs are preserved. E.g. .de LI \" my own take on the LI macro in the mm macros : .. .namespace MM -mm \" start the namespace MM, \" which contains the -mm macro package. .MM.BL \" use .BL from the MM namespace .LI \" use .LI from the top (unnamed) namespace : .MM.LI \" use .LI from MM : .MM.LE .BL \" There is only one .BL (in MM); use it. .LI \" As above. : .MM.LI \" As above. : .LE \" There is only one .LE (in MM); use it. .MM.\" default all following macros to the MM namespace. .BL \" use .BL from MM .LI \" use .LI from MM : ._.LI \" use .LI from the unnamed namespace (named _ ?) : .LE ..namespace MM \" end default to MM . .MM.BL \" still defined. .namespace Mine \" start the Mine namespace. .de Glurp \" defines .Mine.Glurp . : .. .Glurp \" uses .Mine.Glurp , \"" unless ._.Glurp is defined. ..namespace Mine\" end Mine . .Mine.Glurp \" still defined. This is just a sketch, and needs to be thought about more. I'm sure someone who designs languages will have good suggestions. Comments? -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [SPAM] RE: [Groff] Extending .tm to allow for file handles
On Wed, Feb 17, 2010 at 08:38:17PM -0500, Tom Borawski wrote: > : > Thanks to all the Groff developers. You have no idea of how useful > you have turned what is possibly the oldest continuously used software > package. Amen. As a continuous user of n/t/groff since 1974 I also am most appreciative. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] preserve ascii escape characters from input
On Sat, Feb 27, 2010 at 12:25:31PM +, Ralph Corderoy wrote: > > > It's horrible when commands hard-code ANSI escape sequences, e.g. > > > the otherwise good dstat(1). > > > > I think it's pretty common these days, though. I took a quick peek > > and ls, grep, colordiff and git all hard-code ANSI. My dstat(1) on Ubunutu 8.04 Linux puts out color escapes when the it talks to a terminal, but is mono-chrome when invoked in a pipe line or into a file. dstat | cat - dstat >dstat.out Similarly for ls --color=auto . -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Questions about the MM macro package
On Fri, Apr 23, 2010 at 07:16:13PM +0400, Anton Shepelev wrote: > Mike Bianchi: > > > I am a day-to-day MM user (since the 1970s) so I should be able to help > > you. Please provide stripped down examples that demonstrate your concerns > > and I'll look at them. > > Here's a sample script: > > .PGFORM 30n 25v 0u > \".PH \" don't want any headers, but this affects > \" . \" only the next page... > .VM 0 0 > .AL > .LI > I like these structured lists. > .LI > I really do. This text should be 30 symbols wide, as > defined by the .PGFORM macro called in the beginning of > the document. > .LE > .P > The page height is low, so a new page is going > to begin soon. And it will have a correctly > centered header on it, as disticnt from the > first page. > .P > > The result: > >- 1 - > > > > 1. I like these structured > lists. > > 2. I really do. This text > should be 30 symbols > wide, as defined by the > .PGFORM macro called in > the beginning of the > document. > > The page height is low, so a > new page is going to begin > soon. And it will have a > > > > > > > > > - 2 - > > > > correctly centered header on > it, as disticnt from the first > page. > > > My questions: > > (1) Some settings (page width affecting the printing of >the header) seem not to work from the very first >page. Does it mean I can't avoid using the command- >line parameters for MM? I'd like to have full control >over the document from inside the souce code. > >I have found that PH can turn off the header, but >again, it works only form the second page... The .PH macro has to be processed before and "output" occurs. Read .PGFORM in the groff_mm man page carefully. > (2) I couldn't set the vertical margins to zero (note the >vertical space between the pages). How to do it? Since you do not want any top- or bottom-of-page processing at all, see TP and EOP in the man page. By defining macros with those names and no content, you get the effect you want. Hence ,.. cat i .de TP .. .de EOP .. .PGFORM 30n 25v 0u . .AL .LI I like these structured lists. .LI I really do. This text should be 30 symbols wide, as defined by the .PGFORM macro called in the beginning of the document. .LE .P The page height is low, so a new page is going to begin soon. And it will have a correctly centered header on it, as disticnt from the first page. .P command nroff -mm i >j 1 2 3 12345678901234567890123456789012345 pr -n j 2010-04-23 13:26j Page 1 1 1. I like these structured 2 lists. 3 4 2. I really do. This text 5 should be 30 symbols 6 wide, as defined by the 7 .PGFORM macro called in 8 the beginning of the 9 document. 10 11 The page height is low, so a 12 new page is going to begin 13 soon. And it will have a 14 correctly centered header on 15 it, as disticnt from the first 16 page. 17 18 19 20 21 22 23 24 25 -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Questions about the MM macro package
On Sat, Apr 24, 2010 at 12:25:17AM +0400, Anton Shepelev wrote: > : > 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. 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 Look at the groff(7) man page man 7 groff pr -o8 -t i1 .de TP .. .de EOP .. .ll 30n .pl 19v .po 0 \# .PGFORM 30n 19v 0u 1 \# .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. nroff -mm i1 >j1 pr -n -t j1 1 Hello, let’s test some lists: 2 3 1. One 4 5 The first element it 6 was. 7 8 2. Two 9 10 Now we approaching a 11 horrible and fearful 12 margin ‐‐ the bottom 13 margin of the page, 14 beyond which unknown 15 things await us. Let us 16 close the list. 17 18 List closed. 19 -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Headers in MM
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. .de HY .nr temp_indent_ \\w'\\*[}0]' .in +\\n[temp_indent_]u .ti -\\n[temp_indent_]u .nr ;0 2 .. .de HZ .in 0n .br .. . this is a test .H 1 asdfjkl asdfjkl asdfjkl adfjkl adfjkl adfjkl adfjkl sdkfjasldfkj \ sdkl sdfal sdfjkasdfjkl asdfjkl sdfjkl ajkl asdfjkl asdfjkl asdfjkl \ adfjkl adfjkl adfjkl adfjkl adf this is a test Mike On Tue, Apr 27, 2010 at 11:27:02PM +0400, Anton Shepelev wrote: > 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 -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Groff 1.19.2 and 1.20.1 differences
On Tue, May 04, 2010 at 07:24:44AM +0200, Werner LEMBERG wrote: > > > The 1.20.1 behavior is obviously wrong: [...] > > Since I don't use mm, I can only ask for contributors to provide a > fix. Is there anyone capable of checking whether Tadziu's suggestion > is correct? > > > Werner I will be happy to look at the mm issues in detail, since I depend on it. I have the background in n/t/groff to figure out the why of what is happening, given enough time. But I am up to my eyeballs until late May, and maybe beyond. I'll look at it then. -- Mike Bianchi Foveal Systems 973 822-2085 call to arrange Fax mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Hanging paragraphs in MM
On Tue, Jun 01, 2010 at 02:19:17PM +0400, Anton Shepelev wrote: > 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)? 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. .MyMacro FirstArg \ All the text that is processed by MyMacro FirstArg follows and \ in the case of a lot of text \ multiple lines. -- Mike Bianchi
