Re: getting more out of man pages with less(1) (was: [bug #59962] soelim(1) man page uses pic diagram--should it?)
On 17 May 12:50, G. Branden Robinson wrote: > [looping in linux-man@ because issues of user education and topics that > fall between project/man page stools come up below] > > At 2021-05-16T20:29:30-0500, Dave Kemper wrote: > > This stuff about less(1) is only tangential to groff, but it did come > > up in the context of viewing man pages, so I'm keeping the groff list > > in the cc. > > Good idea. I've further changed the Subject: to reflect the flow of the > discussion. > > > On 5/12/21, G. Branden Robinson wrote: > > > One thing I would mention is that less(1) supports regex searches > > > within its buffer. On my system, the searches are even > > > case-insensitive by default if the search pattern is all lowercase, > > > and not otherwise. > > > > less's default is for searches to be case-sensitive. Its -i option > > (which can be given on the command line or while less is running) is > > what activates the behavior described above. A user or a distro might > > make -i the default in their environment (I do) through the $LESS > > environment variable or an alias, but that isn't less's out-of-the-box > > behavior. > > On my Debian buster-based system, less(1) behaves that way, but $LESS is > not defined in my environment and I don't have a shell alias or function > set up. Checking the source package, I don't see patches to turn -i on > by default. Baffling! man(1) from the man-db package execs less(1) (or other configured pager) with the LESS environment variable populated with "-ix8RmPm%s$PM%s$". The %s escapes are replaced by the prompt string. See include/manconfig.h: #define LESS_OPTS "-ix8RmPm%s$PM%s$" Any existing $LESS is appended to this string prior to exec, allowing these options to be overridden. This is on debian buster. > > > > In fact, to leap among sections you can do > > > > > > /^[a-z] > > > > > > regardless of the lettercase convention, and after doing the above > > > once you can type simply > > > > > > / > > > > > > to repeat the search or > > > > > > ? > > > > > > to repeat it in the backwards direction. > > > > Or to save yourself a keypress (since those methods require a "Return" > > after the "/" or "?") you can use "n" and "N" respectively. Longtime > > vi users will do this without even thinking about it. > > Yup, you caught me. :D > > I don't think it's ever too soon to teach a user who has seen man pages > how to get more out of them, and that includes the pager interface. > It's frustrating because man(1), less(1), and man(7), formally > considered, can all disclaim responsibility for communicating this > knowledge. less(1) can page all sorts of text files, not just man > pages, and its own man page is huge and talks about all kinds of stuff. > man(1) is also big, and that program definitely is not the pager. > man(7) documents the macro package[1], which is a man page _writer's_ > interface, not primarily one for the reader. > > I find myself wishing that intro(1) from the Linux man-pages project > said more about this, either directly in that page or maybe in the > man(7) they provide, with a conspicuous pointer there from the former. > > Maybe Michael or Alejandro can advise regarding where they think a good > place for a man page utilization tutorial would be. > > I also wonder if the pager wars are basically over and less(1) won them. > I haven't heard anyone mention most(1) in a long time[2], and the, uh, > simple elegance of more(1)'s inability to seek its stream (meaning: no > backwards searching) seems to have driven many people to less(1) even if > they have reservations about the length of its feature list. > > Regards, > Branden > > [1] Michael Kerrisk can correct me, I hope, but as far as I know the > Linux man-pages man(7) page arose because, back in the '90s, the GNU > roff project refused to supply one, in keeping with the GNU "no > documentation at all if not Texinfo" philosophy--Susan G. Kleinmann > of Debian had to write one, which I guess escaped the notice of the > (Red Hat-using?) man-pages maintainer(s) of the time. By 1999, the > rigor of groff's fealty to that principle had slackened, and, > judging by groff's CVS-to-Git history, it looks like I can credit > Werner Lemberg with adopting and revising her work as groff_man(7). > > [2] a fate that seems to have inexorably claimed any project that > hitched its horses to S-Lang's wagon
Groff hdtbl tables disappear near the footer
Hello, I am new to groff. I am more a designer than a coder, so my understanding here may be lacking. I created a CV template using groff + ms macros + tbl + hdtbl. To be fair, it worked wonderfully. I was able to replicate what I had previously done with LaTeX. Including adding hdtbl table entries with macros. There is just one issue. I cannot get my head around why the tables created by hdtbl vanish as they approach the footer. If I place 6 tables in a row, tables one two and three will show on the first page, then tables 4,5 and 6 are gone. the following content is seen on the next page but not the tables (they appear to have been swallowed). I noticed, however, that a page break after the 3rd table causes the next 3 to appear on the following page. One caveat, sometimes when content moves, one of the middle tables (3 or 4) vanishes again, while the last few flow onto the next page. Perhaps this is by design and I am just naive to it, but I would love to know the cause and what I could do for reliable results. Kind regards, Mike
Re: Groff hdtbl tables disappear near the footer
> Can you prepare a pair of exhibits for us to test? One that doesn't > show the problem, and one with as minimal a change as you can make to > cause it to happen? Yes. I am attaching 3 documents: - A stripped down section of the CV template (hdtbl-issue.ms). - A macro file demonstrating the issue (hdtbl-issue-macros.ms). - A macro file demonstrating a temporary fix (hdtbl-issue-macros- working.ms). The command I have been using to compile: groff -ms -m hdtbl hdtbl-issue.ms > hdtbl-issue.ps && ps2pdf hdtbl- issue.ps hdtbl-issue.pdf Environment: Manjaro Linux The "working" macro file has only one change. Line 72 contains .ne 1.5i > Studying the differences between the two and the macros and requests > they do or don't call will likely help us to pinpoint the issue. That would be amazing! Thank you for looking into this. Kind regards, Mike .so hdtbl-issue-macros.ms .fam T .nr PS 10p .nr VS 15p .ds t*bgc white\" background color .ds t*fgc textcolor\" foreground color .ds t*bc linecolor\" border color .nr t*cpd 0.02n\" cell padding .br .sp -.4c .heading "Professional Experience" .WORK \ "2018 - 2023" \ "Job Title" \ "Company One" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem." .WORKBL \ "Achievement one" \ "Achievement two" .WORK \ "2014 - 2018" \ "Job Title" \ "Company Two" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam." .WORKBL \ "Achievement one" \ "Achievement two" .WORK \ "2010 - 2014" \ "Job Title" \ "Company Three" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam." .WORKBL \ "Achievement one" \ "Achievement two" .WORK \ "2010 - 2014" \ "Job Title" \ "Company Four" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam." .WORKBL \ "Achievement one" \ "Achievement two" .WORK \ "2010 - 2014" \ "Job Title" \ "Company Five" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam." .WORKBL \ "Achievement one" \ "Achievement two" .WORK \ "2010 - 2014" \ "Job Title" \ "Company Six" \ "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam. Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam." .WORKBL \ "Achievement one" \ "Achievement two" .de BL .IP \(bu 2 .. .ds ACCENT "\X'ps: exec .1 .3 .6 setrgbcolor' .ds GREY "\X'ps: exec .7 .7 .7 setrgbcolor' .ds DGREY "\X'ps: exec .3 .3 .3 setrgbcolor' .ds RED "\X'ps: exec 1 0 0 setrgbcolor' .ds BLUE "\X'ps: exec 0 0 1 setrgbcolor' .ds BLACK "\X'ps: exec 0 0 0 setrgbcolor' .ds WHITE "\X'ps: exec 1 1 1 setrgbcolor' .defcolor textcolor rgb #353535 .defcolor linecolor rgb #a1a1a1 .de smallcaps .nr .sc.ps (\\n[.s]*75/100) .nr .cap.PS \\n[.s] .char a \s[\\n[.sc.ps]]A\s[\\n[.cap.PS]] .char b \s[\\n[.sc.ps]]B\s[\\n[.cap.PS]] .char c \s[\\n[.sc.ps]]C\s[\\n[.cap.PS]] .char d \s[\\n[.sc.ps]]D\s[\\n[.cap.PS]] .char e \s[\\n[.sc.ps]]E\s[\\n[.cap.PS]] .char f \s[\\n[.sc.ps]]F\s[\\n[.cap.PS]] .char g \s[\\n[.sc.ps]]G\s[\\n[.cap.PS]] .char h \s[\\n[.sc.ps]]H\s[\\n[.cap.PS]] .char i \s[\\n[.sc.ps]]I\s[\\n[.cap.PS]] .char j \s[\\n[.sc.ps]]J\s[\\n[.cap.PS]] .char k \s[\\n[.sc.ps]]K\s[\\n[.cap.PS]] .char l \s[\\n[.sc.ps]]L\s[\\n[.cap.PS]] .char m \s[\\n[.sc.ps]]M\s[\\n[.cap.PS]] .char n \s[\\n[.sc.ps]]N\s[\\n[.cap.PS]] .char o \s[\\n[.sc.ps]]O\s[\\n[.cap.PS]] .char p \s[\\n[.sc.ps]]P\s[\\n[.cap.PS]] .char q \s[\\n[.sc.ps]]Q\s[\\n[.cap.PS]] .char r \s[\\n[.sc.ps]]R\s[\\n[.cap.PS]] .char s \s[\\n[.sc.ps]]S\s[\\n[.cap.PS]] .char t \s[\\n[.sc.ps]]T\s[\\n[.cap.PS]] .char u \s[\\n[.sc.ps]]U\s[\\n[.cap.PS]] .char v \s[\\n[.sc.ps]]V\s[\\n[.cap.PS]] .char w \s[\\n[.sc.ps]]W\s[\\n[.cap.PS]] .char x \s[\\n[.sc.ps]]X\s[\\n[.cap.PS
Re: Groff hdtbl tables disappear near the footer
> Seems to work if you add:- > > .am pg@top > . t*hm > .. That appears to have worked. Thank you for pointing that out. Very much appreciated! Kind regards, Mike
Is there a Groff showcase?
Hello, Not a technical question, so I apologise in advance if this is the wrong place to post. I'd like to know if a showcase of Groff typeset documents exists anywhere on the internet? Kind regards, Mike
Re: Is there a Groff showcase?
> It's not much, but I did some kind of a template for different stuff > with groff > that you can find here : https://t.karchnu.fr/doc/grofftut.pdf > > Not sure it's what you're looking for. Thank you Philippe. That is an interesting resource, thank you for sharing it with me. I was thinking of a website or web page which demonstrates the extent of groff's capabilities. If there isn't anything like this, currently. Has this been considered? I have only just learned of groff. The manual is awesome (though tough reading for me in places). groff does so much more than I first imagined. I don't know if this aligns with the goals of the contributors, but examples of some well-designed, finished documents might attract new users and potential contributors. Forgive me for being bold, I am just thinking out loud. Mike
Re: Is there a Groff showcase?
> Almost all my exams (being a science teacher) are created using Groff. That sounds really interesting. If it isn't confidential, I'd love to see a copy of your exam paper to see how it was made and how you create two versions in the same document. Kind regards, Mike
Re: Is there a Groff showcase?
> I can give you the source to the commercial license for a product we > did. That would be great. I'm new to groff, so I am only touching the surface of what it can do. I would love to see a working source which can perform these tricks. Kind regards, Mike
Re: Is there a Groff showcase?
> A showcase as like at a trade show? > I think it would be better to have easy to understand single topic prove-of-concepts samples, a bin to throw in and a whatever-grep- function for searching. My original thought was: Is there a website where the various document layouts and visual capabilities of groff are displayed? - Drop caps - Text in the margin - Text around an image or quote - Graphical title pages - Background images - Coloured backgrounds - Custom bullet points - Coloured text boxes - Custom paper sizes ... I have found information on technical aspects of groff and people here have been kind enough to point me toward some useful online resources. However, I have not seen any resources which focus on the visual aspects. This would allow people, including myself, to see at a glance how groff visually stacks up against word processors, LaTeX and desktop publishing software. To see if groff is the right choice for their project. I am, currently, exploring to find the visual boundaries of the software and any help from groff users would be appreciated. Has anyone achieved flowing text around an image or text box, I would love to know? (I have seen discussion on this topic, but no examples). Mike
Re: Proof Of Concept, Flowing Text Around Left-Aligned Image
> There has been a bit of discussion recently regarding the uploading > of examples of [gt]roff in action. So I munged an example from one of > my documents. Thank you for sharing. I managed to (more or less) replicate your example using your code. While I don't understand it all, yet, I am experimenting further to help me grasp it. > Please note, while the concept works and the result is > typographically pleasing (well, it is to me) it is far from the > refined efforts that are usually presented to this list. But, it > may serve to whet the appetite of those who actually know what > they are doing. I agree, I would love to see any advancement on this. Mike
Re: [Groff] (no subject)
On Wed, Mar 27, 2013 at 08:08:33PM -0400, Anonymous wrote: > Subject: simply trying to put a box around text > > I found a rough example out in the wild for how to box text using > groff. This is my attempt to make it work: > > ===8<- > #!/bin/bash > > cat < .B1 > &client > &address1 > &address2 > &address3 > .B2 > EOF > ===8<- > > Any ideas why the text does not end up inside a box? Piping the text > through "pic" was a guess.. but it does not make a difference either > way. try ... cat
Re: [Groff] encapsulated postscript from pic
On Wed, May 01, 2013 at 11:02:58PM -0400, Louis Guillaume wrote:
> On 4/23/13 3:34 PM, Doug McIlroy wrote:
> > Is there a tool or trick for getting encapsulated postscript from pic?
> > What I want is that the bounding box should have origin 0 0 and
> > be just big enough to cover the picture.
> >
> > Doug McIlroy
>
> I have this in my Makefile...
>
> .ms.eps:
> ${GROFF} -stp -ms -dpaper=${PAGE} -P-b16 $< > $*.ps
> ${GS} -dNOPAUSE -sDEVICE=bbox -- $*.ps 2>$*.bbox
> ${SED} -e "/^%%Orientation/r $*.bbox" -e "/^%\!PS-Adobe-3.0/s/$$/
> EPSF-3.0/" $*.ps > $*.eps
> rm $*.bbox
>
>
> ... seems to do the trick.
>
> Louis
Sweet! A grateful community thanks you!
--
Mike Bianchi
Re: [Groff] Integrating Figures and text ?
John,
Look at man grops ; inparticular the reference to PSPIC .
The -mps macros (which are automatically loaded when grops is
run by the groff command) include a PSPIC macro which allows a
picture to be easily imported. This has the format
.PSPIC [-L|-R|-I n] file [width [height]]
file is the name of the file containing the illustration; width
and height give the desired width and height of the graphic.
The width and height arguments may have scaling indicators
attached; the default scaling indicator is i. This macro will
scale the graphic uniformly in the x and y directions so that it
is no more than width wide and height high. By default, the
graphic will be horizontally centered. The -L and -R cause the
graphic to be left-aligned and right-aligned respectively. The
-I option causes the graphic to be indented by n.
I use it with the .DS/.DE display macros of the -mm memorandum macros
to include encapsulated postscript (EPS) images in my documents.
E.g.
.DS
.PSPIC fig/Chalkboard_mic_schematic.eps 5i
.FG "Ideal Positions of Contact Microphones
.DE
Mike
On Wed, May 29, 2013 at 08:33:20AM -0700, John W. Smay wrote:
> This is a problem I have had for years and hope maybe someone, or
> everyone but me, has a simple solution. I write technical text and
> equations with groff, then save as .ps (PostScript) and translate to
> .pdf (Acrobat). I parallel I generate figures, mostly complex line
> drawings or technical plots (not photographs or "art") that are
> illustrations to accompany the groff text. The figures are made with
> other applications such as Canvas, fortran code, of c code. but all
> (most) can be in either .ps, .eps. or .pdf format.
>
> So in the end I have a file with groff generated code in .ps or
> .pdf, and a separate file with the illustration in the same format.
> The groff file is a page with text at the top, a blank portion for the
> illustration, and more text at the bottom. The problem is to combine
> the two files into a single .ps or better .pdf that presents text and
> figure on the same page. There must be a command sequence to be
> embedded in the groff source that will import the file with the
> illustration in a satisfactory fashion.
>
> I have tried more alternate approaches than I cam remember, e.g..
> importing both the groff .ps or .pdf and the illustration into Canvas
> or Word, editing onto a single page, then resaving the result, but
> every attempt is flawed in some way! Bolds disappear, subscripts get
> misplaced or resized or countless other flaws.
>
> Thanks in advance, John
>
> John W. Smay
> email: jws...@earthlink.net
> web site: http://home.earthlink.net/~jwsmay/prof.html
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] Multiple Lines Equation
On Sat, Oct 26, 2013 at 01:30:00PM +0200, Tadziu Hoffmann wrote: > Here's a small hint on what the second version is intended > to accomplish (see if you can recognize this in the code): > > If the equation does not overlap (with a safety margin of 1 em) > with the text in the previous (partially-filled) line, then > don't space (because then there's already a full "v" of space > above the equation), otherwise space half a "v". > After the equation, space half a "v" again and turn on > no-space mode, in case another equation follows immediately > after (since you don't want twice the space between equations > as between the equation and the surrounding text). > If you absolutely must space after the equation, insert > ".rs" immediately after ".EN" in your document. That sounds like a good comment to include in the code. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Multiple Lines Equation
On Sat, Oct 26, 2013 at 04:17:22PM +0200, Tadziu Hoffmann wrote: > > > That sounds like a good comment to include in the code. > > I remember reading somewhere that comments are unnecessary > because the code is "obvious": > > www.usm.uni-muenchen.de/~hoffmann/roff/tmp/rpdup.pdf > > (formatted using groff, so it's not completely off-topic. :-) That once might have been true, but I am living proof that the solar-constant has changed because I routinely come across code that I clearly created but which I: don't understand what it does, and/or don't understand why it does what it does, and/or don't remember creating. (There should be an option to this shell script (that I wrote) to do Glurp. Oh! It already is there, and the usage message tells me so, if I would just look at it.) Today's obvious is tomorrow's obscure. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.coq
Re: [Groff] [PATCH] Use bash for several contrib scripts
On Thu, Jan 02, 2014 at 04:07:20PM +, Roger Leigh wrote: > On Thu, Jan 02, 2014 at 05:00:04PM +0100, Ingo Schwarze wrote: > > Hi Mike, > > > > Mike Bianchi wrote: > > > > > There is no man page for sh(1) . > > > There is no executable for /bin/sh . On Debian ... > > > > Sorry if that answer seems blunt, but it is not groff's > > problem if the shell is broken in Debian. > > It isn't broken. It's just a minimal POSIX shell. It will work > fine with any script, providing you aren't using any non-standard > bash, ksh or zsh extensions. There might possibly be some new > POSIX shell standard features which it doesn't yet support, but > I've yet to encounter any deficiencies should any exist. If you > were using such features, it would doubtless break any many other > systems as well using older POSIX shells. Please define what a non-standard extension shell is. When troff and nroff were new, in the 1970s, /bin/sh came from a file named sh.c . My point is that #!/bin/sh is the name of a shell command that is not documented. In fact it does not exist anymore. More over, on Debian, the man page for the dash(1) shell that /bin/sh does point to _admits_ that that document is incomplete and that the command is not strictly POSIX compliant. How is someone attempting to understand a #!/bin/sh script to know what the writer intended if there is no documented way to interpret the syntax? All my shells start with #!/bin/bash or #!/bin/ksh (depending on how long ago I wrote them -- some are decades old). That way whoever reads them knows what standard I was writing to. I'm suggesting that all the groff scripts should point to the shell the writer was using when they were written. The shell is very unlikely to have been /bin/sh . -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] [PATCH] Use bash for several contrib scripts
On Thu, Jan 02, 2014 at 09:12:38PM -0500, Peter Schaffter wrote: > On Thu, Jan 02, 2014, Mike Bianchi wrote: > > How is someone attempting to understand a #!/bin/sh script to know what > > the > > writer intended if there is no documented way to interpret the syntax? > > #!/bin/sh > # This script is written for the bash shell. See bash(1). > > Or is that just too obvious? Wouldn't #!/bin/bash be more obvious and less error-prone? For years my /bin/sh linked to /bin/ksh . It took a while when debugging ~#/bin/sh shells (often written for /bin/bash) to figure out _that_ was what was burning me. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] space width
On Tue, Feb 04, 2014 at 11:32:00AM -0500, Peter Schaffter wrote: > ... What of > future macro programmers, though? How many who might contribute to > groff are going to shake their heads over what to them will seem > absurd anachronisms and simply move onto programming for something > unemcumbered by what are rapidly becoming absurd historical > idiosyncracies? Is the absolute purity of backward compatibility > worth relegating a powerful and useful program to the museum? The fact that I can still format documents I wrote in the 1970s and beyond is valuable to me, and, should any of them ever become classics, possibly to others in the future. So no, do not break groff by "modernizing" it. The "absurd anachronisms" were once the best we could do. But that is no reason why a groff2 could not come into being. After all roff begat nroff, which begat troff, which begat ditroff, etc. A groff2 that learned from lessons from the likes of tex, latex, and (gasp) the WYSIWYG formatters while preserving the (to me) essential property of letting me compute my documents from (sometimes very dynamic) source has the potential to be quite wonderful. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Future direction of groff
My 2 cents. I learned nroff/troff in the mid 1970s, and have used it, almost exclusively, ever since. It is what I know in my spine. The MM macros are my presentation format of choice, for the same reason. But my criticism of groff, and HTML, TeX etc., is that presentation and formating are horribly intermingled. By "presentation" I mean concepts such as Title, Chapter, Section, Figure, Footnote, Table of Contents, Index (still use permuted index via ptx), etc. "Formating" to me means how it looks on paper/screen/tablet, etc. To me the value of groff is that the _words_ are the most important things and even if I lost my ability to format past *roff documents, I still have all the words. I can even recover many of the words associated with presentation concepts. Done right, a really great macro package would have to clearly separated parts: presentation and format. But it seems *roff has never really provided the architecture to support that sort of separation, hence macro packages that mush the concepts together. And thus the long standing habit of tweaking the format with commands scattered among the words to fix the formatting errors. In an ideal world, I would write thinking only about the words of the text and their associated presentation concepts. THEN, when sending my creation to the world, some automation would make it look appropriate on paper and all the variations of "screen" out there (on GoogleGlass?) without any further adjustment on my part. (My best documents come close, but only because I am become blind to all the teaks inherent in the presentation macros.) I am not aware of any good examples of what I am looking for. Are there? -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] The future redux
On Mon, Feb 24, 2014 at 09:59:43PM -0500, Peter Schaffter wrote: > Mike Bianchi summed up the backward compatibility concern best: > : > "So no, do not break groff by 'modernizing' it." Just to be clear, my opinion is that the _vast_ majority of changes from legacy *roff to groff have been modernizing that preserved backward compatibility, and that is important when documents are viewed as living things that mature and evolve. I cheered when the two-letter limit on names was abolished! Very few things broke and the source-code of my documents where now much easier to understand. I even retrofitted some old ones as they changed. The thing I fear is when .glurp arg1 arg2 changes to .glurp arg2 arg1 , etc. (I cringe when I watch other languages, Ruby comes to mind, make this mistake. Code, written to the spec, that used to work now doesn't?!) As to "good typography", what I value most is that the document still reads _correctly_ and looks OK. I seldom care about how the text layout changes from version to version. (Although I do sometimes obsess over a widow or orphan, or table layout.) > I was really surprised by Mike's comment: > "Done right, a really great macro package would have to clearly > separated parts: presentation and format. ..." I apologize Peter. I have not considered mom in a _long_ time. I'm too comfortable in my mm macro world, but I'm finding mm a bit rickety for new things I want to do. It is time I looked at mom again. Thank you for the long post. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] The future redux
On Wed, Feb 26, 2014 at 02:42:45PM +, Deri James wrote: > : > It may be necessary to alter the man.config command I gave for > other pdf readers. I cannot find man.config or any reference to it in Debian 7.4 (wheezy). 2.6.2 2012-06-18 MAN(1) Only manpath.config . What am I missing? -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] The future redux
On Wed, Feb 26, 2014 at 04:08:45PM +, Deri James wrote:
>>On Wed 26 Feb 2014 10:19:07 Mike Bianchi wrote:
>>> I cannot find  man.config  or any reference to it in Debian 7.4
>>(wheezy).
>It looks like on debian the answer is to create a shell script called
>"mandb_tfmt" to do exactly what you want when man -t is used.
>Unfortunately my only version of debian is on a sheevaplug which is not
>up to running an X server, but the man page says:-
>
>A formatting pipeline is formed from the filters and the primary
>formatter (nroff or [tg]roff with -t) and executed.
It appears that /etc/manpath.config holds the magic configurations.
Witness:
:
# Program definitions. These are commented out by default as the value
# of the definition is already the default. To change: uncomment a
# definition and modify it.
#
#DEFINE pager pager -s
#DEFINE cat cat
#DEFINE tr tr '\255\267\264\327' '\055\157\047\170'
#DEFINE grepgrep
#DEFINE troff groff -mandoc
#DEFINE nroff nroff -mandoc
#DEFINE eqn eqn
#DEFINE neqnneqn
#DEFINE tbl tbl
#DEFINE col col
#DEFINE vgrind vgrind
#DEFINE refer refer
#DEFINE grapgrap
#DEFINE pic pic -S
#
#DEFINE compressor gzip -c7
:
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] Re: Back to the future
On Tue, Mar 04, 2014 at 12:57:20AM -0500, Eric S. Raymond wrote:
> Peter Schaffter :
> :
> > Corollary to acknowledging that groff's primary role is as a
> > typesetting backend is keeping debates about manpages, semantically
> > useful macros, and well-formed input files distinct from discussions
> > about code development. What goes on in macroland should stay
> > in macroland.
>
> Again, I agree. Thus my hygiene proposal; that's how we keep the
> macroland abstractions from being violated (when it's a good idea
> to enforce that, which is admittedly not always).
>>> On Tue, Feb 25, 2014 at 11:06:09AM -0500, Eric S. Raymond wrote:
>>> Now let us imaging adding two primitives to groff:
>>>
>>> 1. Declare hygienic. Takes a request or macro name, sets a 'hygienic'
>>> bit on it.
>>>
>>> 2. Enable hygienic node. After this point, all explicit requests without
>>> their hygienic bit set are disabled and cause a fatal error. They
>>> can only be used within hygienic macro expansions.
>>>
>>> Given this pair of primitives, backward compatibility and the goal of
>>> achieving semantic markup in groff would no longer be in conflict.
>>> Instead, macro packages get to choose where they sit on the
>>> structured-vs.-expressive continuum by what set of requests they
>>> allow.
> > If others on the list are prepared to make--and debate--"big
> > picture" suggestions for a statement of this sort, I will see to
> > the compiling and writing of it.
> All hail the new project leader! :-)
I propose the hygienic feature as a first project after we agree on the mission
statement.
\# declare all groff macros hygienic, default
.hygienic ON GROFFALL
\# declare all groff macros not hygienic
\# excludes .hygienic
.hygienic OFF GROFFALL
\# change given macros hygienic modes
.hygienic { OFF | ON } macroname ...
.macroset macrosetname macroname ... ?
.hygienic { OFF | ON } macrosetname ... ?
\# set hygienic mode
.hygienic { DISABLE | ENABLE }
It would help me stay disciplined in my own macro packages.
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] Back to the future
On Thu, Mar 06, 2014 at 11:54:11AM -0500, Eric S. Raymond wrote: > Ingo Schwarze : > > The classical man(7) language is a purely presentational language > > and contains exactly three semantic macros as exceptions: TH, SH, SS. > > So basically, nothing except titles is semantic in there. > I'm aware that we're stuck with presentation-level markup in man macros. I don't see why we are stuck. If there were macros that supported a semantic representation of the common man page structures they could be added to -man. I imagine: .SYNOPSIS .Commandman .FlagArgOpt C file .FlagArgOpt d .FlagArgOpt D .LongArgOptOpt warnings warnings . . . .Option section .Args page .Command man .FlagArg -k .Option "apropos options" .Argsregexp : .DESCRIPTION .Command man is the system's manual pager. Each .Arg page argument given to .Command man is normally producing (with appropriate bold and italics) SYNOPSIS man [-C file] [-d] [-D] [--warnings[=warnings]] . . . [section] page ... man -k [apropos options] regexp ... . . . DESCRIPTION man is the system's manual pager. Each page argument given to man is normally . . . I dare say most people who write man pages copy one that is close enough to where they think they are going and edit like crazy. (Start from an empty file? I don't think so.) Once there are significant number of man pages in that style, the ecology would slowly change over time. Maybe within my life time. Which is quite a thought. I was in my mid-20s with I first encountered UNIX. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] End of file processing
Peter, I don't understand the instructions, I guess, having never mucked with fonts. I'm guessing I need more preparation than I thought. Can you help? sudo ~/bin/install_font *pfa /usr/local/share/groff/site-font not found; creating. mkdir: cannot create directory `/usr/local/share/groff/site-font': No such file or directory sudo mkdir -p /usr/local/share/groff/site-font sudo ~/bin/install_font *pfa /usr/local/share/groff/site-font/devps not found; creating. /usr/local/share/groff/site-font/devpdf not found; creating. Processing CodabarJK.pfa... Running fontforge... Copyright (c) 2000-2011 by George Williams. Executable based on sources from 23:14 GMT 25-Feb-2011-ML. Library based on sources from 13:48 GMT 22-Feb-2011. Done. Family name (default = Codabar): =>CodabarJK (CodabarJK.pfa) assigned to family 'Codabar'. Enter +STYLE (eg +R, +I, +BD, +BI), or a unique groff name for CodabarJK. Leave blank to set name to 'CodabarJK': =>CodabarJK assigned groff fontname 'CodabarJK'. 'textmap' not found. Aborting. Further investigation shows that by 'textmap' the script means /usr/local/share/groff/1.21/font/devps/generate/textmap What I see is: ls -R /usr/local/share/groff/ /usr/local/share/groff/: site-font /usr/local/share/groff/site-font: devpdf devps /usr/local/share/groff/site-font/devpdf: /usr/local/share/groff/site-font/devps: -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] End of file processing
On Sat, Mar 29, 2014 at 07:10:23PM -0400, Peter Schaffter wrote: > On Sat, Mar 29, 2014, Mike Bianchi wrote: > > Peter, I don't understand the instructions, I guess, having never > > mucked with fonts. I'm guessing I need more preparation than I > > thought. Can you help? > > > >sudo ~/bin/install_font *pfa > > /usr/local/share/groff/site-font not found; creating. > > mkdir: cannot create directory `/usr/local/share/groff/site-font': No such > > file > > or directory > > From the looks of it, you aren't using a locally built groff, > or you passed the configure script > > '--prefix=' > > when you built. > > In the first case, you need to run install-font with the -s flag > (use /usr/share/groff; the default is /usr/local/share/groff). > : Thanks Peter. The lack of -s was the problem. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] Mission statement - final
On Wed, Apr 02, 2014 at 06:38:49PM -0400, Peter Schaffter wrote: > Groff Mission Statement > 2014 I like. And I like the path we took to get here. Congratulations to all involved. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] groff webpage re-design
On Tue, Apr 08, 2014 at 05:19:11PM -0400, Peter Schaffter wrote: > : > Also on the proposed webpage are links to our shiny, new mission > statement in both pdf and html versions. Please take a look at both > and post comments if you have any. Would it make sense to have the mission statement point at the source for the mission statement, as an illustration of how groff turns what you write into what you get? -- Mike Bianchi
[Groff] groff postscript output rotated 90 degrees in for a 4 x 2.5 inch label?
I just don't seem able to get this right.
I want to create a Postscript file with the text turned 90 degrees from
horizontal.
I define
.ll 4.0i
.pl 2.5i
.po 0
I format a simple label that looks just fine in Letter sized displays.
I want to
crop the Postscript to 4 x 2.5 inches
rotate it 90 degrees
Look at it with gv(1) and then send it to my Dymo label printer.
I have the label printer working, so I think this should work:
tmpfile=/tmp/xxx
groff file >${tmpfile}
psnup -w4in -h2.5in -l ${tmpfile} >${tmpfile}2
gv ${tmpfile}2
If I make the 3rd line
psnup -l ${tmpfile} >${tmpfile}2
and I get the label, but not rotated.
I've also tried using
pstops '0L' ${tmpfile} >${tmpfile}2
but again, no output.
Oddly
pstops '0V' ${tmpfile} >${tmpfile}2
produces the expected vertical reflection.
Any suggestions?
Is there a way to do the rotation _within_ groff?
(I know about the pic "aligned" hack,
but that seems to be useful only for simple unformatted text.
I would need to rotate an entire groff diversion.)
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] groff postscript output rotated 90 degrees in for a 4 x 2.5 inch label?
On Sun, Jun 08, 2014 at 08:01:36PM -0400, Mike Bianchi wrote:
> I want to create a Postscript file with the text turned 90 degrees from
> horizontal.
> :
Many thanks to Clarke, Ralph and Ted (and by indirection, Werner) for all the
pointers. My final form was
shell script:
tmpfile=/tmp/$$.$( basename $0 )
trap " rm -f ${tmpfile} " 0
export PRINTER=DYMO_LabelWriter_450_Turbo
# -P argsgo to grops(1)
# -p
# -llandscape
groff -P -p4.i,2.3125i\
-P -l
-M ${HOME}/lib/tmac \
-m PrintLabels_macros \
"$@" >${tmpfile}
gv --media=Dymo ${tmpfile}
dymo.troff:
\# Dymo 30256 LW Large White Shipping Labels
.ll 4.3500i \" 4 inches + 0.35 inch fudge factor!
.pl 2.1625i \" 2 5/16 inches - 0.15 inch fudge factor!
:
The fudge factors where found by painful, incremental experimentation
needed to make a label formated to 4 x 2.3125 inches print properly on
the Dymo printer's 4 x 2.3125 inch labels.
Ever it has been so. Sigh.
Again, many thanks for the pointers and those in the distance past that made
the whole process possible.
--
Mike Bianchi
Re: [Groff] underlining
> ... Would be a good thing but has to have a new name (other than .ul). > Preferable with more than two characters. The .ul macro dates back to nroff which was aimed at impact printers and where underlining was (almost) the only option and the intention was to replace manual typing. My first use of nroff was on daisy wheel printers; we were grateful for .ul . "Backward Compatibility" is simply another way of saying "all bugs are preserved". Define the difference between a Feature and a Bug. 10 points Oh, the memories ... I am pretty sure I once used a specialized teletype that actually supported 2 fonts, using the ShiftIn and ShiftOut ASCII characters. See ascii(7) . During that same era, Bell Labs had special groups of "mathematical typists" who used "mathematical typewriters". I once wrote a Fortran program that drove a pen-plotter to create pages of mathematics very similar to those produced by Mathematics Typing, making it easier to edit them over time. 5 punched cards produced 1 line of output. I wonder if I still have a deck ;) -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] underlining
On Sat, Jul 12, 2014 at 02:21:58PM +0100, Ralph Corderoy wrote: > > Actually, why not? I'd like to argue that request names carry with > > them an "implied contract" as to their function, and "ul" stands for > > underline, so that's what it should be used for. It _does_ stand for "underline", in the original nroff, predating troff. The choice to have it mean italic in troff was so all those man pages and documents would still format, but look "better". Again: "Backward Compatible" translates as "All Bugs Are Preserved". I believe the "implied contract" of groff over the years is that most documents will format as they did way back when they were first written. I vote for .underline (or the like) to exist as a standard groff feature in some macro package(s) or another. -- Mike Bianchi
Re: [Groff] Compression support for files?
On Thu, Jul 17, 2014 at 03:44:31PM +0100, Ralph Corderoy wrote: > : > If you really want programs to handle compressed files then investigate > zlibc instead, an LD_PRELOAD library that intercepts open(2) and > friends. http://www.zlibc.linux.lu/install.html > That keeps the code separate to each program and gives just one thing to > improve. Wow! Now _THAT_ is proof once again of the value of UNIX/LINUX/BSD, etc. and open source. And the wisdom of crowds. If I want many, many programs can now handle compressed files, including groff and friends. Thanks for the pointer, Ralph! -- Mike Bianchi
Re: [Groff] \[-+] not available? why?
On Tue, Jul 29, 2014 at 04:32:21PM +0100, Denis M. Wilson wrote: > Try something like > > .char \[-+] \f[S]\v'.1v'\z+\v'-.25v'\-\v'.25v'\v'-.1v'\f[] > > The spacing needs more fine-tuning, I don't have time at the moment. This seems to work ... .char \[-+] \f[S]\z+\v'-.35v'\-\v'.35v'\f[] \[-+] \[+-] -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] \[-+] not available? why?
On Wed, Jul 30, 2014 at 01:40:55PM +0100, Ted Harding wrote:
> :
> The main difference, which I strongly recommend, is to use
> 'm' rather than 'v' as the scale for the vertical motion.
> The reason is that 1v is one line-space, which can be set
> independently of the current point-size, while 'm' is, in
> effect, the point size, so that the result will scale as
> the point-size changes.
>
> What I had devised (and again some tweaking of the motions
> may be desirable -- it might look better to shift it down
> a bit) is:
>
> .char \[-+] \Z'\fS+\fP'\v'-0.370m'\fS\[mi]\f[]\v'0.370m'
>
> Then, in plain text,
>
> \[-+] \[+-]
>
> will display appropriately. And of course one can also define
> "-+" for the 'eqn' environment (where it will feel most at home
> anyway):
>
> .EQ
> define -+ "\[-+]"
> cos ( A +- B ) ~~=~~
> cos ( A ) cos ( B ) ~ -+ ~ sin ( A ) sin ( B )
> .EN
>
> and, to show how the scaling adapts:
>
> .EQ
> a ~+-~ b ~-+~ c ~ e sup{a~ +-~ b ~-+~ c}
> .EN
>
> This little thing has provoked quite some interest!
This is what I like about this group!
There is such depth of knowledge that we all can draw on.
Is it possible to make .char \[-+] ... something that is part of the
S font by default?
Otherwise we are likely to revisit this in a year or two.
--
Mike Bianchi
Re: [Groff] Reproducible dates in HTML/PDF/PS output files?
On Wed, Aug 27, 2014 at 03:56:24PM +0200, Werner LEMBERG wrote: > ... However, I'm not convinced that I want to > *always* suppress timestamps (and a setting in a user's environment is > more or less permanent). Instead, I prefer good old command line > options to control this behaviour. If time stamps are just notations in the binary that _always_ show up in the same places, it should be very easy to create a map of where they are and ignore them when doing the bit-for-bit compare. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] [Groff & Heirloom] tbl problem with backslashes
On Sun, Aug 31, 2014 at 11:25:28PM -0500, Blake McBride wrote:
> I found that Groff and Heirloom handle backslashes in tables differently.
> I actually think both are wrong, but I am not sure. My input is as
> follows:
>
> .TS
> a a .
> INPUT PRODUCES
> \\
> abc def
> .TE
>
>
>
> I am processing it with tbl & troff but no macro packages. They produce
> different results - both unexpected by me. What I am trying to produce is
> as follows:
>
> INPUTPRODUCES
> \\ \
> abc def
>
>
> (Yes, I am using tabs between the columns on the real input file.)
You've run into what (I think) was first stated as "Kernighan's Lemma"
which went something like:
In troff, the number of / characters necessary to output a single
/ character grows exponentially with macro depth.
This is why the \e escape was created:
... \e represents the current escape character.
To get a backslash glyph, use \(rs or \[rs].
groff(7)
Brian: I hope I represented this accurately. ;)
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] [Groff & Heirloom] tbl problem with backslashes
On Mon, Sep 01, 2014 at 05:07:51PM +0200, Carsten Kunze wrote: > - Original Nachricht > Von: Mike Bianchi > > > In troff, the number of / characters necessary to output a single > > / character grows exponentially with macro depth. > > Ok, but should we consider fields as macros? I had not expcted up > to now that fields reduce \\ to \. And we now have a difference > between groff and other troff variants here. > > So I read your and Ralph's mail as "\\ should not be used to produce > a \ character in the output and so we don't need to fix this feature"? That is my take. \\ yielding \ output is relying on a side-effect of the definition of "escape character" . \e yielding \ relies on the common, but not universal, case where the escape character is has the current value of / . \[rs] is utterly reliable within groff. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[Groff] What is the current state of Unicode support in Groff?
While verifying Kernighan's Lemma with him, Brian mentioned: I used groff about 3-4 years ago for a new book (advt below, in case I haven't already spammed you). It all worked pretty well, though there were a lot of bandaids to handle indexing, contents, PDF, etc. I'm in the early stages of a new one at this point (no details yet, since my co-author has to clear it) and we're thinking about what to use. One big problem with groff is that it doesn't really do Unicode smoothly, though I think this is more a Postscript problem. If I could resolve that, I would likely use groff again. Troff is no walk in the park, but the alternatives are all worse. Any thoughts on that? Would be nice if it worked smoothly. If you look carefully at the tiny amount of Unicode in "D is for Digital", you can see that I had trouble. [Advertisement] Check out "D is for Digital: What a well-informed person ought to know about computers and communications", ... [And a second advertisement] As an experiment, I have also published a Kindle book "Hello, World! Opinion columns from the Daily Princetonian", ... I've not kept up with the current Unicode state of groff. Any enlightenment would be appreciated. Brian is cc'ed to this email, so "Replay All". -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] .mk/.rt not work across a page?
On Thu, Sep 04, 2014 at 03:35:25PM +0100, Anton Shterenlikht wrote: > >Date: Thu, 4 Sep 2014 12:31:09 +0200 (CEST) > >From: Carsten Kunze > >To: groff@gnu.org > > > >You could try > > > >.mk A > > > >and on the next page > > > >.sp |\nA > > > >(have not tested that.) > > In UNIX Text Processing, p. 462, the advice is > > .mk Q > .sp |\nQu > > Neither your form nor theirs (with "u" at the end) work. > I guess this is because this feature is used > to affect vertical position on a single page, > not across pages. > > Anton If you are doing this at the top a page, the "no-space mode" is probably turned on. See .ns and .rs in man 7 groff . In theory, issuing an .rs should make it work, but I find with the mm macros it is not reliable. Rather than figuring out precisely why it doesn't alway work, I just output a \& (Non-printable, zero-width glyph) which seems to reliably cancel the no-space mode and then it does work. E.g. \& .nr Q 0.5i .sp |\n[Q]u Hi there (I put all my register, string and character references inside [ ] so they stand out. Just a matter of style.) Give it a try. I used: groff -mm /tmp/i | gv - for these experiments. >> Gurus of groff internals <<look at this! Using MM macros. \& .nr Q \n[.ns] .sp |0.5i Q = \n[Q] prints Q = 1 That says to me "no-space mode is ON". Yes? Now .rs .nr Q \n[.ns] .sp |0.5i Q = \n[Q] Prints Q = 0 1.0 inch down from the top edge, which is where MM normally starts normal text. That says to me "no-space mode is OFF", so position of the Q = [01] text is opposite of what I expect. Am I confused about something? Oddly, this works as expected. .br .rs .nr Q \n[.ns] .sp |0.5i Q = \n[Q] Prints Q = 0 0.5 inch down from the top edge. So there is some odd relationship between no-space and whether the line buffer has been flushed? What is going on? -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] .mk/.rt not work across a page?
On Fri, Sep 05, 2014 at 08:18:55PM +, Bjarni Ingi Gislason wrote: > On Thu, Sep 04, 2014 at 11:25:22AM -0400, Mike Bianchi wrote: > > [...] > > > > Oddly, this works as expected. > > .br > > .rs > > .nr Q \n[.ns] > > .sp |0.5i > > Q = \n[Q] > > > > Prints > > Q = 0 > > 0.5 inch down from the top edge. > > > > > > So there is some odd relationship between no-space and whether the line > > buffer > > has been flushed? > > > > What is going on? > > You are not informed. Read at least the first paragraph of chapter > "3.� Page control" in the troff reference at "cm.bell-labs.com" (ftp or > http), file "/cm/cs/cstr/54.ps.gz". Thanks! Yep. There it is, in black and white. The good news is the behavior observed _is_ documented. I can even imagine why that is the proper behavior. I've been using troff since the mid 1970s, but I don't know if I would have ever found that if I were looking for it. So tell me Bjarni, how did you _know_ that was there? -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[Groff] Missing text in PDF with Mom
Hi- So it is my first ever attempt at using Groff. I wrote the small text file below in Mom, and processed it into pdf using pdfmom 1.22.2, on a Fedora 20 box. Then I moved the pdf to a Windows machine. The generated pdf file doesn't have any paragraphs when viewed by Adobe Reader XI Version 11.00.08 on Windows 8 64-bit. It is nothing but title text. But if I convert the resultant pdf to a PNG using pdftopng 3.04 on Fedora, the title text and the paragraph text appears. I'm guessing that I was supposed to embed a font, maybe, in the PDF file itself somehow. Any ideas? The groff file and resultant PDF are attached. -Mike Gran.TITLE "Using Groff/Mom like Markdown" .PRINTSTYLE TYPESET .START .PP Paragraphs in Mom are just one or more lines of consecutive text preceeded by the '\.PP' macro. .PP If you need to have text in your paragraph that happens to be a macro, like '\.PP', you'll need to escape the period by preceding it with a backslash, like so '\\\.PP' tmp.pdf Description: Adobe PDF document
Re: [Groff] Missing text in PDF with Mom
> On Saturday, September 6, 2014 2:16 AM, "ted.hard...@wlandres.net" > wrote: > > On 06-Sep-2014 08:05:46 Ralph Corderoy wrote: >> Hi Mike, >> >>> So it is my first ever attempt at using Groff. >> >> Welcome! >> >>> The generated pdf file doesn't have any paragraphs when viewed >>> by Adobe Reader XI Version 11.00.08 on Windows 8 64-bit. It is >>> nothing but title text. >> >> ...and the "- 1 -" page number at the bottom? >> >>> But if I convert the resultant pdf to a PNG using pdftopng 3.04 on >>> Fedora, the title text and the paragraph text appears. >> >> That's odd, because it doesn't appear for me; I get the same as > viewing >> the PDF. And if I look at the PDF's contents, I don't think the > text is >> there. The qdf(1) program can make the PDF more readable. Doh! I figured it out. The problem was that my http server cache instance was caching a previous version of the file, so when I looked at it online, I was getting a previous attempt. Can now confirm that it works both in Adobe Reader 11.0.08 and the default "Reader" app on Windows 8.1 Metro. Thanks, Mike
Re: [Groff] new automake system
> On 10/03/2014 05:37 PM, Bertrand Garrigues wrote: > > ... I've just noticed that a lot of people on the list > > use 2 spaces after a full stop. What is the main reason ? ... On Fri, Oct 03, 2014 at 06:54:51PM -0600, Clarke Echols wrote: > : > I find it easier to read because I read fast. I often copy text off of web pages and documents and run it through groff to get the double-space-after-sentence format and "reasonable" line lengths. I find it helps my reading and comprehension. -- Mike Bianchi
Re: [Groff] No white space between . and PS?
On Fri, Oct 31, 2014 at 07:13:06PM +0100, Carsten Kunze wrote: > Mike Bianchi > > It should be allowed, > > but the evidence is that pic does not see .PS and .PE as macros. > > Yes, but this is somehow an imcomplete implementation. ... For what it is worth, tbl and eqn suffer from the same malady. Sounds like a worthwhile enhancement, but not strictly a "bug" requiring immediate correction. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] [Heirloom] Double word space after :
On Thu, Nov 13, 2014 at 08:17:50PM -0600, Dave Kemper wrote: > On 11/12/14, Carsten Kunze wrote: > > by default Heirloom troff inserts a double word space if a line ends with > > ":". Is this correct US English typography? > > Most modern US typography uses the same amount of space for everything > on the line: between sentences, between words, and after any > punctuation that requires a following space. (Here, "modern" refers > to the past 50 years or so; see > http://en.wikipedia.org/wiki/History_of_sentence_spacing#Movement_to_single_sentence_spacing) > > So the default groff behavior of adding additional space between > sentences also does not follow today's typical US typography. You > would have to specify ".ss 12 0" to achieve US convention. It seems ease of reading or better comprehension (which are the reasons I prefer extra space after sentences, etc.) have nothing to do with "the rules." Sigh. -- Mike Bianchi
Re: [Groff] [Heirloom] Double word space after :
On Fri, Nov 14, 2014 at 01:53:20PM -0500, Peter Schaffter wrote: > > ... ease of reading or better comprehension ... > >have nothing to do with "the rules." Sigh. > : > The matter gets more complicated when you have sentences that end > with "r." or "y.". > : > ... I've never figured out is whether it's possible to set up kern pairs in > groff font files that have "space" as the first element of the pair. ... As someone who never wanders beyond Times, Courier, Helvetica and DingBats, it seems to me that the kerning and spaces-after-whatever rules should be an _adjustable_ intrinsic aspect of the individual fonts, not rules built into the processor (groff) or even the macro packages. "Adjustable" because I have my own ideas of what looks good, especially when writing technical documents vs. when writing literature. But I dream. Groff is what it is because there exist works which read as well as they do because groff is faithful to its predecessors, warts and all, and does what it does better than the alternatives, at least in the eyes and minds of its admirers. For now, I pretty much love it as it is and accept (and pride myself in sometimes mastering) its idiosyncrasies. Someday there may be a successor typesetting system where the writer thinks of the text in terms of _only_ I'm writing, and the typesetting _only_ in terms of clear rules that make it all look pretty and correct. Again, I dream. -- Mike Bianchi
Re: [Groff] condition: OR of two string comparisons
On Thu, Nov 20, 2014 at 07:31:23PM +0100, Tadziu Hoffmann wrote: > I say we shouldn't change the interpretation of > numeric expressions. > : > 3. It's not necessary, because order of operations > can always be specified by using parentheses. Maybe it needs to be said that "good practice" implies that _all_ arithmetic expressions should be fully parenthesized so there is no chance for misinterpretation. ... order of operations _should_ always be specified by using parentheses. I'm starting to do that in my code because if I've been reading code in one language for too long I forget and start misinterpreting code in other languages. It helps me make fewer mistakes and documents what I meant. -- Mike Bianchi
Re: [Groff] Strange error messages from Groff 1.22.3
On Fri, Nov 21, 2014 at 01:24:36PM +, Ralph Corderoy wrote: > : > > Indeed, this is true for (almost) all groff header files. For some > > reason, Clark decided to code it that way, not providing guards > > against loading header files multiple times. I haven't changed that. > > Gets my vote. :-) It's a Bell Labs style of programming seen widely in > Plan 9. Rob Pike has also written about it since the 1980s. Header > files should not be #include'd multiple times; nor should they #include > others. They should state their needs and be #include'd once in the > C(++) file, in an appropriate order. Guards are verboten. Rant: Sounds to me like blaming the victim. A simple #include_once directive in the preprocessor would fix the multiple include problem. > http://talks.golang.org/2012/splash.article Go at Google: Language Design in the Service of Software Engineering I found that Go language article by Pike worth reading. Now it is a simple matter of translating Groff into Go. ;) -- Mike Bianchi
Re: [Groff] conditionals inside a table?
The issue is that tbl processes the entire file before groff sees it. The data follow is typically tbl From tbl(1) ... w,WMinimal column width value. Must be followed either by a troff(1) width expression in parentheses or a unitless integer. If no unit is given, en units are used. Also used as the default line length for included text blocks. If used multiple times to specify the width for a particular column, the last entry takes effect. On Thu, Dec 04, 2014 at 07:57:50AM -0800, Anton Shterenlikht wrote: > I want to make a document that can give good > ascii and Postscript results. I found that I need > to adjust the formating of tables. I'm trying to > to this with .ie/.el like this: > >10 .TS H >11 expand,center; >12 .ie t lw(0.5i) lw(0.01i) lw(0.5i) lw(2.5i) lw(1.4i). >13 .el lw(1i) lw(0.2i) lw(1i) lw(5i) lw(3i). > > However, it seems tbl doesn't understand this: > > tbl:wish.1:12: `.' not last character on line > tbl:wish.1:12: giving up on this table > > Please advise > > Thanks > > Anton > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [Groff] conditionals inside a table?
u stands for "basic unit" ...
From https://www.gnu.org/software/groff/manual/html_node/Measurements.html
gtroff (like many other programs) requires numeric parameters to
specify various measurements. Most numeric parameters9 may have a
measurement unit attached. These units are specified as a single
character that immediately follows the number or expression. Each of
these units are understood, by gtroff, to be a multiple of its basic
unit. So, whenever a different measurement unit is specified gtroff
converts this into its basic units. This basic unit, represented by a
aCu', is a device dependent measurement, which is quite small, ranging
from 1/75th to 1/72000th of an inch. The values may be given as
fractional numbers; however, fractional basic units are always rounded
to integers.
:
((the available units explained))
On Fri, Dec 05, 2014 at 11:40:33AM +, Anton Shterenlikht wrote:
> Thank you, that's what I was looking for.
> The only thing I don't understand is
> what is "u" in
>
> lw(\n[w1]u)
>
> tbl says:
>
>u,UMove the corresponding column up one half-line.
>
> which I don't need, but if I remove "u",
> the formatting becomes completely broken.
>
> In my case I get good results with:
>
> .ie n \{\
> . nr LL 12.5i
> . nr c1 1i
> . nr c2 0.2i
> . nr c3 1i
> . nr c4 4i
> . nr c5 3i\}
> .el \{\
> . nr PS 9
> . nr c1 0.5i
> . nr c2 0.01i
> . nr c3 0.5i
> . nr c4 2.5i
> . nr c5 1.5i\}
> .TS H
> expand,center;
> lw(\n[c1]u) lw(\n[c2]u) lw(\n[c3]u) lw(\n[c4]u) lw(\n[c5]u).
>
> Thanks
>
> Anton
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [Groff] conditionals inside a table?
On Fri, Dec 05, 2014 at 03:06:08PM +, Ralph Corderoy wrote: > > Is this included into any of the man pages. I tried to find, but > > couldn't, but I haven't searched all of groff man pages. > > I don't think all of groff's GNU info information is duplicated in the > man pages. Man pages were never intended to replace all documentation. But they do serve as an excellent kicking off point. I knew the answer, but steps to look for supporting documentation were: man 7 groff search for the single letter u : /\ found u Basic unit for actual output device searched for variations of the word unit : /\https://www.gnu.org/software/groff/manual/.../Measurements.html GNU Most numeric parameters may have a measurement unit attached. ... This basic unit, represented by a ' u ', is a device dependent measurement, which is quite small, ranging from 1/75th to 1/72000th of an ... Ens. In groff , this is half of an em. That's what I pointed you to which happens to be contained in info groff > groff.txt which is what Ralph suggested. Many roads lead to ... -- Mike Bianchi
Re: [Groff] groff_char(7): Combination of characters vs. single unicode character
On Tue, Dec 16, 2014 at 04:33:55AM +0100, Werner LEMBERG wrote: > > > Do i understand correctly that the Info manual calls u2260 invalid > > as a glyph name, but that, all the same, \[u2260] produces the > > desired output? > > : > > Similar to TeX, the distinction between characters, entities, and > glyph names is unclear, unfortunately. > : > So if you enter \[!=], groff converts `!=' to `u2260' (step 1), then > to `u003D_0338' (step 2). > > For the `utf8' output device, `u003D_0338' is found in > `font/devutf8/R' (step a), returning character code U+2260 as the > final output. > > For the `ps' output device, `u003D_0338' is not found, thus it gets > converted back to `!=' (step b), which is eventually found in file > `font/devps/S', returning PostScript glyph name `notequal'. > > > I hope this helps. Patches to improve the docs are really welcome :-) Also: Could a trace option be added so the path of \[u2260] interpretation could be seen? May a tool that shows the choices when there are "equivalent" interpretations? -- Mike Bianchi
Re: [Groff] Proper Small Caps.
(Commentary) http://xkcd.com/1167/ -- Mike Bianchi
Re: [Groff] Building a troff parser
On Tue, Mar 03, 2015 at 01:00:35AM -0500, Eric Andrew Lewis wrote: > In short, I'd like to make a program that does this: > > $ explain "rm -rf *" > rm -rf * > └── rm remove files or directories > ├── -r remove directories and their contents recursively > ├── -f ignore nonexistent files, never prompt > └── *Remove (unlink) files matching this text pattern. Are you aware of rm --help ? The --help argument is very common in commands. -- Mike Bianchi
[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
