Re: Hi! Do you have a 64 bit version of Groff for windows?
Am Freitag, 2. April 2021, 23:16:28 CEST schrieb Cool Kiwi: > Hello! I am new to GNU troff and I would like to try it. But, when I > went to download it, I couldn't find a 64 bit version of groff to use. > Do you have 64 bit version (either old or new) of groff to download? > > Also, I see a bunch of files to downloads on your downloading hosting > website, sourceforge.net. Which file should I download? > > Thank you! > > From New Groff User🐃 Cool Kiwi, If you are working with a pckagae manager, it will do it for you. Depending on the architecture of your machine it will install the 64 or 32 bit, the Intel or Arm version. In my case, OpenSuse # zypper install groff or # zypper install groff-full On Upbuntu or Debian it's like # apt install groff Regards Heinz
Re: .ss paragraph-style-footnote example, then and now
Hi Branden, I too need to amend misstatements in my original post. Unfortunately, unlike you, I spotted them after you replied, so I've muddied the discussion with them. Here's what I should have said about the original example: - It shows how to use .ss to insert extra (discardable) horizontal space without overriding its normal use to also separate words and sentences. That is, in the original example, one of the footnotes could have consisted of more than one sentence, and groff would use its usual spaces to separate words and sentences while still putting the extra-wide space between footnotes. - It shows that .ss will take effect multiple times on the same output line. So I got the details wrong, but with the above finessing I think my main points stand. I'll reply to some of your specific responses out of order: On 3/25/21, G. Branden Robinson wrote: > The _main_ thing I wanted to illustrate was > the use of the _second_ argument to .ss. A valid point, though I still suspect that's a straightforward enough application of the basic .ss description that it might not warrant an example illustrating only that. > the original example _does not illustrate the use of > the second argument to .ss_, which I think is a flaw given the > context. In fact, the _only_ groff feature it uses is the .nop > request. Therein lies a worthy philosophical question: should the Texinfo examples strive to illustrate groff-specific features, or general language features? The manual overall seems to presume no existing roff knowledge, so arguably the examples should be illustrating the roff language as a whole. However, see my final paragraph below. > I find .nop to be poorly-named No argument there. > if I understood all of the use cases that motivated it I'd > be happy to add them to our manual. Agreed, the .nop section is a prime candidate for some good examples of where that request is useful; like you, I don't have any readily available. Does anyone out there use this regularly and have some simple examples? If that hole were filled in, it would be less important to retain uses of .nop in unrelated snippets. > By changing the .nop request into a pair of spaces you can, > perhaps, achieve the same result with only CSTR #54 features. (I say > "perhaps" because V7 Unix troff didn't honor the .ss request for nroff > devices at all, and Heirloom doesn't seem to either). I'll call this > "Example 3". > > .ll 4.5i > 1.\ This is the first footnote.\c > .ss 48 > \" 2 spaces > .ss 12 > 2.\ This is the second footnote. > > The above works on groff equivalently to the old original example. Good point. (Incidentally, two spaces aren't necessary; one is sufficient.) But I think which is better is a judgment call. Were I using this technique in production code, I'd probably use the .nop formulation because I find it cleaner than a line containing only space (or alternatively, as above, space followed by a comment). The .nop might still warrant a comment to explain what it's doing, but the comment at least wouldn't need to point out the .nop's very existence. But in a short example illustrating a novel .ss usage, keeping the focus on that and not bringing in more other requests than necessary has its advantages too. Whittling your Example 3 down to only CSTR #54 features further drives home that the implementation matters: This snippet does what you want in groff, and does not in Heirloom troff, regardless of what extension level you specify. Whether this is a functional change that warrants an explicit mention in the manual, I'm not sure. This might be an unintentional limitation (or a bug) in the original code; I don't think anything in CSTR #54 indicates that this *shouldn't* work. Thus, while groff seems to depart from historical behavior here, it's not clear that it departs from historical *intent*.
Re: Update groff_tmac(5)
On 3/28/21, Peter Schaffter wrote: > Mom's been around for almost two decades. She's no longer the new > kid on the block. Isn't it time this entry be updated? This was updated a few weeks ago in commit bbbcafc8 (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=bbbcafc8). The description of mom could still be refined if you have a wording you'd prefer.
Re: Soft hyphens
On 3/28/21, Peter Schaffter wrote: > I'm wondering if the interpretation of soft hyphens when .nh is > active is correct behaviour. It's counter-intuitive and feels like > a bug. If it is the expected behaviour, we need to amend the info > manual to state that .nh does not disable the interpretation of soft > hyphens. I don't know the answer to your question, but in general, anything that will require some kind of change -- even if it's presently unknown whether that change is to the software or to the documentation -- should have a savannah ticket opened (http://savannah.gnu.org/bugs/?group=groff&func=additem) to keep tabs on it.
Re: Soft hyphens
On Sat, Apr 03, 2021, Dave Kemper wrote: > On 3/28/21, Peter Schaffter wrote: > > I'm wondering if the interpretation of soft hyphens when .nh is > > active is correct behaviour. > > I don't know the answer to your question, I got an answer from Doug McIlroy. "In pre-Unix roff hyphenation mode 0 turned off all breaking of words. The original troff, however, behaved as described above, and also broke genuinely hyphenated words in mode 0." > but in general, anything that will require some kind of change > --even if it's presently unknown whether that change is to the > software or to the documentation--should have a savannah ticket > opened (http://savannah.gnu.org/bugs/?group=groff&func=additem) to > keep tabs on it. >From what Doug said, I don't think it qualifies as a bug, more of an idiosyncracy. I do think it needs to be documented in the info manual, though. I've opened a ticket and assigned it to Branden. -- Peter Schaffter https://www.schaffter.ca
Re: Update groff_tmac(5)
On Sat, Apr 03, 2021, Dave Kemper wrote: > On 3/28/21, Peter Schaffter wrote: > > Mom's been around for almost two decades. She's no longer the new > > kid on the block. Isn't it time this entry be updated? > > This was updated a few weeks ago in commit bbbcafc8 > (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=bbbcafc8). > The description of mom could still be refined if you have a > wording you'd prefer. I missed that commit. Thanks for drawing it to my attention. The wording is fine. -- Peter Schaffter https://www.schaffter.ca
Re: Interesting articles
> On Mar 26, 2021, at 4:03 AM, Ulrich Lauther > wrote: > > On Thu, Mar 25, 2021 at 10:30:57PM -0400, Larry Kollar wrote: >> Sometimes, my Twitter feed coughs up some cool articles, like >> this one: "Performance comparison: counting words in Python, >> Go, C++, C, AWK, Forth, and Rust” >> >> https://benhoyt.com/writings/count-words/ >> >> The Awk solution was by far the shortest by line count. Since >> the runtime for all the different solutions was a few seconds or >> less, Awk was probably the fastest because it took the least time >> to code. :D >> > What about "wc -w" ? That just counts the aggregate number of words. This challenge was to produce a sorted list of counts for each word. It seems like I coded up something like that once, I think in my first tech writing job, to see what words showed up most often. If I did, it’s on a bit-rotted tape at the bottom of a box… somewhere. — Larry
Re: Soft hyphens
Hi, Peter! At 2021-04-03T12:31:38-0400, Peter Schaffter wrote: > On Sat, Apr 03, 2021, Dave Kemper wrote: > > On 3/28/21, Peter Schaffter wrote: > > > I'm wondering if the interpretation of soft hyphens when .nh is > > > active is correct behaviour. > > > > I don't know the answer to your question, > > I got an answer from Doug McIlroy. > > "In pre-Unix roff hyphenation mode 0 turned off all breaking of words. > The original troff, however, behaved as described above, and also > broke genuinely hyphenated words in mode 0." > > > but in general, anything that will require some kind of change > > --even if it's presently unknown whether that change is to the > > software or to the documentation--should have a savannah ticket > > opened (http://savannah.gnu.org/bugs/?group=groff&func=additem) to > > keep tabs on it. > > From what Doug said, I don't think it qualifies as a bug, more of > an idiosyncracy. I do think it needs to be documented in the info > manual, though. I've opened a ticket and assigned it to Branden. Here's the current text of our Texinfo manual on this subject, before it gets into the gory details of requests (.hc, .shc, .hy, .nh, .hpf, .hpfa, .hpfcode, .hcode, .hla, .hlm, .hym, .hys). Much of this content is new or heavily revised since groff 1.22.4. I think the sentence Explicitly hyphenated words such as "mother-in-law" are eligible for breaking after each of their hyphens when GNU 'troff' fills lines. does most of the work you're asking for...but if you disagree please speak up. [...] 5.1.3 Hyphenation - When an output line is nearly full, it is uncommon for the most recent word collected from the input to exactly fill it--typically, there is enough room left over for part of the next word. The process of splitting a word so that it appears partially on one line (with a hyphen to indicate to the reader that the word has been broken) with the remainder of the word on the next is "hyphenation". GNU 'troff' uses a hyphenation algorithm and language-specific pattern files (based on but simplified from those used in TeX) to decide which words can be hyphenated and where. Hyphenation does not always occur even when the hyphenation rules for a word allow it; it can be disabled, and when not disabled there are several parameters that can prevent it in certain circumstances. *Note Manipulating Hyphenation::. [...] 5.8 Manipulating Hyphenation GNU 'troff' hyphenates words automatically by default. Automatic hyphenation of words in natural languages is a subject requiring algorithms and data, and is susceptible to conventions and preferences. Before tackling automatic hyphenation, let us consider how it can be done manually. Explicitly hyphenated words such as "mother-in-law" are eligible for breaking after each of their hyphens when GNU 'troff' fills lines. Relatively few words in a language offer such obvious break points, however, and automatic hyphenation is not perfect, particularly for unusual words found in domain-specific jargon. We may wish to explicitly instruct GNU 'troff' how to hyphenate words if the need arises. -- Request: .hw word ... Define each "hyphenation exception" WORD with each hyphen '-' in the word indicating a hyphenation point. For example, the request .hw in-sa-lub-rious alpha marks potential hyphenation points in "insalubrious", and prevents "alpha" from being hyphenated at all. Besides the space character, any character whose hyphenation code is zero can be used to separate the arguments of 'hw' (see the 'hcode' request below). In addition, this request can be used more than once. Hyphenation points specified with 'hw' are not subject to the restrictions given by the 'hy' request (see below). Hyphenation exceptions specified with the 'hw' request are associated with the hyphenation language (see below) and environment (*note Environments::); calling the 'hw' request in the absence of a hyphenation language is an error. The request is ignored if there are no parameters. These are known as hyphenation _exceptions_ in the expectation that most users will avail themselves of automatic hyphenation; these exceptions override any rules that would normally apply to a word matching a hyphenation exception defined with 'hw'. Situations also arise when only a specific occurrence of a word needs its hyphenation altered or suppressed, or when something that is not a word in a natural language, like a URL, needs to be broken in sensible places without hyphens. -- Escape: \% -- Escape: \: To tell GNU 'troff' how to hyphenate words as they occur in input, use the '\%' escape, also known as the "hyphenation character". Preceding a word with this escape prevents it from being automatically hyphenated; each instance within a word indicates to GNU 'troff' that the word may be
Re: .ss paragraph-style-footnote example, then and now
Hi, Dave! At 2021-04-03T04:23:22-0500, Dave Kemper wrote: > Hi Branden, > > I too need to amend misstatements in my original post. Unfortunately, > unlike you, I spotted them after you replied, so I've muddied the > discussion with them. > > Here's what I should have said about the original example: > > - It shows how to use .ss to insert extra (discardable) horizontal > space without overriding its normal use to also separate words and > sentences. That is, in the original example, one of the footnotes > could have consisted of more than one sentence, and groff would use > its usual spaces to separate words and sentences while still putting > the extra-wide space between footnotes. > > - It shows that .ss will take effect multiple times on the same > output line. > > So I got the details wrong, but with the above finessing I think my > main points stand. Yes, I agree that those are both desirable points to illustrate. > On 3/25/21, G. Branden Robinson wrote: > > The _main_ thing I wanted to illustrate was the use of the _second_ > > argument to .ss. > > A valid point, though I still suspect that's a straightforward enough > application of the basic .ss description that it might not warrant an > example illustrating only that. I can buy that. > > the original example _does not illustrate the use of > > the second argument to .ss_, which I think is a flaw given the > > context. In fact, the _only_ groff feature it uses is the .nop > > request. > > Therein lies a worthy philosophical question: should the Texinfo > examples strive to illustrate groff-specific features, or general > language features? The manual overall seems to presume no existing > roff knowledge, so arguably the examples should be illustrating the > roff language as a whole. The '"roff language as a whole" as implemented by groff' is how I would put it, yes. As I think I have mentioned before (but which I should document in some kind of introduction to our Texinfo manual), my model reader for the manual is a person with basic competence in the Unix shell and in natural language (English) composition, but no knowledge of typography or programming languages. In principle, such a model reader could start from that position and acquire sufficient knowledge from the manual in toto to be able to write a full-service macro package for oneself. In practice, our typical reader is neither that ignorant nor that ambitious, but each one will have different gaps in requisite knowledge. > > By changing the .nop request into a pair of spaces you can, perhaps, > > achieve the same result with only CSTR #54 features. (I say > > "perhaps" because V7 Unix troff didn't honor the .ss request for > > nroff devices at all, and Heirloom doesn't seem to either). I'll > > call this "Example 3". > > > > .ll 4.5i > > 1.\ This is the first footnote.\c > > .ss 48 > > \" 2 spaces > > .ss 12 > > 2.\ This is the second footnote. > > > > The above works on groff equivalently to the old original example. > > Good point. (Incidentally, two spaces aren't necessary; one is > sufficient.) Right. The second space is only necessary if the effect of the _second_ newline in the input text is suppressed with \c. > But I think which is better is a judgment call. Since there is a redundancy in the above, I would replace it with one of the following. .ll 4.5i 1.\ This is the first footnote.\c .ss 48 \" 1 space .ss 12 2.\ This is the second footnote. .ll 4.5i 1.\ This is the first footnote.\c .ss 48 \c \" 2 spaces .ss 12 2.\ This is the second footnote. The first is more economical, but the second is much more illustrative of end of sentence detection and what, precisely, \c does. Maybe it will suffice to have the latter only in the mailing list archives. > Were I using this technique in production code, I'd probably use the > .nop formulation because I find it cleaner than a line containing only > space (or alternatively, as above, space followed by a comment). The > .nop might still warrant a comment to explain what it's doing, but the > comment at least wouldn't need to point out the .nop's very existence. > > But in a short example illustrating a novel .ss usage, keeping the > focus on that and not bringing in more other requests than necessary > has its advantages too. I have a bias against .nop at present because I don't know how to explain it convincingly to people. "It's syntactic sugar for '.if 1'!" feels feeble to me. > Whittling your Example 3 down to only CSTR #54 features further drives > home that the implementation matters: This snippet does what you want > in groff, and does not in Heirloom troff, regardless of what extension > level you specify. Whether this is a functional change that warrants > an explicit mention in the manual, I'm not sure. This might be an > unintentional limitation (or a bug) in the original code; I don't > think anything in CSTR #54 indicates that this *shouldn't* work. > Thus, while gr
Re: Hi! Do you have a 64 bit version of Groff for windows?
At 2021-04-02T17:16:28-0400, Cool Kiwi wrote: > Hello! I am new to GNU troff and I would like to try it. But, when I > went to download it, I couldn't find a 64 bit version of groff to use. > Do you have 64 bit version (either old or new) of groff to download? > > Also, I see a bunch of files to downloads on your downloading hosting > website, sourceforge.net. Which file should I download? > > Thank you! > From New Groff User🐃 Hello from across the ditch! I'm sorry to report that presently groff is unavailable for Windows; it's supported in principle but we don't have any volunteers performing builds. If you're conversant with building GNU software under Cygwin or MinGW--or whatever is in vogue among Windows users apart from running Linux distros in VMs--maybe you could be that person! Are you interested? Regards, Branden signature.asc Description: PGP signature
Re: New extension to gropdf
Hi, Deri! At 2021-04-02T14:11:02+0100, Deri wrote: > I have been working on an extension to gropdf to draw boxes underneath > the usual output from groff. The idea is to make it easier to include > coloured frames around groff content, without having to use keeps, > particularly if you want the frame to extend over several pages. It > can also add a backgtound colour to the "paper” gropdf uses. This looks great! I haven't tried it out yet but I have definitely felt this itch when revising Larry Kollar's ms.ms document. > Included is my first attempt at an extension to the ms macros to make > it easy to include coloured frames. I have not used ms very much, nor > written macros so I'd be very grateful if people more expert than me > could improve it, particularly in regard to proper integration with > the ms macros. The only problem I can see at first glance is an easy one to deal with--name space issues. GNU ms leaves mixed-case macro (etc.) names as the user's playground, having squatted on all names without lowercase letters. > The attached archive contains the new version of gropdf. Also it > includes the macro extension file sboxes.tmac which can be used with > "-ms -msboxes", and an example of using the extension called > msboxes.ms. > > Please feel free to do whatever to improve it. Thank you! I'd like to integrate it. On top of this feature, there are others that ms.ms should bring to the reader's attention, like device tags, URL support, and colored text. The distributed file webpage.ms is a nice exhibit of what is possible with GNU ms, but it's much too tedious to keep up to date, and exhibition is no substitute for documentation. Regards, Branden signature.asc Description: PGP signature
