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: 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: 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?
> 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?
> 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
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: 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
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
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: z/OS porting issues, UTF-8 support, and the groff man(1) page
On Fri, Mar 31, 2023 at 2:55 PM G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > [adding Dave to CC; seek your name below for my magical summons] > > At 2023-03-31T13:05:09-0700, Mike Fulton wrote: > > On Fri, Mar 31, 2023 at 8:57 AM G. Branden Robinson < > > > As a groff developer, I'm interested in minimizing the number of > > > patches you have to carry "downstream" to support groff. > > > > > Definitely - I have not yet been able to build with the 'git' dev > > build but instead have been building from the tarball. I was planning > > to work to upstream changes once I had the 'git' build working (we are > > getting there now that we have more tools in place - it's a circuitous > > process!) > > When you're ready to make that shift, be sure to read the "INSTALL.REPO" > file in the root of the repository or distribution archive. > Bruno Haible has provided an enhancement to gnu libiconv that now 'falls back' to < and > from the mathematical angled brackets. The net of that change is that 'man groff' now works for me, which is great! I _do_ want to tackle the other things that are brought up here as well (in particular getting a proper fix for my sed hack) and I want to figure out how to build man so that I can get 'true' UTF-8 support in my man pages. I am going to take a crack at getting the 'git build' going. I will reach out once I have made progress with that. Hopefully it won't be too hard - depends on how many other tools are required for bootstrap/configure. It sounds like that may also help with my 'sed' problems (see below). > > > > I assume the change here: > > > > > > > https://github.com/ZOSOpenTools/groffport/blob/main/patches/makevarescape.sed.patch > > > > > > is due to a limitation of the system's sed(1)? > > > > > Yes - that is the change. No - it's not because of sed. We have ported > > sed and could rely on it as a dependency. The issue we hit is a bit > > ugly. Because z/OS is a 'multi-tenant' operating system, we want > > people to be able to install into a particular location of their > > choice (either as developer _or_ as a consumer of the binary). > > ...without a recompile, I assume? > Correct. Without a recompile. > > > To make that work, we run a post-process on the files when someone > > downloads them to change the install 'root' location from where we > > built the code to the target location they want to install into. It's > > ugly and we end up doing a find across files to do this trick. If that > > 'sed' change is in there, we end up 'missing' some particular updates > > because the string gets changed on us for the 'root' and so I took out > > that sed update (a complete hack that I need to do better). > > Ah. Hmm. I can think of a better way, although it won't (completely) > help groff 1.22.4. > > For groff 1.23, I revised our man pages to be much more careful about > documenting full file specifications to groff-installed files and to > compute their values based on the build's configuration > parameters--stuff like "./configure --prefix=/home/foobar". > I will check this out - maybe the problem 'goes away' in 1.23. > > Something I think you could do starting with the 1.23.0 release > candidates--if you keep the groff build tree around somewhere--is to > perform your sed operation on all the *.man files in the source tree > (and build tree, if it is separate), sniping any of the existing fodder > for sed replacement that you find appropriate. > > To be concrete, I'm talking about this stuff: > > > https://git.savannah.gnu.org/cgit/groff.git/tree/Makefile.am?id=e3824d611be904bad22176f4f4eb282a5352509d#n864 > > So your multi-tenancy assistance script could do something like this: > > MANS=$(find groff-source-dir groff-build-dir -name "*.man") > sed -i 's#@BINDIR@#'"$TENANT_HOME"'/bin#g' $MANS > cd groff-build-dir > make man-all # You can thank Keith Marshall for suggesting this. > I will try the 'git build' first and see what that looks like. > > ...and as Emeril Lagasse would say, "bam!" The pages will be > regenerated with correct file specifications with no cumbersome > workarounds. And thanks to makevarescape.sed, if the file names wind up > being long, they'll break in pleasant locations and won't be hyphenated. > > Or so I predict, not having actually done this concretely. > > If you're wondering why yo
Re: z/OS porting issues, UTF-8 support, and the groff man(1) page
On Fri, Mar 31, 2023 at 8:57 AM G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > [let me know if you're subscribed to the list or if you'd prefer not to > be CCed] > > [also, if you want to break any of the several subjects arising in this > message into a separate thread, please feel free] > > Hi Mike, > > At 2023-03-31T07:29:16-0700, Mike Fulton wrote: > > Over the last year, we have been working hard in the z/OS Open Tools > > community (https://zosopentools.github.io/meta/#/) to not only port > > the fundamental tools to z/OS, but also to do it completely in the > > open. > > This is good news! Knowing that you're a software developer might also > make communications easier. :) > > > We create one 'port' repo for each Open Source package and the repo > > contains information on compiler options, dependencies, and so forth > > so that anyone can (relatively easily) build the software. > > > We also have a special repo (meta) that has a rudimentary package > > manager and build tool that we use (e.g. _zopen install_ to install > > binaries, _zopen build_ to build from source, etc.). > > Much as with GNU/Linux distributions; this is a pleasure to hear. > > As a groff developer, I'm interested in minimizing the number of patches > you have to carry "downstream" to support groff. > Definitely - I have not yet been able to build with the 'git' dev build but instead have been building from the tarball. I was planning to work to upstream changes once I had the 'git' build working (we are getting there now that we have more tools in place - it's a circuitous process!) > > I assume the change here: > > > https://github.com/ZOSOpenTools/groffport/blob/main/patches/makevarescape.sed.patch > > is due to a limitation of the system's sed(1)? > Yes - that is the change. No - it's not because of sed. We have ported sed and could rely on it as a dependency. The issue we hit is a bit ugly. Because z/OS is a 'multi-tenant' operating system, we want people to be able to install into a particular location of their choice (either as developer _or_ as a consumer of the binary). To make that work, we run a post-process on the files when someone downloads them to change the install 'root' location from where we built the code to the target location they want to install into. It's ugly and we end up doing a find across files to do this trick. If that 'sed' change is in there, we end up 'missing' some particular updates because the string gets changed on us for the 'root' and so I took out that sed update (a complete hack that I need to do better). > > If the problem is the '\+' part of the pattern, I see that POSIX says > that the interpretation of that is "implementation-defined", though the > latest draft of Issue 8 (just out in the past 24 hours or so) says that > "a future version of this standard may require "\?", "\+", and "\|" to > behave as described for the ERE special characters '?', '+', and '|', > respectively." (IEEE P1003.1™-202x/D3, March 2023, p. 181). > > A workaround would be: > > -s|[^ ]/\+|&:|g > +s|[^ ]//*|&:|g > > If you also want to steal a slight improvement from groff 1.23, you can > do this instead: > > -s|[^ ]/\+|&:|g > +s|[^ ]//*|&:%|g > > > We have indeed moved to a 'UTF-8 first' model, which for the most part > > is a 'ISO8859-1 first' model > > Interestingly, this meshes closely with groff's assumptions. Due to its > chronological origins ca. 1990, it does not accept UTF-8 input, but it > aware of UTF-8 and can produce it as output. The formatter, troff(1), > accepts ISO Latin-1 input, except on systems where the C preprocessor > macro "IS_EBCDIC_HOST" evaluates true; it then assumes that its input is > encoded using code page 1047. > >From my perspective, we can drop support for 1047 altogether. However, I don't know if someone else has done their own 'separate' port. I haven't seen it if there is one. Correct. I don't set that symbol. > > I reckon you've already dealt with this if necessary, and ensured that > your groff 1.22.4 build does not define that symbol. > > Is code page 1047 deprecated or obsolescent on z/OS? If groff dropped > support for it, do you suspect any z/OS users would be inconvenienced? > I would say neither. An application can choose whether it wants to work in UTF-8/ASCII or whether it wants to work in EBCDIC (or both if it's careful). I wrote a blog on this awhile bac
Re: z/OS porting issues, UTF-8 support, and the groff man(1) page
Hi I think I should probably respond in the channel so the other folks in the z/OS Open Tools community can see. I think I may have botched this a little. Do you typically respond through email or do you use the web interface? I'm probably not doing this quite right on my end... I am not subscribed yet but I can - is that a better way to respond? thanks, mike On Fri, Mar 31, 2023 at 8:57 AM G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > [let me know if you're subscribed to the list or if you'd prefer not to > be CCed] > > [also, if you want to break any of the several subjects arising in this > message into a separate thread, please feel free] > > Hi Mike, > > At 2023-03-31T07:29:16-0700, Mike Fulton wrote: > > Over the last year, we have been working hard in the z/OS Open Tools > > community (https://zosopentools.github.io/meta/#/) to not only port > > the fundamental tools to z/OS, but also to do it completely in the > > open. > > This is good news! Knowing that you're a software developer might also > make communications easier. :) > > > We create one 'port' repo for each Open Source package and the repo > > contains information on compiler options, dependencies, and so forth > > so that anyone can (relatively easily) build the software. > > > We also have a special repo (meta) that has a rudimentary package > > manager and build tool that we use (e.g. _zopen install_ to install > > binaries, _zopen build_ to build from source, etc.). > > Much as with GNU/Linux distributions; this is a pleasure to hear. > > As a groff developer, I'm interested in minimizing the number of patches > you have to carry "downstream" to support groff. > > I assume the change here: > > > https://github.com/ZOSOpenTools/groffport/blob/main/patches/makevarescape.sed.patch > > is due to a limitation of the system's sed(1)? > > If the problem is the '\+' part of the pattern, I see that POSIX says > that the interpretation of that is "implementation-defined", though the > latest draft of Issue 8 (just out in the past 24 hours or so) says that > "a future version of this standard may require "\?", "\+", and "\|" to > behave as described for the ERE special characters '?', '+', and '|', > respectively." (IEEE P1003.1™-202x/D3, March 2023, p. 181). > > A workaround would be: > > -s|[^ ]/\+|&:|g > +s|[^ ]//*|&:|g > > If you also want to steal a slight improvement from groff 1.23, you can > do this instead: > > -s|[^ ]/\+|&:|g > +s|[^ ]//*|&:%|g > > > We have indeed moved to a 'UTF-8 first' model, which for the most part > > is a 'ISO8859-1 first' model > > Interestingly, this meshes closely with groff's assumptions. Due to its > chronological origins ca. 1990, it does not accept UTF-8 input, but it > aware of UTF-8 and can produce it as output. The formatter, troff(1), > accepts ISO Latin-1 input, except on systems where the C preprocessor > macro "IS_EBCDIC_HOST" evaluates true; it then assumes that its input is > encoded using code page 1047. > > I reckon you've already dealt with this if necessary, and ensured that > your groff 1.22.4 build does not define that symbol. > > Is code page 1047 deprecated or obsolescent on z/OS? If groff dropped > support for it, do you suspect any z/OS users would be inconvenienced? > > > and we have a special OS library that takes care of edge case > > conversions to EBCDIC (and provides a couple functions that are > > missing). This is also Open Source (zoslib). > > This really good stuff to hear about; thanks for bringing this > initiative to my attention. > > > We have about 80 packages we are porting / have ported. Some are very > > far along like gnu make and Perl with many fixes upstreamed. Some are > > just barely building - htop is probably a good example of one we have > > just started on. > > I'm glad groff is a member of the first 100! :D > > > I am also not sure if we want to work in UTF-8 or in ISO-8859-1. My > > goal would be UTF-8 across the board, but I expect there are things we > > still need to fix to get there. Our vim port seems to work well with > > UTF-8 but I'll be honest that the testing of that is sparse still. > > My suggestion would be to back the UTF-8 horse. groff already has > machinery in place for accommodating input in UTF-8 via the preconv(1) > preprocessor. > > If there is no longer an audience for code page 1047, several aspects of > groff could be simplified,
Re: groff man(1) page
Hi Thank you for the detailed response! Over the last year, we have been working hard in the z/OS Open Tools community (https://zosopentools.github.io/meta/#/) to not only port the fundamental tools to z/OS, but also to do it completely in the open. We create one 'port' repo for each Open Source package and the repo contains information on compiler options, dependencies, and so forth so that anyone can (relatively easily) build the software. We also have a special repo (meta) that has a rudimentary package manager and build tool that we use (e.g. _zopen install_ to install binaries, _zopen build_ to build from source, etc.). We have indeed moved to a 'UTF-8 first' model, which for the most part is a 'ISO8859-1 first' model and we have a special OS library that takes care of edge case conversions to EBCDIC (and provides a couple functions that are missing). This is also Open Source (zoslib). We have about 80 packages we are porting / have ported. Some are very far along like gnu make and Perl with many fixes upstreamed. Some are just barely building - htop is probably a good example of one we have just started on. I am also not sure if we want to work in UTF-8 or in ISO-8859-1. My goal would be UTF-8 across the board, but I expect there are things we still need to fix to get there. Our vim port seems to work well with UTF-8 but I'll be honest that the testing of that is sparse still. With all that background, I'm wondering if 'both' is the right answer? Would others also find it valuable to be able to have the mathematical angle brackets in UTF-8 be transliterated to angle brackets in ISO8859-1? If so, perhaps a 'starter fix' would be if I worked with the libiconv folks to see if that can be added (I opened a similar question in the libiconv channel since honestly I'm not sure the best way to fix this). In parallel, I think I need to understand how I could change the way I build man so that it operates in UTF-8 mode. Thanks, Mike On Fri, Mar 31, 2023 at 6:55 AM G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > [redirecting to groff@gnu discussion list] > > Hi Mike, > > At 2023-03-30T20:51:06-0700, Mike Fulton wrote: > > When I perform 'man groff', I am getting a failure when iconv converts > > from UTF-8 to ISO8859-1 on the groff 1.22.4 17 December 2018 built > > tarball. The angle brackets from the .UR and .UE entries do not > > convert properly (they show up as spaces and I see a failure after > > quitting 'man') > > > > I have reduced this down to the angled brackets being generated in UTF-8 > > that can't be converted to ISO8859-1, in particular for the text: > > > > ``` > > GNU <http://www.gnu.org> > > ``` > > > > which comes from: > > > > ``` > > > > system within the free software collection > > .UR http://\:www.gnu.org > > GNU > > .UE . > > > > ``` > > > > The text in the intermediate UTF-8 file has UTF-8 angle bracket > > characters. > > > > When I manually try to do translation of the intermediate UTF-8 file, > > I can confirm that iconv fails on the UTF-8 open angled bracket. > > > > Unfortunately the latest dev code seems to have removed the .UR and > > .UE reference so I can't show the problem in the dev line - so I'm > > curious if this was a bug or just a code change? > > > > I am seeing this failure on z/OS. When I try to run on the Mac via > > brew install, it works fine but it is a slightly newer time stamp of > > man page (23 December 2018). > > > > Apologies if this was already asked - I didn't see it when I searched > > for man page issues. > > I in turn must apologize because I have a variety of independent > observations to share. > > There have been significant changes to the groff man(7) package in > groff's Git repository since 1.22.4 was released. Since the groff(1) > man page is written using the man(7) macro package, changes to the > package impact the rendering of document, just as changes to the > document itself can. > > We are currently attempting to finalize groff 1.23.0 for release; the > latest release candidate, 1.23.0.rc3, was tagged a little over a month > ago. You can obtain it from the alpha.gnu.org site. > > https://alpha.gnu.org/gnu/groff/ > > z/OS is one of the environments I'm intensely curious to hear feedback > about; we don't often hear from z/OS users on the groff development > list, and I am curious about many aspects of current character encoding > support on that operating system. There may be claims about code page > 1047 in groff's documentation that are outdated and require correctio
Question about makevarescape.sed in groff-1.22.4 tarball
Hello, The last line of the makevarescape.sed is: ``` s|[^ ]/\+|&:|g ``` I do not understand why it is making the change it is, but if I do ``` ./configure --prefix=/Users/fult...@ca.ibm.com/Documents/Development/mine<mailto:--prefix=/Users/fult...@ca.ibm.com/Documents/Development/mine> ``` On my Mac, or a similar type of line under z/OS, then the man pages seem to have strange escape sequences added to them. For example, on my Mac, this results in the line: ``` .I /Users/fult...@ca.ibm.com/Documents/Development/mine/share/groff/1.22.4/tmac/\:tty\-char.tmac<mailto:/Users/fult...@ca.ibm.com/Documents/Development/mine/share/groff/1.22.4/tmac/\:tty\-char.tmac> ``` Being generated in the ./src/roff/nroff/nroff.1 file Thanks, Mike
Question about makevarescape.sed in groff-1.22.4 tarball
Hello, The last line of the makevarescape.sed is: ``` s|[^ ]/\+|&:|g ``` I do not understand why it is making the change it is, but if I do ``` ./configure --prefix=/Users/fult...@ca.ibm.com/Documents/Development/mine<mailto:--prefix=/Users/fult...@ca.ibm.com/Documents/Development/mine> ``` On my Mac, or a similar type of line under z/OS, then the man pages seem to have strange escape sequences added to them. For example, on my Mac, this results in the line: ``` .I /Users/fult...@ca.ibm.com/Documents/Development/mine/share/groff/1.22.4/tmac/\:tty\-char.tmac<mailto:/Users/fult...@ca.ibm.com/Documents/Development/mine/share/groff/1.22.4/tmac/\:tty\-char.tmac> ``` Being generated in the ./src/roff/nroff/nroff.1 file Thanks, Mike Thanks, Mike
Re: [groff] 27/33: eqn(1): Fix content and style nits.
> It may be, but I don't think that outweighs users knowing to search for
> ‘bugs’ when they want to see if the man page has that section on
> encountering odd behaviour.
Historically, BUGS were there to acknowledge actual failures that had not yet
been addressed. Witneess:
http://man.cat-v.org/unix-6th/1/diff
I agree that a LIMITATION is not a BUG, but sometimes a BUG is more severe than
an LIMITATION. If so, then it belongs in the man page.
Mike Bianchi
On Mon, Oct 24, 2022 at 10:18:37AM +0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > I've introduced or retained "Limitations" (sub)sections in several
> > groff man pages; often I find it a better fit for discussion of issues
> > than the historically well-attested "Bugs". Against Ingo's advice I
> > tend not to use that section title. We have a bug tracker for bugs;
> > as far as I know, Room 1127 in Murray Hill didn't. "Limitations"
> > seems like a better characterization of features
>
> It may be, but I don't think that outweighs users knowing to search for
> ‘bugs’ when they want to see if the man page has that section on
> encountering odd behaviour.
>
> --
> Cheers, Ralph.
--
Mike Bianchi
Coffee with Brian Kernighan - Computerphile
I often enjoy listening the Brian Kernighan reminisce and foretell. Witness Coffee with Brian Kernighan - Computerphile https://youtu.be/GNyQxXw_oMQ This 28 minute conversation between Professor Brailsford and Brian Kernighan begins with stories about awk(1). Eventually they start to talk about text processing and the question of how the next AWK book will be written. Naturally troff(1) and groff(1) come up. That part of the conversation starts here: https://youtu.be/GNyQxXw_oMQ?t=1312 -- Mike Bianchi
Re: Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash
I come into this very late and without having studied the on-going discussion.
For this I apologize.
> However, since many manual pages in existence are incorrect, and they
> use '-' >>> when they should use '\-' <<< ...
Let me take exception to the claim that '-' should be '\-' .
In manual pages of UNIX/Linux commands, system calls, libraries, etc. all the
examples are for strings and negative numbers expressed in ASCII characters.
man(1)
execve(2)
fileno(3)
:
To my mind the correct solution to the '-' controversy is to format
everything at is an ASCII expression in an ASCII font which has no
concept of '\-' .
((I come from the days when all UNIX documentation was formated using nroff.))
Mike Bianchi
On Sun, Jul 31, 2022 at 02:04:23PM +0200, Alejandro Colomar (man-pages) wrote:
> Hi Baptiste,
>
> On 7/31/22 13:49, Baptiste Beauplat wrote:
> > Hi Alejandro,
> >
> > On 2022/07/31 12:35 PM, Alejandro Colomar wrote:
> >> The template page 'manpage.1.ex' uses '-' instead of '\-' for a
> >> dash that should be a Latin minus sign (as it's in the context of
> >> command options). Using '-' would produce a hyphen, which if
> >> copy&pasted, wouldn't be interpreted correctly by a command.
> >>
> >> The offending line in the file is 41:
> >>
> >> options starting with two dashes ('-')
> >
> > When I run the following command on the manpage :
> >
> > man ./manpage.1.ex | xxd
> >
> > The resulting text from the dash line 41 is converted to the correct 2d
> > minus ascii char.
> >
> > The same is true for the two examples following that text, which are
> > correctly shown as \-\- in the source.
> >
> > I am missing something? Or maybe the fact that this text is in a .SH
> > section make it work correctly?
>
> Upstream groff(1) renders '-' and '\-' differently, as they should.
> However, since many manual pages in existence are incorrect, and they
> use '-' when they should use '\-', Debian modifies the behavior by
> downgrading hyphens into Latin minus sign.
>
> Let's fix the page in the hope that Debian can some day remove that
> workaround.
>
> See the relevant part of :
>
> . \" Debian: Strictly, "-" is a hyphen while "\-" is a minus sign, and the
> . \" former may not always be rendered in the form expected for things like
> . \" command-line options. Uncomment this if you want to make sure that
> . \" manual pages you're writing are clear of this problem.
> . if '\*[.T]'utf8' \
> .char - \[hy]
>
> Cheers,
>
> Alex
>
> --
> Alejandro Colomar
> Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/
Re: Typesetting Mathematics by Kernighan and Cherry, retypeset in PDF
> Thanks to some feedback in private email from Deri James, I'm pleased to > make available a PDF version of the re-typeset "Typesetting Mathematics > - User's Guide (Second Edition)" by Kernighan and Cherry. Many thanks! Maybe we should grant advanced degrees in the domains of UNIX Archeology and Software Preservation. -- Mike Bianchi mbian...@foveal.com
Re: Parallel Typesetting
On Thu, May 26, 2022 at 03:54:45PM -0400, Hendursaga wrote: > > May I suggest formatting side-by-wide text on a single page using tbl(1) . > > > > This will get you the side by side paragraphs (or whatever lumping you > > want) automagically with only complete lumps on each page. > > Thanks for the quick response! > > I'm not sure how "rigid" these tables would be, even if on one page > at a time. I'm hoping the paragraphs of each language would be of > comparable length in general, but I doubt that. > > ~ Hendursaga > I'm not sure how "rigid" these tables would be, ... I think my rough PDF sample shows that groff will format a side-by-side table item completely on a single page. If the side-by-side pair do not fit on one page, they force a page-break to the next one. The only place where I think you might have to manually format an item is if one side-by-side table item takes up _more_ than one page. -- Mike Bianchi 973 822-2085 mbian...@foveal.com
Re: Parallel Typesetting
ing to see how much trouble it would be to typeset a
bilingual text parallel by pages, as in, one language on the recto
page, the other on the verso page, synchronized somehow by paragraph,
preferably more or less automagically. I've searched the list already
and came upon an interesting albeit two decade old message[1] that
T}T{
Random words in French.
.br
preferably more or less automagically. I've searched the list already
page, the other on the verso page, synchronized somehow by paragraph,
bilingual text parallel by pages, as in, one language on the recto
with parallel typesetting with columns, on the same page, which is NOT
what I'm looking for.
went unanswered as well as a much more recent thread[2] that deals
preferably more or less automagically. I've searched the list already
page, the other on the verso page, synchronized somehow by paragraph,
bilingual text parallel by pages, as in, one language on the recto
and came upon an interesting albeit two decade old message[1] that
I'm trying to see how much trouble it would be to typeset a
T}
.TE
See attached:
i.pdf
--
Mike Bianchi
mbian...@foveal.com
i.pdf
Description: Adobe PDF document
Re: Resources for *roff internals and PDF generation
Deri, What a nice answer! (And this old-timer learned a few things.) Mike On Thu, Feb 24, 2022 at 04:09:13PM +, Deri wrote: > On Thursday, 24 February 2022 14:54:51 GMT Olle L�gdahl wrote: > > Hello, > > > > I understand this mail is a little outside the scope of this > > mailinglist; i just had nowhere else to ask. Does somebody know any good > > resources for understanding the internals of groff/roff? Mostly curious > > about the PDF-generation part. Any resources may be helpful (online, > > books). I already have the PDF-1.7 specification, but something more > > specific on document generation and easier to digest. > > > > Thanks in advance, > > > > Olle L�gdahl > > Hi Olle, > > I found the PDF 1.4 specification more helpful, it has a proper clickable > index, which the 1.7 version lacks. (https://www.adobe.com/content/dam/acom/ > en/devnet/pdf/pdfs/pdf_reference_archives/PDFReference.pdf). > > As regards how groff produces pdfs it is worth looking at the following:- > > The groff_out man page. > > This describes the groff intermediate format which is what the groff output > devices read to produce the final output. The intermediate format is > concerned > with the business of specifying fonts, size, colour and position of text on > the page and includes drawing commands for non-tex objects as well. > > Keith Marshall's pdfmark.pdf which is probably already installed. > > The intermediate format described above does not cover aspects which are > useful for pdfs in particular, i.e. creating a document overview and > embedding > links within the pdf, specifying meta-data for the pdf, etc.. This document > covers those areas. All these "extensions" are facilitated using the \X > escape > for example, which allows you to send information directly to the output > driver. > > The gropdf man page. > > This describes some more \X extensions which are understood solely by the > gropdf device driver. > > Cheers > > Deri -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: Two trivial questions
On Tue, Oct 26, 2021 at 08:39:51PM -0500, Dave Kemper wrote: > > I say "g-roff" (to match t-roff and n-roff). The missing piece of information was before there was ?roff there was roff . roff Run OFF ((Unix version of the runoff text-formatting program from Multics)) https://en.wikipedia.org/wiki/Roff_(software) nroffNew ROFF troffTypesetter ROFF groffGnu ROFF neatroff NEAT ROFF or (NEArly TROFF ?) So if you came from a time and place where more than one of these were in common use, the pronunciation differentiates the particular implementation. But if groff was the only command you were exposed to ... growl like a dog. -- Mike Bianchi mbian...@foveal.com
Re: troff Memorandum Macros documentation derived from the paper "MM -
> My own research undertaken for updating Larry Kollar's ms.ms suggests > that there were several revisions of Lesk's ms manual. I was there at the time; mid-1970s. Michael Lesk's ms came out of the Bell Labs research area where UNIX was invented and refined. The target audience was the folk inside the research community and writing for journal publication. The mm macros came from the Programmer's Workbench area where the focus was on the Bell Labs general population using PWB to write for Bell Labs internal publication. A lot of work went into making the output meet the writing standards of that time. From citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.54.3797&rep=rep1&type=pdf A TROFF Tutorial Brian W. Kernighan For producing straight text (which may well contain mathematics or tables), there are a number of ‘macro packages’ that define formatting rules and operations for specific styles of documents, and reduce the amount of direct contact with troff. In particular, the ‘–ms’ [4] and PWB/MM [5] packages for Bell Labs internal memoranda and external papers provide most of the facilities needed for a wide range of document preparation. (This memo was prepared with ‘–ms’.) There are also packages for viewgraphs, for simulating the older roff formatters on UNIX and GCOS, and for other special applications. Typically you will find these packages easier to use than troff once you get beyond the most trivial operations; you should always consider them first. [4] M. E. Lesk, Typing Documents on UNIX, Bell Laboratories, 1978. [5] J. R. Mashey and D. W. Smith, PWB/MM — Programmer’s Workbench Memorandum Macros, Bell Laboratories internal memorandum -- Mike Bianchi mbian...@foveal.com
Re: Introducing mu, my new macro package
> So if you see a one-letter macro, it's definitely a macro and not a
> standard troff request.
True. But I must memorize that
.x
is a font-change macro. If it were
.Ufont bi
I am more likely to remember that the font will change to Bold Italic.
And it is from the U set.
And someday it could take the cbi argument. Constant-Width Bold Italic
But I say again, very nice!
Welcome to the Macro Writers Guild.
Mike
On Thu, Jul 01, 2021 at 09:44:13PM +0200, John Ankarström wrote:
> Den 2021-07-01 kl. 21:15 skrev Mike Bianchi:
> > With just a quick glance, I like what you've done.
> > I can see myself using it sometime soon.
> >
> > One suggestion, give the Inline, Environment and Other macros 2 or 3
> > character names with a common theme so they stand separate from the groff
> > commands and macros.
> >
> > [...]
> >
> > I have so many documents where _all_ the groff actions are in lower case
> > and I don't know where to look when I need to understand the action and
> > syntax. Is it native groff? Or the mm macro package? Or something I
> > wrote?
> >
> > Now when writing my own macros I tend to make them start with a capital
> > letter
> > or be all capitals.
>
> Thanks a lot! The neat thing about the one-letter lowercase macros,
> though, is that all built-in troff macros are two letters (or more). So
> if you see a one-letter macro, it's definitely a macro and not a
> standard troff request.
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: Introducing mu, my new macro package
> http://ankarstrom.se/~john/mu.html With just a quick glance, I like what you've done. I can see myself using it sometime soon. One suggestion, give the Inline, Environment and Other macros 2 or 3 character names with a common theme so they stand separate from the groff commands and macros. May I suggest ... .\" Inline macros -- .\" U" -- inline quotation .\" Ub -- bold font .\" Uc -- constant-width font .\" Ui -- italic font .\" Ux -- bold italic font .\" Environment macros - .\" Ud -- centered date .\" Uh -- heading .\" Ul -- literal display .\" Up -- paragraph .\" Uq -- quotation .\" Us -- subheading .\" Ut -- centered title .\" Other macros --- .\" U( -- begin footnote .\" U) -- end footnote .\" Uw -- want space or .\" Inline macros -- .\" _" -- inline quotation .\" _b -- bold font .\" _c -- constant-width font .\" _i -- italic font .\" _x -- bold italic font .\" Environment macros - .\" _d -- centered date .\" _h -- heading .\" _l -- literal display .\" _p -- paragraph .\" _q -- quotation .\" _s -- subheading .\" _t -- centered title .\" Other macros --- .\" _( -- begin footnote .\" _) -- end footnote .\" _w -- want space I have so many documents where _all_ the groff actions are in lower case and I don't know where to look when I need to understand the action and syntax. Is it native groff? Or the mm macro package? Or something I wrote? Now when writing my own macros I tend to make them start with a capital letter or be all capitals. Again, very nice! Mike On Thu, Jul 01, 2021 at 08:09:25PM +0200, John Ankarström wrote: > Hi all! > > I've been working on my own troff macro package for the last couple of > weeks, and I thought I'd share it with you here: > > http://ankarstrom.se/~john/mu.html > > The package is called "mu". In summary: > > It is simple, flexible and small: u.tmac is only 417 lines. > It has footnotes and tables of contents. > It has no special registers or strings! > > For an example of an advanced document written with mu, see > http://git.ankarstrom.se/mu/plain/README.pdf. > > I hope you find it interesting and perhaps even useful. Feel free to > write any questions or feedback. > > Best regards > John -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: 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] Re: Modernising UNIX manpages.
> I would like to investigate the possibility of using Markdown as an > alternate format for UNIX man-pages. For what it is worth ... This is a very old story and I might not have all the details correct, but the basic message fits here. And the basic message is: Once you have a stylized markdown for man-pages that produces a stylized output of groff, mandoc and/or html create back-converters to turn changed output into the source form. The story is from the mid 1970s. A friend worked on a project that used a "data dictionary" (https://en.wikipedia.org/wiki/Data_dictionary) and a specification language (spelling out the functionality of the code in stylized English) to drive translator programs that produced: IBM IMS (Information Management System) database specification language andCOBAL code and functions for accessing the databases. The inputs AND outputs were _so_ stylized that making changes in any of the outputs were translated back into the input specification language and data dictionary with reverse-translator programs. The translation paths thus became a circle. Changes could be made in any of the output forms and reflected back into the other input forms. All the input forms were human-readable. Someone who could only read the data dictionary could change the code in a predictable way. Likewise for someone who was IMS-knowledgeable. Over time the project became very stable. Changes were reliable. When bugs were found the bug-fixes were often in the translators. Thus finding one bug would often fix many more un-found bugs. IFF such a thing could be accomplished for the man-pages, then maintaining them would be something that could be passed along down the generations. ((I am 73 years old. I grew up with nroff/troff/groff. I think I have written my last man-page.)) I imagine pairs of translators, like maybe: markdown <-> mandoc mandoc <-> groff groff<-> html The <-> translators might be macro packages (for groff, or may mom) or could be written in a Python, Ruby, or something else. It would have to be a team effort with team consensus. Mike On Wed, Apr 21, 2021 at 05:46:58AM +0200, JM Marcastel wrote: > Dear all, > > I would like to investigate the possibility of using Markdown as an > alternate format for UNIX man-pages. > (Cf. https://github.com/marcastel/marcastel/discussions/7) > > Rather than re-inventing the wheel I would ideally like this to > become part of an existing tool (mandoc, groff, ...). > > I would like to devote time to this in the second semester of 2021 > and would appreciate sharing this. > > I believe the first step is to provide a proof of concept what > demonstrates the expected outcome and that desired command line > interface. > > I have a clear idea on how to build that POC once the requirements > have been set. > > Has this already been studied? Would this be an initiative you > would support? > > Best regards, > JM Marcastel > -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[eqn] 'therefore' and 'implies' symbols
Hello! I was wondering if it is possible to use the "therefore" (∴) and "implies" (⇒) symbols using eqn. In LaTeX this is possible using \therefore, and \implies. I can't seem to find any method of doing this in eqn - I thought I'd ask in case I'm missing something. Apologies if this is the wrong place to ask this. Thanks - Mike
Re: problem with mm macros
Andreas has found a true bug. The .AT macro does not act as advertised in
groff_mm ...
The title _does_not_ show up after the name in the signature block.
Search /usr/share/groff/1.22.2/tmac/m.tmac (the copy I am using at present)
fgrep 'cov*at!' /usr/share/groff/1.22.2/tmac/m.tmac
and I find
.\" author(s) title stored in cov*at!x!y
. ds cov*at!\\n[cov*au]!\\n[cov*i] "\\$[\\n[cov*i]]
which shows that cov*at!N!N is created as cov*at!1!1
but never referenced.
Witness: If I give nroff -mm the following ...
.ND "January 1, 1999"
.AU "Dr. Gray Hound"
.AT "Project Leader"
.MT 5
.nf
\*[cov*au!1!1]
\*[cov*at!1!1]
it yields ...
Dr. Gray Hound
Project Leader
Does anyone maintain m.tmac these days?
Mike
On Thu, Feb 25, 2021 at 09:55:59AM -0500, Robert Goulding wrote:
> I get the same result; and then tried variants with .LT instead of .MT, and
> the signature is not produced at all!
>
> On Thu, Feb 25, 2021 at 9:44 AM Andreas Eder wrote:
>
> >
> > Hello,
> >
> > I'm a newcomer to roff and have just begun reading the book 'UNIX
> > Document Processing and Typesetting'. There is an example of a letter in
> > there thay I enclose here, necause it shows the poblem:
> >
> > .ND "January 1, 1999"
> > .AU "Dr. Gray Hound"
> > .AT "Project Leader"
> > .MT 5
> > .DS
> > Our Reference: prog/001
> > Your Reference: xyz/100
> > .SP 4
> > Mr. William Smith
> > Chief Advisor
> > Consult the Consultants
> > Penny House
> > Graceland
> > .DE
> > .SP 3
> > Dear Mr. Smith
> > .SP 2
> > .ce
> > Recruitment of a Programmer
> > .fi
> > .SP 2
> > .P
> > With reference to our discussion over lunch at the West Gate Club,
> > the requirements of the programmer are as follows:
> > .P
> > The programmer should be conversant in all computer programming languages
> > and be ready to develop any kind of software using different computers.
> > The programmer must also be willing to do administrative and paperwork
> > to get his/her pay.
> > .P
> > Although the requirements may seem to be unusual, I am sure
> > that with your company's expertise in head hunting, finding a
> > suitable person for the above-mentioned position will be a trivial matter.
> > .P
> > Hope to hear from you soon.
> > .FC Sincerely yours
> > .SG
> >
> > Now the problem is that groff doesn't show the author's title below the
> > author's name. Both heirloom and neatroff do, so it is maybe a bug in
> > groff? Also both heirloom and neatroff show name and tile in bold,
> > whereas groff only shows the name an does not do so in bold.
> >
> > Maybe someone with more experience in roff can explain what goes wrong.
> >
> > Sincerly,
> >
> > Andreas Eder
> >
> >
> >
> >
>
> --
> Robert Goulding
> Director, John J. Reilly Center for Science, Technology, and Values;
> Director, Program in History and Philosophy of Science;
> Assoc. Professor, Program of Liberal Studies,
> Fellow, Medieval Institute,
> University of Notre Dame.
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: Long text in tbl won't wrap, maybe related to mom
I don't know what the intended appearance was supposed to be, but
this sort-of works; substitute a tab-character for each ...
.TS
expand;
cb s s s
c | c | c s
ltiw(1i) | ltw(2i) | lp8 | lw(1.6i)p8.
Some Interesting Places
_
NameDescriptionPractical Information
_
T{
American Museum of Natural History
T} T{
The collections fill 11.5 acres (Michelin) or 25 acres (MTA)
of exhibition halls on four floors. There is a full-sized replica
of a blue whale and the world's largest star sapphire (stolen in 1964).
T}Hours 10-5:45 S M Tu Th, 10-9 W Sat. Sun.
LocationT{
Central Park West & 79th St.
T}
AdmissionDonation: $1.00 asked
SubwayAA to 81st St.
Telephone212-769-5100
_
.TE
The characters used to delineate columns disappears in normal printing.
Mike
On Fri, Feb 05, 2021 at 11:05:58AM -0300, Bento Borges Schirmer wrote:
> Hello
>
> I'm having great joy composing little documents for some homework and
> assignments using groff and the mom package. Yesterday I wanted to learn how
> to
> make tables so I read through mom's excellent documentation and
> reproduced all tables except the last one from L. L. Cherry and M. E.
> Lesk's Tbl -- A Program
> to Format Tables, when I encountered a problem where the lines wouldn't wrap:
>
> .PRINTSTYLE TYPESET
> .START
> .TS
> expand;
> cb s s s
> c | c | c s
> ltiw(1i) | ltw(2i) | lp8 | lw(1.6i)p8.
> Some Interesting Places
> _
> NameDescription Practical Information
> _
> T{
> American Museum of Natural History
> T} T{
> The collections fill 11.5 acres (Michelin) or 25 acres (MTA)
> of exhibition halls on four floors. There is a full-sized replica
> of a blue whale and the world's largest star sapphire (stolen in 1964).
> T} Hours 10-5:45 S M Tu Th, 10-9 W Sat. Sun.
> \^ \^ LocationT{
> Central Park West & 79th St.
> T}
> \^ \^ Admission Donation: $1.00 asked
> \^ \^ Subway AA to 81st St.
> \^ \^ Telephone 212-769-5100
> _
> .TE
>
> This is a minimal version of the last example from the tbl document that
> reproduces the funny behavior. It breaks the line as in the source, but the
> table grows beyond the page and doesn't stay as nice as seen e.g. on the troff
> FAQ or when using groff -Tpdf -t -ms. Am I missing something? Is there any
> workaround? I don't mind manually breaking the lines, of course.
>
> Best regards,
> Bento
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [DRAFT] Revised groff ms manual for review
> Overall, let’s (both of us) focus on trimming anything that doesn’t
> help a reader get a -ms document together.
YES!
But don't throw away the trimmings. They often contain info that the
more involved readers might value. So maybe there can be an Appendix called
"Color Commentary"? ;)
Mike
On Tue, Nov 10, 2020 at 11:40:26PM -0500, Larry Kollar wrote:
>
> G. Branden Robinson wrote:
>
> > Happy Halloween!
> >
> > Ready for something on the gory and disturbing side?
>
> I got six staples in my head, day before Halloween. They’re out now,
> but I had a live-action creepshow going for the day. Bring it. :D
>
> > I feel like I'm about 40% of my way through a huge update of Larry
> > Kollar's ms.ms document, as promised earlier this year. I've done most
> > of the work over the past 2-3 weekends; the promise of a release kicked
> > my rear into gear.
>
> I’ve looked it over. I’m not sure if the chatty parts are yours or mine
> at the moment. When I get a chance, I’ll run a diff and see which of us
> said what.
>
> Overall, let’s (both of us) focus on trimming anything that doesn’t
> help a reader get a -ms document together.
>
> > … I started discovering just how much is of our
> > s.tmac is undocumented, and how much confusion there has historically
> > been over what, _exactly_, constitutes the historical ms interface.
>
> I have mixed feelings about this. What’s the goal, here? Unless people
> are trying to resurrect older documents, they shouldn’t have to care about
> the “historical” interface — just use what’s there. But…
>
> There was once “the” *roff. Then it sunk, and Groff took its place. But
> thanks to Plan9, the “the” *roff resurfaced with a lot of nice updates, then
> got forked to Neatroff and Heirloom. Fortunately, the differences are
> small enough that one can write a -ms extension package for both, using
> “.ie g / .el” or “.if g / .if neat" in a few places.
>
> The whole point of ms.ms was *not* to get into internal details. It was
> mostly “here’s how you use Groff and -ms to put a document together,
> and here’s how you can control the formatting.” Yes, the end of the
> document does describe differences from the original -ms, and that’s
> probably helpful for the Plan9 derivatives.
>
> But unless you’ve unearthed a 35 year old document that assumes it’s
> using “the” *roff, and is doing all sorts of creepy things under the hood,
> it shouldn’t matter much. My college roommate sent me a book he wrote
> in -mm, back in the 80s, and I got Groff to format it by adding “\&” to
> the beginning (he had a custom cover). The same should apply to -ms
> documents.
>
> If we want to support data archaeologists, maybe we should write a
> separate document for them. :D
>
> — Larry
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [groff] 03/06: roff(7): Develop History section a bit more.
> ... what is the evidenvce > that Mike Lesk is the author of the man(7) macros? I asked Michael about man(7) and ms(7) ... Subject: I did not write the "man" macros. I did write -ms. My best guess at the author of the "man" macros is Doug McIlroy. tx Michael Lesk -- Mike Bianchi
Re: UTP Revisited: scoping the project
On Tue, Oct 20, 2020 at 05:56:46PM +1100, Damian McGuckin wrote: > On Tue, 20 Oct 2020, Larry Kollar wrote: > > > To be honest, I can?t believe over a fourth of my life has gone by since > > we started the transcription. > > The scarier thought is when you realize that you wrote your first tutorial > for using the antecedents of groff more than half your lifetime ago! OK! Everyone line up in the order of their first exposure to *roff. Mr McIlroy all the way on the right ... -- Mike Bianchi
Re: UTP Revisited: scoping the project
> Should we talk about newer groff macro packages like -mom?
> What about utilities and preprocessors?
Absolutely.
I imagine this turning into a collaboration of many authors and editors,
with most concentrating on just the chapters where their expertise is greatest.
Mike
On Tue, Oct 20, 2020 at 12:55:57AM -0400, Larry Kollar wrote:
> To be honest, I can’t believe over a fourth of my life has gone by since we
> started the
> transcription.
>
> Now, with sources where everyone can grab them, maybe we should talk about
> what we
> want to do for UTP Revisited. These are just off the top of my head:
>
> - Update Chapter 3 to cover Vim (including gvim)
> - Update Chapter 4 to cover groff (and Heirloom and Neatroff, listing the
> most significant
>differences)*
> - Update Chapter 5 (-ms) and Chapter 6 (-mm) with groff extensions.
> - New chapter: Ways to work with other file formats, with the goal of
> getting content into
>[gt]roff. Cover conversion utilities such as pandoc and lowdown. I’ll take
> this one at least
>to first draft… maybe I’ll throw in a plug for Tines as a groff-friendly
> outliner, LOL.
> - Where DWB is mentioned, point out that some utilities (like pic) are part
> of the standard
>distributions now, and mention replacements for other DWB utilities. (Or
> has DWB been
>liberated?)
>
> Should we talk about newer groff macro packages like -mom? What about
> utilities and
> preprocessors? I think preconv is a must, do we want to at least mention grap
> or groffer?
>
> Do we want to cover lighter editors, such as pico, nano, or joe?
>
> What about “upstart" scripting languages such as Perl or Python?
>
> OK, that’s all I have, and I’m up way past bedtime. Does anyone else have
> ideas about
> what should be in an updated UTP?
>
> — Larry
>
> ---
> *This implies updating the macros to work with non-groff formatters, and that
> implication
> is deliberate on my part.
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: Learning troff - where to start?
> Isn't it sad that nothing more modern is available? Since it is open source, it might make sense to have a team produce a groff version? Mike Sent from my Adesso PCK-308UW. On Wed, Oct 14, 2020 at 10:26:27AM +1100, Greg 'groggy' Lehey wrote: > On Tuesday, 13 October 2020 at 22:49:03 +0200, J.-J. wrote: > > Le mardi 13 octobre 2020 � 14:41 +0200, Johann H�chtl a �crit : > >> * What would be a good starting point (tutorial) into troff and its > >> core principles? > >> > >> * What is the canonical documentation of troff all the existing > >> implementations seem to derive from and describe their deltas in > >> their respective documentation? > > > > Here is in my opinion the best book on the subject > > (and it's now FREE!) : > > > > https://www.oreilly.com/openbook/utp/ > > An excellent book, and one that I have used a lot. But nobody can > claim that it's up-to-date (it predates groff), and there are many > features in groff that weren't in the troff version described. Isn't > it sad that nothing more modern is available? > > Greg > -- > Sent from my desktop computer. > Finger g...@lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: * RL * code review and strategy for macros set?
On Thu, Aug 13, 2020 at 10:57:45AM +0200, Marc Chantreux wrote:
> :
> thank you for your patience while reading my broken english.
You do me the honor of speaking my language. It is I who should thank you.
> > export GROFF_TMAC_PATH=${HOME}/lib/tmac
> > groff -Kutf8 -GtpeR -U -rW6.5i -mm -mFm ...files...
>
> > where Fm refers to the "Foveal macros" that tune the mm macros. They
> > are
> > found in ${HOME}/lib/tmac/Fm.tmac .
> :
> cool. what i had
> in mind was a bit different: having a ock.tmac that starts with
> something like `mso mm`.
That is the equivalent.
In the UNIX/Linux world there are many correct solutions.
Enjoy the journey!
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: * RL * code review and strategy for macros set?
On Wed, Aug 12, 2020 at 06:07:21PM +0200, Marc Chantreux wrote:
> hello Mike,
>
> first of all: pardon my lack of culture but i don't get what "RL" means
> in this case. i suppose it's a way to say you replied intentionally to
> me and not to the mailing list but have no confirmation of that�.
RL has to do with the mail filtering I have.
It means nothing to anyone else.
> it is sad that the rest of the mailing list can't read this very
> interesting answer.
That was a goof on my part. I'll add the groff mailing list to this response.
> On Tue, Aug 11, 2020 at 10:44:53AM -0400, Mike Bianchi wrote:
> > I would suggest you turn the list upside down and start with something that
> > _works_ even if not to your liking.
>
> i gave roff a try in circa 2000 and i hated it. i started again since
> the begin of the year because i love the man command and wanted to write
> my own manuals.
>
> it quickly appeared to me that
>
> * compared to the other typesettings systems (including the very
> overated TeX), troff isn't that bad.
> * my only sine qua none is fixed by the -k flag
> * now understand that some syntax "limitations" actually really
> ease many automations
> * nothing compares when it comes to be fast and lightweight.
>
> so i started using mm, me and ms and got results that are far enough
> for me but if i want to go further, i should be abble to tune the
> documents to comform the visual chart of my employees for exemple.
>
> if i can be good enough at it, maybe i can introduce roff in the
> communities i work for.
> > The *roff commands are an _assembly_ language with lots of hidden states,
> > arcane rules and interactions. It's value is that it works and that _lots_
> > of
> > smart people mastered it to such a degree that some _really_ clever things
> > have
> > been done with it. Macro sets are the means of doing the clever things.
>
> to explicit one question i have: should a high level macro set rely on
> lower level ones like ms (as it seems ms is't as rich and opiniated than
> me, mm and mom)?
I strongly recommend you pick one macro set, read and become fluent in the
the concepts in the command macros manual for that set and use the built-in
tuning features to make them look the way you want. You are _not_ the first
person to want it "just like that, but different" and you will find that the
macros sets are built with fine-tuning in mind. I have used the mm package
since it's invention and have always used a set of its fine-tunings to make
it specific to my needs.
export GROFF_TMAC_PATH=${HOME}/lib/tmac
groff -Kutf8 -GtpeR -U -rW6.5i -mm -mFm ...files...
where Fm refers to the "Foveal macros" that tune the mm macros. They are
found in ${HOME}/lib/tmac/Fm.tmac .
There I have things like:
\# A mark list of checkoff boxes.
.de CheckList
.ML "\s+8\(sq\s0 " 7
..
.de CheckListEnd
. LE 1
..
> > Said another way, many have gone before you and pushed the rock far up the
> > mountain.
>
> i'll take my time on it as i'm convinced mastering troff is worth it.
>
> > Skim and then re-read the *roff command manual of your choice.
> > I suggest groff.
> > ... [you describe a interesting path there ] ...
>
> thanks for this widsom. I just copied m.tmac as ike.tmac and will
> modify/tune it until the documents i already written fit the look
> i acheived in my demo.
I advise _against_ modifying the standard *.tmac files, especially with the
sets like me , ms and mm . They rarely change, but when they do you loose
the benefit of the fixes.
> > When you think you have the basics down, go to the macro package of your
> > choice
> > and attempt to understand the simple macros for the simple concepts. I use
> > mm so I would start with
> >
> > .P Paragraphs
> > .SP line SPacing
> > .HU Header Unnumbered
> > .R Roman font
> > .B .I Bold Italic
>
> i'll do that one by one.
>
> > ((From someone who has been writing nroff/troff/groff since the late
> > 1970s.))
>
> impresive :)
No. Just old.
> in a sense, i envy you: it feels to me that computers were about for and real
> hobbists back then so the digital culture was much more inspiring than
> nowadays.
I was fortunate enough to be at Bell Labs when the UNIX Programmer's Work Bench
was happening and in one of the first groups to do our PL/I code development on
a UNIX PWB machine that took the place of a card puncher, punch card reader and
printer. Said another way, it was a work environment making use of a new
Bell Labs innovation. It led into a career.
> �: The New Hacker's Dictionary definition of RL is "Real life"
>(http://www.catb.org/jargon/html/R/RL.html)
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: weird \s
Bjarni,
Nice, tight analysis and proposed solutions. Thank you.
Mike Bianchi
On Thu, Apr 02, 2020 at 11:58:01PM +, Bjarni Ingi Gislason wrote:
snip
> 1) The missing part is information.
> Solution:
> a) Provide a message (warning, error), if "\snn" is in the input.
> b) Augment the documentation to tell the readers,
> that "\snn" is deprecated, obsolete, out of date, etc.
> and what they should use instead.
>
> 2) About the "\snn" problem.
> The current executing code is not the problem.
> The current existing roff-files are not the problem.
> The problem is the people who (still, will) write "\snn"
> instead of "\s(nn" (portability) or "\s[nn]" (for "groff" and
> compatibles).
snip
> 3) Other things.
> a) A missing part of messages is the name of the culprit,
> in this case the s-escape (\s).
> Solution: Provide the name ("\\s escape" is already used once in the
> subroutine).
> b) Adding details of the argument of the escape in messages is not
> necessary.
> c) Adding specific code to report specific syntax errors is not
> necessary.
snip
Re: weird \s
On Tue, Mar 31, 2020 at 09:57:08AM +0100, Ralph Corderoy wrote: > : > The point of being able to format historical documents is that they can > be formatted without examination and editing to fix what today might be > considered bad style. In an ideal world, preserved historical documents would be generated from preserved historical source processed by preserved historical processing programs running on preserved historical systems. "Backward" compatibility has always been fraught with pain. Designing for forward compatibility requires a genius we rarely, but do occasionally, see. I think UTF-8 encoding may be such. -- Mike Bianchi
Re: weird \s
> What do folks think?
I would add that where \s[nnn] is legal it would be the preferred syntax.
It is what I use all the time, even for \s[9] . Unambiguous.
Witness in groff:
.sp 8
.ps 8
\ .ps 8 \s10 10 \s40 40 \s(20 20 \s[40] 40 \s[120] 120
attachment:
witness.png
Mike
On Tue, Mar 31, 2020 at 12:32:04PM +1100, G. Branden Robinson wrote:
> At 2020-03-30T19:16:56-0400, Doug McIlroy wrote:
> > Does anyone else see the following behavior?
> > Version 1.22.4 handles \s correctly up to \s39, but
> > truncates a size of 40 or greater to its first
> > digit. Here are two screen shots, with ^D edited in
> > to show where input ends and output begins.
>
> Hi Doug!
>
> This appears to be for backward compatibility. The 1992 revision of
> CSTR #54 says in �2.3:
>
> "Note that through an accident of history, a construction like \s39 is
> parsed as size 39, and thus converted to size 36 (given the sizes
> above), while \s40 is parsed as size 4 followed by 0. The syntax \s(nn
> and \s�(nn permits specification of sizes that would otherwise be
> ambiguous."
>
> As Robert Thorsby noted, this is documented in the groff Texinfo manual;
> however, it is not noted in the groff(7) man page, something I'm
> inclined to fix in the near term.
>
> To the broader group, I would furthermore suggest that, being GNU roff,
> it might behoove us to preserve the above "accident of history" only in
> compatibility mode, and have the \sn form accept only a single-digit
> argument for consistency with other escape forms. Doug still would have
> gotten into trouble, but it would have been a more easily understood
> trouble.
>
> What do folks think?
>
> Regards,
> Branden
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: amusing bug
On Tue, Mar 17, 2020 at 01:37:22PM -0400, Steve Izma wrote: > : > For a description of a real antediluvian habit, there's a short > video somewhere (I can't find it now) of him talking about why he > doesn't need the Internet while crossing the Atlantic by ship. See https://youtu.be/6v6wdK2EbIQ?t=298 -- Mike Bianchi
Re: amusing bug
I nominate Brian Kernighan. Mike Bianchi On Tue, Mar 17, 2020 at 12:30:21PM -0400, Eric S. Raymond wrote: > Doug McIlroy : > > Please excuse my antediluvian hangover. > > *snort* > > If I had to make a list of the top three people who never, *ever* need > apologize for "antediluvian hangover", the other living designee > besides yourself would be Ken Thompson. Sadly Dennis Ritchie is no > longer available to fill the third slot. I suppose Don Knuth will do. > > :-) > -- > http://www.catb.org/~esr/";>Eric S. Raymond
[groff] An alternative to info(1) ?
On Sun, Feb 16, 2020 at 07:55:31PM -0800, Larry McVoy wrote: > I *hate* info. It has made Linux less available to a lot of people. BUT info sometimes has information that man(1) lacks. So _maybe_ an approach would be to make an info2(1) command that had access to the same information with a different terminal interface. Or a dialog interface. So my question is does any have experience with a terminal walk-the-decision-tree interface they like? Could it serve as a model for info2 ? -- Mike Bianchi
Re: GNUism in groff tests, was: pic anomalies
On Fri, Jan 03, 2020 at 12:45:22PM -0500, Doug McIlroy wrote: > > C is one of the worst possible foundation languages conceivable for > > automated formal verification > > Yet the Mars rovers run on a wholly checked code base written > in C, ... I sometimes think that C would be greatly improved if it just added: Strings as first-class objects (instead of a collection of array side effects) Hardened memory management Hardened pointer management -- Mike Bianchi
[groff] Re: Space After A Heading with groff -mm
> When using the 'mm' macros, I try ...
Look at groff_mm(7) , for the documentation of the .H macro.
The .H macro is highly customizable.
In particular, the Hs register says:
Heading space level
A blank line is inserted after the heading if the heading
level is less or equal to number register Hs. Default
value is 2.
Text follows the heading on the same line if the level is
greater than both Hb and Hs.
Mike
On Sun, Dec 22, 2019 at 05:03:11PM +1100, Damian McGuckin wrote:
>
> When using the 'mm' macros, I try
>
> .H 1 "A Heading"
> .AL 1
> .LI
> My List
>
> under 1.18.1.4, if gives me a single space between the space and the list.
>
> 1. A Heading
>
> My List
>
> This is the correct behaviour and has been since the days of DWB/MM. Some
> of use are that old to remember that. Sad!
>
> Anyway, then I try it under 1.22.3, I get 2 spaces between the two.
>
> Before I go fishing for the problem, has anybody else experienced this and
> have a fix?
>
> Thanks - Damian
>
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Jean Louis wrote on Mon, Oct 28, 2019 at 11:12:51AM +0530:
> From: Ingo Schwarze > >> I'd like to know if it is possibile translate the entire groff manual > >> in italian obtaining some money for this kind of work. > > > It is good idea. You could hire somebody to translate it. > > Note that there is no consensus about this opinion. > For example, personally, i consider translating documentation > a waste of time if not outright harmful. I completely agree with Ingo; there is _no_ consensus. I'm glad someone took the time and effort to translate the UNIX and C-language documents into the many languages where they exist. As to groff, et. al., they are stable enough that any translations would remain useful, especially for those approaching them for the first time. -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
Re: [groff] A poor mans Excel
> If there is interest, I'll post the script and an example.
Yes please.
Mike
On Thu, Oct 10, 2019 at 01:21:31PM +0200, Ulrich Lauther wrote:
> Hi all,
>
> I have written a small perlscript, that preprocesses tables
> and allows to
>
> - add the values in selected collums
> - to replace a table entry by the result of an expression
>
> Lines between
> .(
> and
> .)
> are processed.
>
> The ".(" line may contain the numbers of collums in which addition
> is requested, e.g.:
> .( add 2 5 7
> or just
> .( 2 5 7
>
> ".(" ".)" blocks my be nested; sums calculated at a lower level are
> propagated up.
>
>
> Table entries of the form E. are repaced by the result
> of the expression rounded to n digits after the decimal point.
> "expression" is any valid perl expression.
> Variables used in the expression are
> - any valid perl variable (starting with "$")
> - $, the value in column n in the current line
> - $S, sum of values in the column (where $S is placed) seen so far
> If $S or E. is precedet by an "!", addition is suppressed for this
> table entry.
>
> As all tables of a document are processed by one perl-instance and perl
> variables can be created on the fly, values can be tranported from one
> table line to a later one or even to another table.
>
> Code size: 130 lines of perl
>
> Limitations: Multiline table enties are not supported.
>
> If there is interest, I'll post the script and an example.
>
> Kind regards,
>
> ulrich lauther
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [groff] anyone seen ".ny0" ?
> .ny0
look for a macro definition:
.de ny
:
..
In the old days, no macro name was more than 2 characters so nroff/troff would
understand .ny0 to be macro ny with argument 0 .
Mike
On Sun, Mar 24, 2019 at 07:16:07PM +0100, Walter Harms wrote:
> Hello list,
> while looking at the xorg man pages there came
> a question what this .ny0 may mean (i shorted that of cause):
>
>
>
> .ny0
> .TH XtAppNextEvent __libmansuffix__ __xorgversion__ "XT FUNCTIONS"
> .SH NAME
>
> .
>
> I could not find this in the groff manual. It seems to do nothing.
> Any ideas ?
>
> re,
> wh
>
--
Mike Bianchi
Foveal Systems
973 822-2085
mbian...@foveal.com
http://www.AutoAuditorium.com
http://www.FovealMounts.com
Re: [groff] [patch] modernize -T ascii rendering of opening single quote
On Thu, Feb 21, 2019 at 10:01:07AM +, Jeff Conrad wrote: > > We still have the question about what is (or was) a Genuine ASCII™ > device, I don't think "Genuine" is a question. There ain't no such thing. Just look at your various keyboards. I have keycaps (unshift ") with straight and angled glyphs. Once again, is anyone working on a UTF-8/Unicode keyboard? I see a need coming. -- Mike Bianchi
[groff] modernize -T ascii rendering of opening single quote
> "Stamp out US-specific, internationally non-portable usage of ASCII > that is incompatible with Unicode, ..." > Is that something we can agree on? I don't agree because it cannot be done. Documentation, still valuable today, was written with "US-specific, internationally non-portable usage of ASCII" and must be understood in that context. It is the very nature of history. Otherwise we burn the books and rewrite them "as they should have been written if we knew then what we know today". Again I make the case for producing a way to tie the specific font and character-code-to-glyph-graphic map to a document so it can be reproduced as the author intended. Said another way "modernise" groff to add that capability and make UTF-8 the modern character-code-to-glyph-graphic map. (Is anyone working on a UTF-8 keyboard? We have the technology. www.nkkswitches.com/nkk-smartswitch-lcd-36-x-24-pushbutton-display-enhanced-accommodate-low-voltage/ Certainly an extension keypad of programmable glyph keys would be doable!) -- Mike Bianchi Foveal Systems 973 822-2085 mbian...@foveal.com http://www.AutoAuditorium.com http://www.FovealMounts.com
[groff] modernize -T ascii rendering of opening single quote
> ... that doesn't look like a consensus yet, and unfortunately, > i don't see how to argue further, ... > : > Any ideas how to resolve this clash of priorities? Rephrasing what I said before: ... build a generalize tool where the choice of font or device implies a set of desirable (to me) character substitutions and renderings that can easily be changed via a personalized configuration file. Say .grofftool-txt.rc where txt is a font name or dev (or both?). Some history here ... The issue of how a specific a ASCII code is rendered goes back to >before< troff. In the 1970s (my youth) there were so-called "daisy wheel" printers/typewriters/terminals where the font was implemented via an easily substitutable part. en.wikipedia.org/wiki/Daisy_wheel_printing The IBM Selectric "ball" (88 glyphs) served the same purpose. en.wikipedia.org/wiki/IBM_Selectric_typewriter They were quite popular in the days of nroff. So the question of how the single and double quotes would be printed was answered by the specific typing element in the machine at the time of printing. Programmers had their favorites; document writers theirs. -- Mike Bianchi
[groff] ... 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
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] 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
> ... 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
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] 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] 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] 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] 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
[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] 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] 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
[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
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
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
[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] 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
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] 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] 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] * 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] 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] 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] 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] 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
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 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] 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] 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
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] 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] 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] 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] *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] 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] 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] 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] 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] 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] 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] 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] 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] 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
[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] 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
Re: [Groff] Proper Small Caps.
(Commentary) http://xkcd.com/1167/ -- 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] 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
