Re: [TUHS] Re: Documenting a set of functions with -man
On Tue, Jun 25, 2024 at 11:13:36AM -0500, G. Branden Robinson wrote: > Subject: Re: [TUHS] Re: Documenting a set of functions with -man > > At 2024-06-25T08:51:39-0400, Douglas McIlroy wrote: > > Since the C/A/T held only four fonts, there was no room for > > Courier. > ... > I had assumed that Kernighan & Ritchie got their hands on a > CAT-8 during the course of preparing _The C Programming > Language_ (1978), since it exhibited use of Courier (upright, > normal weight only) alongside Times: roman and italic, and, for > headings, bold. > ... > So maybe they had access to a CAT-8 after all, and used a > whopping 5 different font plates. Or they used a CAT-4 and had > to compose many pages in two passes. That would have been > mightily tedious. I've never been anywhere near a CAT phototypesetter, but I doubt that any phototypesetter was capable of handling all the phototypesetting paper needed to print a book in one pass -- either the input or the output cassettes holding the paper had limitations (although I know one company that put their VIP phototypesetters inside a darkroom and let the film or paper run out into a big box, but they still needed to have someone replace the input cassettes). We would generally set no more than a chapter at once. Changing fonts between runs like that was no big deal. The earliest phototypesetter we had, a Compugraphic (I think a 2940, in 1971), only allowed one or two fonts at a time. I think that it actually signalled the operator in the middle of a job when a new font was needed (that's a vague memory). In any case, I think it was common for publications to use more fonts than a machine could handle at one time. Lots of things were patched in at paste-up time. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 Temporary residence: 36 Locust St., Kitchener, Ontario, Canada N2H 1W7 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: paragraph-at-once breaking algorithm (was: Re: *roff hyphenation trivia challenge)
On Tue, Apr 02, 2024 at 03:29:28PM -0500, Dave Kemper wrote: > Subject: paragraph-at-once breaking algorithm (was: Re: *roff hyphenation > trivia challenge) > > On Tue, Apr 2, 2024 at 2:23 PM Steve Izma wrote: > > I used TeX and LaTeX [...] and the oversetting of lines caused > > by the periodic failure of the paragraph-justification algorithms > > drove me nuts. [...] The many lines that overset by only a > > few points made proofreading really difficult. That's why I'm > > suspicious of trying to add or replicate these algorithms in > > groff. > > It would be interesting to know if someone with experience using the > Heirloom troff implementation of this algorithm (and with a good > typographic eye) has noticed the same problem there. That is, is it a > bug in the algorithm itself, or in TeX's implementation of it? Good question. One experiment might be to choose a long paragraph and typeset it in TeX, Heirloom troff, and groff and see what the differences are. Yes, I know, I should probably walk the talk, but I don't have Heirloom troff installed and ... -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: *roff hyphenation trivia challenge
On Tue, Apr 02, 2024 at 01:29:05PM -0500, G. Branden Robinson wrote: > Subject: Re: *roff hyphenation trivia challenge > > At 2024-04-02T13:42:59-0400, Steve Izma wrote: > > On Tue, Apr 02, 2024 at 06:51:51PM +0200, Tadziu Hoffmann wrote: > > > Subject: Re: *roff hyphenation trivia challenge > > > > > For "antidisestablishmen\%tarianism", groff prints > > > > > > antidisestablishmen- > > > tar- > > > i- > > > an- > > > ism > > > > > > (which I think is strange), while TeX and Heirloom troff print > > > > > > antidisestablishmen- > > > tarianism > > > > > > which I think is the only reasonable way of handling this case. > > > > I disagree. > > Oops. I misread Tadziu's example, and hallucinated a leading `\%` in it. > > If there is no _leading_ `\%`, then infixed `\%` escape sequences can > only add hyphenation points; they cannot remove them. AIUI. Hi Branden, Thanks for the response. But I'm not clear about your comment here. I get the same results as Tadziu, i.e., the hyphenation points prior to the \% disappear. And now, testing with printf '.ll 1n\n\%antidisestab\%lishmentarianism\n' | nroff -Wbreak | cat -s I get the same results: antidisestab‐ lish‐ men‐ tar‐ i‐ an‐ ism This seems to mean that the function of a leading \% only works until a subsequent \% -- but then the behaviour is the same even without a leading \%. In decades of using groff I've never noticed this. It's a good thing you've started this discussion. > > Also for \% at the beginning of a word, I rarely use this. > > I use it frequently in man(7) documents, because the `hw` request is not > portable/reliable (in theory). Also there's no mechanism for removing > these, so if we tolerate/encourage their use, doing so deals a blow to > reliable/predictable batch rendering.[1] Good point. > So let me amend my claim. > > I think it's weird that > > > > [f]or "antidisestablishmen\%tarianism", groff prints > > > > > > antidisestablishmen- > > > tar- > > > i- > > > an- > > > ism > > whereas > > $ printf '.ll 1n\nantidisestablishment\n' | nroff -Wbreak | cat -s > an‐ > tidis‐ > es‐ > tab‐ > lish‐ > ment > > seems like well-behaved formatting to me. > > ...except for the lack of a break point after "ti", of course. > But I'm comfortable assuming that the discrepancy here is a > limitation of the TeX hyphenation system aggravated by > English's polyglot morphology. Since most of my use of groff for books over the last thirty years has been non-fiction (mostly scholarly) material, much of the terminology used doesn't end up in hyphenation lists -- sometimes the words are just too new or rare. The same applies to the preponderance of proper names in scholarly material. Often most hyphenation points were correct but, especially for long words, a point that would make all the difference towards getting a properly spaced line would be missing, as above with "ti-dis". That's why it's convenient to use \% to add to hyphenation points that arise from hyphenation logic as opposed to exception lists. But now that I think about it, we would often prefer to use .hw in these cases because that allows you to define only what is desireable. I should really go back through my various book projects and do some research here. > Is TeX's hyphenation algorithm defeated by the pathological case of > "antidisestablishmentarianism", and groff's implementation of it > "recovers" differently? I don't remember enough about TeX to answer this. I used TeX and LaTeX up to about 15 years ago to typeset about 20 books from computer science conferences and the oversetting of lines caused by the periodic failure of the paragraph-justification algorithms drove me nuts. That was not due to hyphenation problems, but something to do with limits to word-spacing that I probably didn't understand properly. The many lines that overset by only a few points made proofreading really difficult. That's why I'm suspicious of trying to add or replicate these algorithms in groff. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: *roff hyphenation trivia challenge
On Tue, Apr 02, 2024 at 06:51:51PM +0200, Tadziu Hoffmann wrote: > Subject: Re: *roff hyphenation trivia challenge > For "antidisestablishmen\%tarianism", groff prints > > antidisestablishmen- > tar- > i- > an- > ism > > (which I think is strange), while TeX and Heirloom troff print > > antidisestablishmen- > tarianism > > which I think is the only reasonable way of handling this case. I disagree. I prefer groff's behaviour because I don't ever want correct hyphenation points to be ignored. Using \% is almost always a correction to the hyphenation logic. If I'm typesetting a book, corrections to a paragraph can happen at any time up to the final delivery of the files for printing. Even a single-letter correction in a paragraph can change the line breaks and make the corrected hyphenation unnecessary and inappropriate. In that case I don't want to have to go around searching for hyphenation corrections in order to revert to a greater choice of hyphenation points. However, that means that the above example removes correct hyphenation points before the added correction. If a bug is going to be fixed, I suggest that the correct points on both sides of the \% should be retained. Also for \% at the beginning of a word, I rarely use this. If I don't want a word hyphenated at all, then it's likely that I don't want it hyphenated anywhere in the document. And in such cases I would add .hw antidisestablishmentarianism to the document once (or, preferably, to a local tmac file used for the project). This may not be important for man page authors, but it's very important in a production environment. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: the Courier font family and nroff history
On Sun, Mar 24, 2024 at 03:39:45PM -0400, Peter Schaffter wrote: > Subject: Re: the Courier font family and nroff history > > On Sat, Mar 23, 2024, Steve Izma wrote: > > I tend to believe that Linotype was the driving force in the > > release of a complete package for corporate typesetters: the > > Linotronic 202 (or something like it) driven by Adobe's new > > PostScript rasterizer (RIP), using ITC fonts, and with two > > choices of front ends: either a very expensive inputting and > > editing terminal made by Linotype or else a much cheaper (almost > > hobby-level) Macintosh. > > I worked in a shop in the early '90s that used a Linotronic RIP > connected to two dedicated Linotype terminals and several MacIIfx > computers. I wouldn't call those Macs cheap or hobby-level, not by > a long shot. :) Hi Peter, You're right about the the 1990s-era Macs, but I'm trying to recall the situation around 1985. I certainly couldn't afford a Mac at that time but I'm pretty sure that small-to-medium-sized printshops could, since they'd be so much cheaper than the Linotype devices. But the Linotype frontends were essentially single-purpose ones, weren't they? So they would have become obsolete quickly. I also recall that Macs were the favourites of art-school students starting in the mid-1980s because the machines were more oriented towards graphics software than the early Windows systems. I think this was a factor in driving development of Macs to the point that in the 1990s their sophistication and prices sky-rocketed. Those students became the scriptorium scribes for ad agencies and must have had an influence in the technological shifts in the design industry. But to me, the early Macs were only a couple of steps above video-game devices. Do you remember what the costs of the Linotronic machines would have been? At WLU Press, we were able to do things much more cheaply with PCs running Unix-like software (MKS Toolkit) driving a nearly obsolete Merganthaler VIP up until about the mid-1990s. That was for high-quality output. For quick-and-dirty work to produce low-printrun scholarly monographs we used SQTroff on 386/ix (I think it was called) running fairly good laser printers. We also sometimes used SQTroff as ported by MKS to MS-DOS up until I got the hang of groff and linux (1996?). -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: the Courier font family and nroff history
On Sat, Mar 23, 2024 at 07:13:38PM -0400, James Cloos wrote:
> Subject: Re: the Courier font family and nroff history
>
> So blame Jobs for Courier as the monospace family and for
> Times(12) as the serif family. And for Helvetica as the Sans
> family.
I think we need to remember the third party in this development:
Merganthaler-Linotype. In my memory, it was by far the most
powerful of the group that announced a joint project around 1985.
The International Typeface Corporation (ITC) was also involved,
probably because they were producing the most desirable new
designs for the advertising and publishing industry -- they might
even have had a head start in digitizing fonts.
I tend to believe that Linotype was the driving force in the
release of a complete package for corporate typesetters: the
Linotronic 202 (or something like it) driven by Adobe's new
PostScript rasterizer (RIP), using ITC fonts, and with two
choices of front ends: either a very expensive inputting and
editing terminal made by Linotype or else a much cheaper (almost
hobby-level) Macintosh.
Apple also offered one of their printers as a proofing device so
as not to waste photgraphic materials (Doug McIlroy almost under
estimates the hassle that would result if you made a mistake on
typographic photo paper). Many small printers that couldn't
afford the Linotronic cheated by using Apple printers (I think
they were fairly early laser printers) for output. The resulting
quality can mostly be described as cheap.
This was Merganthaler-Linotype's attempt to dominate the big
commercial photo-typography market (including big newspapers) to
head off other companies developing CRT-based photo-typographers,
especially Autologic and maybe Compugraphic. I can't readily find
info on this (Frank Romano's "History of the Linotype Company"
would have it, but I can't get at this book easily), so I'm
straining my memory to the limit.
I suspect that Apple had nothing to do with font choice.
Everyone, especially newspapers, wanted Times Roman because it
was the best way of cramming more words onto the page. There used
to be a measure of the overall horizontal space required by any
particular font -- I think it was called alphabet length or
something. I've never come across a readable, non-condensed serif
font that takes up as little space as TR. Newspapers and
magazines needed it. So did many book publishers trying to
minimize the number of signatures coming off the press.
Unfortunately, my library of books on typography and old issues
of U magazine (a mouth-wateringly wonderful publication of the
ITC) got severely damaged in a house fire a few months ago.
Otherwise I would have done due diligence and checked these
memories more thoroughly.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net cellphone: 519-998-2684
==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
from Plato to Darwin*, 1996
Re: [bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position
On Sun, Jan 14, 2024 at 05:23:28PM -0500, G. Branden Robinson wrote: > Subject: [bug #64285] [troff] \D't' (set line thickness) drawing command > alters drawing position > > Update of bug#64285 (group groff): > ... > > If you think fixing a crazy (but well known and documented) > > "feature" is more important than maintaining 30 years of > > groff compatibility, > > I pretty much do, yeah. Every crazy feature we keep dragging > along with us makes the language harder to acquire, remember, > and work with. Where the size of the impacted user community > is small, as it surely is here--I fear the most prolific users > of drawing escape sequences outside of macro packages or > preprocessors are cargo cultists--it seems an easy choice to > make. I agree that this should be fixed. But I can't imagine any situation where the current behaviour can be considered a feature. It's more likely that everyone using to the \Z'' fix is doing so as a workaround and any such documents would be unaffected by improving the \D't' behaviour. I don't understand your reference to "cargo cultists". There are scads of situations where one doesn't want to bother with macro packages, e.g., one-page posters, flyers, announcements. I've probably made hundreds of them with groff. Those are the kinds of situations where one draws lots of lines and where this bug becomes a nuisance. The term "cargo cult" is almost always used in a pejorative way. But I've been to Vanuatu and it's clear to me that the real history of cargo cults is a history of anti-colonial movements that engaged in communal, ritualized resistance, not so-called superstition. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net cellphone: 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: Baffling accented glyphs issue
On Sat, Aug 26, 2023 at 04:47:02PM -0400, Peter Schaffter wrote: > Subject: Baffling accented glyphs issue > > chats_1 contains a single accented glyph (î). The glyph is mangled > in the ps output. chats_2 contains the same glyph plus an additional > one (é). Here, neither glyph is mangled in the output. The same > oddity occurs with the pdf driver and with -Tutf8. > > Even more peculiar is that the introduction of *any* accented glyph > into the source file (in addition to the originally mangled glyph), > even one commented out at the end of the file, fixes the problem > with the initial mangled glyph. Try adding > > .\"ô > > or similar to the end of chats_1 and processing it to see what I mean. > > I'm not sure if this is new behaviour because I can't > recall ever creating a document with only one accented glyph. Hi Peter, I've noticed this behaviour only lately myself. I think Bjarni's explanation accounts for it. But your email encoded the texts as iso-8859-1, not utf8, so when I saved the file and ran it there wasn't a problem. When I created my own file with the single accented character as utf-8 I got the same problem as you indicated. Using -K utf8 solves it. I guess I rarely have files with only a single example of a utf-8 character. I use the utf-8 open and closing double quotes very frequently so that probably makes the difference to preconv. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: Selecting Papersize
On Sun, Jul 09, 2023 at 12:33:01PM -0500, G. Branden Robinson wrote: > Subject: Re: Selecting Papersize > Possibly, his answer to the question of how to handle a laser > printer with multiple trays serving different paper formats > would have, in 1984 or so, have been "write a device > description for each tray; that way you know what you'll be > getting". > > I could be wrong, because one of the things such an approach > forecloses is the possibility of printing (in one run) a > document that employs multiple paper formats. An example that > is certainly _not_ a contrivance is the simple matter of > rotating the format, so that one could fit really wide tables > onto some pages of a document using U.S. letter or A4 paper. I'd like to return to this issue of changing paper sizes with single documents, since I think I have a different use case. In my decades-long experience in typesetting scholarly material (the most likely source of very wide tables) I've never found the need to change paper size to accommodate such tables. Possibly, this is because editors force authors to rethink and re-cast their tables to be more easily digestible, i.e., so that the reader can see the data relationships in a simple scan. Also, it's pretty easy to rotate a table on a page so that it reads landscape but the other elements on the page that need to remain portrait -- like headers or footers -- remain in their proper place. This, I think, makes rotating an entire page in mid-document unnecessary or possibly even bad design. On the other hand, there are probably good usage cases for non-academic mixing of page sizes, but that raises the question: what's the relationship between changing paper size mid-document and getting the the printer to change trays? As far as I can tell from my experience with PostScript printers, an unexpected paper-size change (e.g., asking for Legal from a tray that holds Letter) causes the printer to pause with a panel message asking for the operator to switch paper sizes for that tray. I think I've had difficulties even when the printer has the proper size in a different tray. So I don't think we can trust all printers to automatically switch trays. In any case, wouldn't it be safer to assume that a paper-size switch should be accompanied with a paper-tray switch? Also, I think it would be useful to switch trays -- e.g., from plain paper to glossy paper -- in mid-document for the output of high-quality images on the same size of paper. That would make something like a "\X'ps: papertray xx'" or "\X'ps: InputSlot=xx'" very useful. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: PostScript viewers (was: interviews with groff developers)
On Sat, Aug 05, 2023 at 09:52:26PM -0400, Douglas McIlroy wrote:
> Subject: Re: interviews with groff developers
>
> But PostScript seems to be barely hanging on by its
> fingernails. I uninstalled my Ghostly .ps reader on one of my
> computers and have been unable to reinstall it, due to internal
> inconsistencies. If anybody has had recent success installing
> any PostScript reader on a PC, I'd like to hear about it.
Okular on Debian 11 still reads my PostScript files. I continue
to use grops in all my groff work (almost every day).
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
from Plato to Darwin*, 1996
Re: a morsel of groff 1.23.0 status
On Wed, Jul 05, 2023 at 07:31:50PM -0500, Dave Kemper wrote: > Subject: Re: a morsel of groff 1.23.0 status > > On 7/5/23, G. Branden Robinson wrote: > > May I be excused some > > pride in our delivery of over 400 bug fixes and 150 automated tests? > > Fully justified. I'm glad it's finally out in the world. Thank you > for your tireless work in making groff more featureful, more portable, > better documented, and less buggy. Yes, all this work is very much appreciated. Thanks again. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
"recently uncovered" Bell Labs Unix bibliography
Some of you might be interested in a note from today's Tex Users Group news: Nelson Beebe reports a recently uncovered large Bell Labs bibliography about Unix spanning 1972 to 1980. It is available at https://www.math.utah.edu/pub/tex/bib/unix.bib. There is a SQLite3 version of the bibliography at https://www.math.utah.edu/pub/tex/bib/unix.db. See https://www.math.utah.edu/~beebe/talks/#2009 for the documentation of this format. There are numerous references to nroff and troff in it. Part of my interest in this comes from just having finished Brian Kernighan's "Unix: A History and a Memoir", which was thoroughly enjoyable to read. (Lots of good stories about Doug McIlroy in it, as well.) -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: widows vs orphans
On Thu, Jun 15, 2023 at 03:40:47PM -0500, G. Branden Robinson wrote: > Subject: Re: widows vs orphans > > At 2023-06-15T13:41:38-0500, Dave Kemper wrote: > > Although Wikipedia says there's no agreement on the > > definitions of "widow" and "orphan" > > (http://en.wikipedia.org/wiki/Widows_and_orphans), web > > research has led me to conclude that there's a stronger > > consensus than Wikipedia credits: that orphans are at page > > bottom and widows at page top. > > This convention is difficult for me to internalize. > > > As two data points, these are the definitions used by > > typography expert Robert Bringhurst (as quoted long ago on > > this list by Steve Izma > > (http://lists.gnu.org/r/groff/2004-03/msg00091.html), himself > > a knowledgeable and experienced typographer), > > I have his book and started to read it. The early material has > interest but is not of utility to me as a groff developer. > Perhaps my organs of artistic appreciation are withered and > insensitive. I hope it doesn't sound too aggressive for me to suggest that someone who is regularly typesetting for *print* (especially books and book-like productions) would find Bringhurst's observations and suggestions useful on a daily basis. But most of his ideas have little application for material meant to be presented on a character display (i.e., man pages). This especially applies to the very high significance of white space on a printed page -- it represents important boundaries to the text, where the mind gets a chance to take a breath and the amount of white space relates to the kind of break one is supposed to take between digesting the concepts in the text. It's really hard to do this in a subtle way on a mono-spaced character display. But I think groff is absolutely wonderful for allowing control over white space (usually to one-thousandth of a point) on a printed page. Much of Bringhurst's book is about how to provide helpful rhythms of thinking through good typography. Thanks to Dave for reminding me of the exchange about widows and orphans that took place almost twenty years ago. One of its main points was to argue in favour of final aesthetic adjustments being made by humans as opposed to algorithms. I was glad to have my memory refreshed about this, especially in respect to recent debates about the "paragraph-at-once" algorithms (which have never worked in a satisfying way to me when I have needed to typeset with TeX). To clarify Bringhurst's suggestion that "widows" should be accommodated but "orphans" need not be worrisome, I'll quote again the passage from his book: The typographic terminology is telling. Isolated lines created when paragraphs *begin* on the *last* line of a page are known as *orphans*. They have no past, but they do have a future, and they need not trouble the typographer. The stub-ends left when paragraphs *end* on the *first* line of a page are called *widows*. They have a past, but not a future, and they look foreshortened and forlorn. It is the custom -- in most, if not all, the world's typographic cultures -- to give them one additional line for company. (Robert Bringhurst, *The Elements of Typographic Style*, Hartley & Marks, 2012) Note that this is about short lines, not single words, although somewhere in the discussion someone has mentioned the (usually good) idea of avoiding single words at the end of paragraphs. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: drawing commands have no impact on diversion height
On Thu, Jun 08, 2023 at 02:29:04PM -0400, Steve Izma wrote: > Subject: Re: drawing commands have no impact on diversion height > > On Fri, Jun 02, 2023 at 01:35:22PM -0500, G. Branden Robinson wrote: > > Subject: drawing commands have no impact on diversion height > > > > I find myself offended by the fact that \D drawing commands update the > > diversion width register `dl`, but have no impact on the diversion > > height register `dn`. When I first tested this with the following modified script: > > .sp 1i > Hello, world. > .sp > Pardon me a moment while I create a diversion. > .br > .di DD > ' \" \D'c 1i' > .nf > \H'72'This is a test.\H'0' > Line 2 of this test. > .sp -2v > Line 3 of this test. > .br > .di > .fi > Okay, I'm back. > .sp > Now, let's have a look at that diversion; > it's \n(dn tall by \n(dl wide. \" 12000, 72000 in PostScript > .sp 0.5i-0.5v > .DD > This line starts after the output of the diversion. > .sp 0.5i > All done. > I didn't get increased clarity on the \n[dn] problem (still working on it in my copious spare time), but I was perplexed by this: > *But* the ending of the diversion seemed to swallow the EOL of > the diversion's last output line, or the .br, or something. As a > result, the first line after the diversion acts as if it's a > continuation of the input to the diversion (see attached PS > file). If I add a .br immediately after the .DD, I get the > expected results, but that seems unnecessary and unpredictable to > me, almost as if a .chop got silently applied by .di I've now realized that this problem resulted from the diversion being re-processed due to the lack of a .nf during it's output in both Branden's and my script. In other words, when the diversion is output in fill mode, all line endings are removed and line justification is redone. Still experimenting with \n[.h] and \n[dn]. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: drawing commands have no impact on diversion height
On Thu, Jun 08, 2023 at 08:30:53PM -0500, G. Branden Robinson wrote: > Subject: Re: drawing commands have no impact on diversion height > At 2023-06-08T14:29:04-0400, Steve Izma wrote: > > > *But* the ending of the diversion seemed to swallow the EOL of the > > diversion's last output line, or the .br, or something. As a result, > > the first line after the diversion acts as if it's a continuation of > > the input to the diversion (see attached PS file). If I add a .br > > immediately after the .DD, I get the expected results, but that seems > > unnecessary and unpredictable to me, almost as if a .chop got silently > > applied by .di > > There might be a confounding factor. Note the part about diversions. > > 5.11 Manipulating Spacing > = > > A break causes the formatter to update the vertical drawing position at > which the new text baseline is aligned. You can alter this location. > > -- Request: .sp [distance] > Break and move the next text baseline down by DISTANCE, or until > springing a page location trap.(1) (*note Manipulating > Spacing-Footnote-1::) If invoked with the no-break control > character, 'sp' moves the pending output line's text baseline by > DISTANCE. A negative DISTANCE will not reduce the position of the > text baseline below zero. Inside a diversion, any DISTANCE > argument is ignored. The default scaling unit is 'v'. If DISTANCE > is not specified, '1v' is assumed. Branden, Thanks for pointing this out, but I think I have lost track of the discussions on this list about recent changes to documentation. The above section looks like it's from the GNU Troff Manual, but it's not in the version I have, which is "The GNU implementation of troff", edition 1.23.0. Where would I find the above? In any case, I'm sure I've not seen this discussion of DISTANCE being ignored within a diversion, although many times I've been confounded trying to control the vertical space at the beginning of a diversion. As well, I'm not sure that this cautionary note about .sp addresses the issue with the .br command apparently being ignored. Does anyone have more insight about this? I will also experiment with the \n[.h] register to see if it keeps track of drawing motions that go below the baseline. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: drawing commands in groff(7) (was: undiagnosed pic error)
On Tue, Jun 06, 2023 at 03:07:07PM -0500, G. Branden Robinson wrote:
> Subject: drawing commands in groff(7) (was: undiagnosed pic error)
> \D't n'
> Set line thickness of geometric objects to to n basic units. A
> zero n selects the minimal supported thickness. A negative n
> selects a thickness proportional to the type size; this is the
> default.
>
> Comments?
Is it worth pointing out here that \D't n' is not zero-width?
e.g.:
.sp 1i
.po 1i
.ps 12s
.ll 24P
\D'l \n[.l]u 0'
.br
\D't .5p'\D'l \n[.l]u 0'
.br
In fill mode, the second drawing command produces this error:
troff: thick:7: warning [p 1, 1.2i]: can't break line
The troff output:
x T ps
x res 72000 1 1
x init
p1
V84000
H72000
md
DFd
s12000
Dl 288000 0
n12000 0
V96000
H72000
Dt 500 0
Dl 288000 0
n12000 0
x trailer
V792000
x stop
shows that \D't .5p' has a width of 500 units, which is output as
a 500-unit space. For as long as I can remember, I've needed to
use this instead:
\Z'\D't .5p''\D'l \n[.l]u 0'
I'm pretty sure this anomaly has been discussed on the groff list
before, but I don't know of any explanation in the documentation.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
from Plato to Darwin*, 1996
Re: drawing commands have no impact on diversion height
On Fri, Jun 02, 2023 at 01:35:22PM -0500, G. Branden Robinson wrote: > Subject: drawing commands have no impact on diversion height > > I find myself offended by the fact that \D drawing commands update the > diversion width register `dl`, but have no impact on the diversion > height register `dn`. > > Nevertheless, all of DWB 3.3, Heirloom Doctools, and GNU troff behave > this way. > > But it seems pretty unhelpful to me. If a drawing command inside a > diversion increases its maximum vertical extent, the formatter should > tell me that, but it doesn't. Instead it appears to count only text > baselines. > > Can someone defend this behavior? I haven't seen any responses to this yet, but it seems pretty important to me. As far as I can tell, the height of a diversion is only calculated by \n[.v] values. If spacing is reversed within the diversion and the end of the diversion occurs before the high-water mark in the diversion, \n[dn] seems to contain only the difference between the vertical starting point of the diversion and the vertical position of the last output line. Nothing I tried with either \D commands or even \H (to artificially increase the height of the current font) made a difference to the value of \n[dn]; it only registered values in terms of \n[.v]. I modified the following for testing: > Hello, world. > .sp > Pardon me a moment while I create a diversion. > .br > .di DD > \D'c 1i' > .br > .di > Okay, I'm back. > .sp > Now, let's have a look at that diversion; > it's \n(dn tall by \n(dl wide. \" 12000, 72000 in PostScript > .sp 0.5i-0.5v > .DD > .sp 0.5i > All done. .sp 1i Hello, world. .sp Pardon me a moment while I create a diversion. .br .di DD ' \" \D'c 1i' .nf \H'72'This is a test.\H'0' Line 2 of this test. .sp -2v Line 3 of this test. .br .di .fi Okay, I'm back. .sp Now, let's have a look at that diversion; it's \n(dn tall by \n(dl wide. \" 12000, 72000 in PostScript .sp 0.5i-0.5v .DD This line starts after the output of the diversion. .sp 0.5i All done. Note the .sp -2v, which caused the diversion to end above the high-water mark and resulted in \n[dn] registering only 1 line height. *But* the ending of the diversion seemed to swallow the EOL of the diversion's last output line, or the .br, or something. As a result, the first line after the diversion acts as if it's a continuation of the input to the diversion (see attached PS file). If I add a .br immediately after the .DD, I get the expected results, but that seems unnecessary and unpredictable to me, almost as if a .chop got silently applied by .di Using groff 1.22.4 on Debian Bullseye. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996 test.ps Description: PostScript document
Re: A file suffix for troff's output.
On Mon, Apr 10, 2023 at 04:37:07PM +0100, Ralph Corderoy wrote: > Subject: Re: A file suffix for troff's output. > > Some programs can act on the pattern to filenames, e.g. > make(1). It can be told how to turn a .tr into a .set and a > .set into a .ps. Even though all three are text files, it's > useful to suffix them descriptively. Thanks for the clarification, Ralph and Alejandro. I see that I was side-tracking a bit and not recognizing the relevance of make(1) to the discussion. For the actual production of complex documents like books and journals I organize the parts of the project into sub-directories and just use fairly simple shell scripts to process them. I've considered using make, but long ago got into the habit of shell scripts. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: A file suffix for troff's output. (Was: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4)
On Mon, Apr 10, 2023 at 10:03:34AM +0100, Ralph Corderoy wrote: > Subject: A file suffix for troff's output. (Was: pdfroff in groff > 1.23.0.rc3 changes compared to 1.22.4) > > troff chapter.tr >chapter.set > grops chapter.set >chapter.ps > > Short, simple, not already widely used by another program, > pronounceable, a clear derivation. Maybe I'm mis-reading the problem here, but Postscript output from groff in my experience has always been a temporary file. I am usually working on several projects at once, with output file names that never seem to clash, so all of my output files from groff processing automatically go to /home/ps. This - works as a kind of tmp directory (but clear of all system tmp files); - is under the /home hierarchy so can be easily added to backups if I feel it necessary (almost always not); - can be easily cleared out, either entirely or according to age (presuming age = possible obsolescence); - follows what I think is a clearer way of defining the nature of a file: it's location within the filesystem hierarchy, identity defined by its parent's name (i.e., "ps"); - utilities like ps2pdf do not require suffixed files for input validation; - it's worked for me with virtual no problem for over 30 years (but I'm only one test case, I guess). So why all the fuss? One could also argue that a Postscript file is a text file and I avoid .txt extensions as much as possible. After all, as far as I can tell, .txt was a Microsoft invention, another step in Bill Gates's war to obstruct Unix conventions. And under Unix one could reasonably argue that an un-suffixed file outside of bin directories was by default a text file. The same argument holds for putting troff source files into a tr subdirectory of your project directory. That keeps the main project directory uncluttered. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: groff for epub/e-books (was: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered)
On Wed, Feb 22, 2023 at 08:26:19PM -0600, G. Branden Robinson wrote: > Subject: groff for epub/e-books (was: groff 1.22.4 mandb 2.11.2 man -H tbl > not rendered) > > [And prefer "open" ePub, vs *proprietary* Adobe PS and PDF, > > PDF is an international standard these days,[1] though I wonder > if it isn't a captive one by Adobe as "Office Open XML" is by > Microsoft.[2] However, it doesn't mean that Adobe's programmers don't make mistakes when working on this proprietary code. When trying to work with PDFs using open source software I often find that I need to use pdftk or something similar to re-distill PDFs that don't behave properly. These are always from Microsoft or Apple platforms. > > as it's zipped html readable in browser addons, or vim or > > less(/open) if desperate. Get on it FSF!] > > I _do_ think ePub would make a good application for groff, and > it's something I've given some thought to. One thing EPUBs > often need to do is reflow and re-render the text, because > someone make take a tablet or phone display and rotate it > frequently. EPUBs _can_ do this, but in my experience, they > often do it poorly. Are there two different discussions going on here? I think I hear some people talking about converting groff files to epub and others perhaps hinting that groff should be the engine driving ebook readers. In my experience, going from arbitrary groff source files to the kind of HTML code needed for epubs (especially the increasingly mandated accessible epubs) is not worth the effort, unless the groff source code is done in a highly structured way (i.e., essentially following XML rules). I would love it if the second possibility were to be undertaken. I read a lot of epubs and they are rendered poorly, especially in respect to hyphenation (if it even exists on the particular platform you have), but also in respect to control of margins, line spacing (e.g., if footnote numbers occur in a line), and if anything other than straight, paragraphed text needs to be displayed. And even pagination itself is usually terrible. If I see extra white space at the bottom of a page, my sub-conscious reading-comprehension starts to wind down, assuming I've reached the end of a chapter or section. Unnecessary and distracting white space shows up a lot in epub rendering. Since I still work in publishing, sales of epubs are very important to me. In Canada, at least, and I think everywhere else, sales have plateaued at less than 20% of a publisher's income. In many cases publishers have stopped selling them actively because the encryption process stymies too many users and takes up too much staff time for customer service. In other cases, publishers have started boosting the prices of epubs to just below that of print books because they can't cover costs. For a long time, Amazon and Apple (in particular) manipulated the market to keep prices low and keep the majority of the sales income, but now their control over this is slipping and prices are going up for everything other than pulp fiction. > PDF apparently doesn't handle this well, which is one of the > reason a bunch of "e-book" document formats popped up. I've > been frustrated with every one I've encountered. In the academic world, epubs render tables, references, footnotes, figures, etc. in extremely awkward ways, and in many cases people prefer PDFs for their increased readability, but on anything smaller than about a 7-inch screen, PDFs can also be very painful. I still prefer reading on paper and I still prefer typesetting for paper as well. > I have noticed that groff generally renders so fast on modern > hardware that I'll wager that a "groff ePub" document could > ship the document _source_ and an "ePub reader" for it would > provide the entire groff rendering system. (For documents that > are slow to render even with this approach, you could > straightforwardly cache the intermediate output for each > display orientation.) I don't see how this would require any > architectural changes to groff itself, and would have many > advantages, particularly for document source accessibility, > archivability, preservation, and "share-alike" licensing > properties. > > (So major publishers would probably hate it and oppose it with > fury.) Publishers wouldn't even notice. It's the manufacturers of ebook readers who make this difficult. One way to start, probably, would be to attach an e-ink screen to a Raspberry PI and run groff to display the HTML from the epub, or the native groff document. That shouldn't be too hard. It might be a lot easier if someone would convert groff into libraries for something like python. That would probably be more efficient in handling the display than using pipes between processes. I'd love to have a python-groff module. It would
Re: Nils-Peter Nelson, sqtroff, and groff history
On Tue, Dec 13, 2022 at 06:29:19PM -0600, G. Branden Robinson wrote: > Subject: Nils-Peter Nelson, sqtroff, and groff history > Some people might find the following messages, first from Nils-Peter > Nelson and then Liam R. E. Quin, of interest. They're posts from 1996 > to the comp.text USENET group. (Je me souviens, DejaNews!) I'll try adding a couple of other related, possibly interesting items. > At any rate, SoftQuad continued to develop sqtroff for several > years. The SoftQuad version has kerning, long character names, > long macro, register, string and special character names, and > an ASCII intermediate format that's moderately readable and > amenable to awk/perl/sed. As Liam implies later, sqtroff had a very useful (albeit extremely verbose) trace option, unlike anything in groff. I miss it. > I think it was in 1988 that I discovered that James Clark was > working on groff, and pressured SoftQuad, who very kindly sent > him a manual for the then latest sqtroff. As a result, groff is > fairly compatible with sqtroff 2.9.1, the then shipping > version. Question (if this ever gets to Liam, who I think is living somewhere in eastern Ontario): who pressured who? At first I thought that this means that Liam pressured SoftQuad to help James Clark, but this also could have the opposite meaning. I clearly remember hearing from SoftQuad's chief programmer, David Slocombe, that there was significant sharing of concepts in this relationship. SoftQuad had done a huge amount development work on the source code, which I sure saved James much effort. I remember David telling me once how he'd spent an entire weekend rewriting tbl, since he was unhappy with some of its core algorithms. > Today, you can use groff on linux (which was what the original > poster asked for, I think), and sqtroff on most commercial Unix > platforms. > > I don't believe we could sell you source for sqtroff, because > of the complexities of whatever remains of our arrangement with > AT At some point during my time with Mortice Kern Systems (better known as MKS), I helped negotiate the licensing of the SoftQuad code for a port to Windows. This was probably around 1987. MKS successfully sold this product until 1994 or thereabouts. By that time I was working at Wilfrid Laurier University Press. We probably started using the Windows version of sqtroff in the late 1980s and then switched to the SoftQuad Unix version in the early 1990s when we were able to afford a 386-based Unix system. We used that on hundreds of projects (mostly academic books and journals) until switching over to groff around 1998. After that we used groff for many more books and journals, until we got to the point where the only people who could be hired were so entrenched in WYSIWYG that the Unix paradigm was beyond them. I continued to use groff for complex technical academic texts and for some administrative documents until I retired from WLU Press in 2015. > One was sqtroff, and this was best for people who had > PostScript printers and/or wanted to develop their own macros. > It used (back then) to have some problems with -me and -ms, > because it derived from the AT version, where -mm was used > most. > ... > On balance, we used to sell sqtroff to people developing macros, I found that none of the supplied tmac packages were suitable for the complexities of our academic work, so I started writing my own macros as soon as I got a copy of sqtroff. SoftQuad provided lots of examples of custom macro sets, and these were of a very different style than ms and me, etc. The style was heavily influenced by XML, so that macros usually operated on blocks of text, with matched opening and closing macros, e.g., .pp(( text ... .pp)) > I've been using sqtroff recently together with David > Megginson's NSGMLS.pm to typeset a book from SGML. A number of Canadian publishers used sqtroff during the 1990s, largely because they either employed or contracted people who were friends of the SoftQuad people (e.g., McClelland & Stewart), or else because they were involved in co-operative efforst with SoftQuad (Coach House Press, Porcupine's Quill -- who still use groff on a high-quality 1990s Linotron phototypesetter). Besides my work at WLU Press, I've used both sqtroff and groff on scores of books I've typeset for Between The Lines, a publishing co-operative I helped to start up in 1977. > Our (SQ's) income from sqtroff is negligible at this point as > far as I know. By the early 1990s I had the impression that SoftQuad was making most of its money doing custom documentation for the U.S. military and large corporations. They weren't happy about that, but their financial circumstances were difficult. As Liam says, their SGML and XML editors and tools later became more important. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
Re: 3-word compound adjectives; the return of the '-'
On Wed, Oct 12, 2022 at 04:47:27PM +0200, Alejandro Colomar wrote:
> Subject: 3-word compound adjectives; the return of the '-'
>
> a) block device-based filesystems
> b) block-device-based filesystems
> c) block- device-based filesystems
Surely "filesystems based on block devices" is much less
mind-boggling.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
from Plato to Darwin*, 1996
Re: .SPACE in mom
On Wed, Nov 10, 2021 at 08:50:29PM -0500, Douglas McIlroy wrote: > Subject: Re: .SPACE in mom > > .sp |d, where d is some vertical distance, provides that much > space from the top of the page above any immediately following > text. The nominal height of such text is the line spacing, > \n[.v]. While I think that this helps to clarify the use of "|" in .sp, I suggest that it's important to show that ".sp |d" is essentially a "vertical move to" instruction. It can be used anywhere on the page to change the current vertical position. Important usages are to move to the top of the next column (which is not necessarily the top of the page) or to position a diversion in a precise spot for output (the horizontal position of the output can be made precise with a temporary change to the page offset with .po). This implies thinking about a page layout in a non-serial way, which is very useful in complex layouts, either multi-column pages or, especially, for single-page layouts with a variety of elements in posters, flyers, ads, etc. In multiple-page documents, like newsletters, I often set "anchors" at the beginning of the document that give the page number, column number, and horizontal and vertical origin positions of a block, usually a graphic with a caption captured in a diversion. My start-of-page macro first of all checks to see if an anchor has been defined for the page, outputs the diversion in the proper position, then sets traps so that the current text flow moves around the output block. This is for occasions where the output block needs to be always positioned in a particular place and isn't really related to a position in the text flow (banners, mastheads, ads, among other things). -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: SEE ALSO fails
On Sat, Oct 30, 2021 at 04:42:24PM -0700, Larry McVoy wrote: > Subject: Re: SEE ALSO fails > > If the proposal is to remove See Also's that aren't installed, I > could not be more against that idea. That just makes the system > harder to learn. > > If I'm way off base, my apologies, please correct me. Thank you for being constructive about this debate: I don't think you're off base; I should have suggested that instead of removing the reference to the missing program, the reference should be annotated to show that it's not installed. On debian systems, "apt search x" results are displayed with the the opposite logic -- "installed" is added for the appropriate result. I've only noticed this in the last few years on debian systems, but I'm very glad it's there. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: [groff] 02/11: doc/groff.texi: Fix style nits.
On Mon, Aug 16, 2021 at 03:33:55PM +1000, Damian McGuckin wrote: > Subject: Re: [groff] 02/11: doc/groff.texi: Fix style nits. > > The AP, APA and CMS Style Guides, all of American origin, have > a mandatory comma. While these Guides live behind paywalls, the > Q+A web site of the Chicago Manual of Style says to "Put a > comma before and after; avoid using both in the same sentence; > and try not to use either in formal prose. And (a bonus tip) if > you start a list with e.g., theres no need to put etc. at the > end." I think this makes the most sense since "e.g.", "for example", "i.e.", and "that is" are parenthetical phrases, unless you're used to slurring through them. The Canadian Government style guide fudges a ruling on this by saying the comma following such constructions is optional, noting that "use of a comma is American style; omission of the comma is British style". So much for Canadian cultural independence. Maybe the best way to synthesize this contradiction is to use parentheses instead and relieve the poor comma of too many responsibilities. It is after all the most overworked punctuation in English prose and would benefit from unionization and a shorter work week. For improving clarity (always a good thing), I would avoid the abbreviations, as you suggest: > such as (not e.g. or for example) > and > that is (not i.e.) > and > and so on (not etc.) although "that is" is still parenthetical, if you ask me. -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == The most erroneous stories are those we think we know best – and therefore never scrutinize or question. -- Stephen Jay Gould, *Full House: The Spread of Excellence from Plato to Darwin*, 1996
Re: Find a char in string
On Thu, Jun 24, 2021 at 11:23:48AM +0100, Denis M. Wilson wrote:
> Subject: Re: Find a char in string
>
> Macros attached.
> ...
> . if \[str]\*[str-tmp]\[str]\$[3]\[str] \{\
Very useful macros, thanks. But I am astonished that \[str] comes
into existence merely by being called. That's an almost
theological concept. Is that documented anywhere? Are there other
instances where we can expect something to be created from
nothing (i.e., without explicit definition)?
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
from Plato to Darwin*, 1996
Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.
On Tue, Nov 03, 2020 at 07:18:50AM +0100, Werner LEMBERG wrote: > Subject: Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '. > > Attached :-) > > I converted the font using `psf2bdf.pl` and `fontforge` (followed by a > normalization run using `ttx` twice to disassemble and reassemble the > font). The only thing I added are some name strings. Thanks very much! -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: (off topic?) Docbook? Re: manlint?
On Sun, Sep 27, 2020 at 12:14:47AM -0400, Larry Kollar wrote: > Subject: Re: (off topic?) Docbook? Re: manlint? > > I’m not going to pronounce Docbook dead, but open-source > projects that use it (or Texinfo) have accidentally erected a > barrier to entry for people who want to contribute to the > documentation. They would be much better served by adopting > Lightweight DITA, which can ingest HTML5 and Github-Flavored > Markdown alongside DITA XML (and convert any type to any other > type). Complain about Markdown all you will, and use weird-arse > corner cases to show it’s Bad, but GFM can handle a lot of > everyday text. I generally agree with the above, but my point about the longevity of an XML document is that such a document is agnostic as to its target output. Too much of this discussion thread is concerned with converting a groff document to other formats like XML or HTML and ignoring the reverse path. Groff is for typesetting on paper. XML and its relatives like modern HTML seem to be used primarily for Web display, but they were designed as generalized markup languages. Groff's hyphenation, justification, and font-handling algorithms could be adopted by other rendering engines (like browsers or epub readers) but as far as I'm concerned it's currently the best method around for producing typeset pages on paper. In fact I think it's wasted on man pages, except for the fact that groff's entrenchment as the man-page generator assures that people like us will have groff available for our purposes regardless of what Linux or BSD machine we find ourselves on. >From the point of view of a structured document, groff's paper-driven purpose makes it a post-processor, not a writing or composing system. In this sense Markdown-type systems are for writing, and the most successful of such systems minimizes the keystrokes needed to structure a document because, after all, a writer's main purpose is to get content down and worry about presentation later. Markup code (like markdown, mediawiki language, even terse XML) is just a set of bookmarks to come back to when you start cleaning up the document's structure, in the same way as you would clean up the content's logic after spontaneous bursts of inspired writing. Peter's comment about Mom's semantic macros is very interesting, especially since he points out how presentation comes later: you write or modify what these semantic macros point to once you've decided what size of page or kind of page design you want for your document. Or you could convert those macro requests into other structured markup, as long as you use opening and closing delimiters (the crucialness of which is a different discussion). I think that's a far more efficient approach than including troff primitives as you write. And it's a significant break from all the traditional troff macro sets. > ... there are several decent XML parsers > for awk while TSV/CSV/JSON parsers have severe limitations. I > had to learn enough Python to deal with a couple of work > projects that involved CSV and JSON input. I think Larry's point here is that it's not that hard to write a script to go from a markup language to groff. I've used python for that for over twenty years (and awk for at least fifteen years before that). I've found that even some of my rather obese python scripts can do the conversion on a modern machine in the blink of an eye. And this also means that people we'll never meet will be able to write a conversion script in whatever language is handy fifty or one hundred years from now. However, there are tricks to the process, such as whether to use tree-like parsing or serial parsing; inline code needs to be handled differently than block code; when do you want to preserve white space and when do you want it ignored; how flexible can you make the parsing so that you can place the markup less obtrusively in the file to improve the readability of the content; etc. I'd prefer to have these kinds of discussions rather than complaining about how bad everyone else's systems are. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: manlint?
On Sat, Sep 12, 2020 at 11:53:44AM +0100, Ralph Corderoy wrote:
> Subject: Re: manlint?
>
> Eric Raymond has been working on a program called doclifter to turn man
> pages into DocBook. A daft idea, and one which the slow death of XML
> and DocBook should ensure never gains traction. :-)
Hi Ralph,
I don't know which part of your statement you're joking about --
I assume the reference to Docbook, which might indeed capsize
like an overweight freighter, but XML is such a simple and robust
form of structuring documents that it's going to outlast us all.
And on account of that anything coded in Docbook is salvageable
by all future generations of archeologists, although I'm glad I
won't be around to help them out.
I'm definitely going to continue to use simple XML to store
anything I want the future to see.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)
On Tue, Aug 04, 2020 at 08:20:54PM -0500, Dave Kemper wrote: > Subject: Re: Groff vs Heirloom troff (was Re: Quick question: how to do > .index in groff?) > > On 7/31/20, Steve Izma wrote: > > When I adjust the kerning (or mortising, if necessary) > > in values of one-hundredth or one-thousandth of a point, > > Everything I've found online says that mortising is another (less > common) term for kerning, but you're using them here as if they're > different processes. What's the distinction between them? In the 1980s, based on hearsay, I started to distinguish between positive and negative letterspacing with "mortising" and "kerning". Prior to that, I was in the habit of just using "kerning". This was at the point that about six of us around the University of Waterloo started up Mortice Kern Systems (which became MKS Inc.), supposedly to develope a typesetting system (we never did). But, prompted by your message, I tried to find other references to it, to no avail. I regard Robert Bringhurst as the expert in the history and theory of these things and he appears not to use the term "mortising", using "letterspacing" in such cases, and he seems to restrict the use to slight increases of letterspacing to words set in small caps. He also seems to restrict the idea of kerning to letterfitting, i.e., only between pairs of letters and almost always as a negative value. He's fairly explicit about considering any kind of track kerning to be poor typography. But I don't thing that's a practical position in my work. Bringhurst has extremely good ideas about "rhythm and proportion" and "harmony and contrast" in the appearance of a page and how this affects readability. I think one can maintain these principles with careful attention to track kerning across a paragraph (and, of course, sometimes across a page). In a production situation, where the typographer is often under pressure to produce pages quickly, I think track kerning (or mortising) is an essential tool, but you always need to look closely at the results. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)
On Fri, Jul 31, 2020 at 08:52:59PM +0200, Pierre-Jean Fichet wrote: > Subject: Re: Groff vs Heirloom troff (was Re: Quick question: how to do > .index in groff?) > > Larry Kollar wrote: > > I’m using neatroff for printed fiction,... > > (including font features like small caps and extended > > ligatures) and paragraph- at-once justification. Still, I > > chafe at its low resolution (1/720in vs Groff’s 1/72000in), > > because some microtypography requires a bit more than 1/10pt > > precision. The macro set I use tries to accommodate either one. > > As a simple curiosity, to help me improve my typographic eye, could > you please explain me in which situation you need a higher resolution? For almost everything I typeset, especially books and newsletter-type publications, I always at least a few places where I need to use track kerning on a paragraph in order to get good word spacing and to shorten or lengthen paragraphs in order to avoid widows (the last line of a paragraph starting a column of text). When I adjust the kerning (or mortising, if necessary) in values of one-hundredth or one-thousandth of a point, it can make a difference in whether a word fits on a line or is broken or pushed to the next line, thereby making the paragraph too long. I avoid trying to adjust only part of a paragraph because that can drastically affect the "colour" (i.e., density) of the text. That said, I've never been convinced that paragraph-at-a-time justification makes a difference to the work I need to do for getting good word fits and even colour to the page. Over a period of about ten years starting in the late 1990s, I typeset about 20 books using LaTeX (probably about 15,000 pages altogether, the proceedings from various computer conferences) and I found that the TeX paragraph-at-a-time justification had to be scrutinized and adjusted just as much as my groff work. The trade-off to getting better word spacing was that often TeX just failed and overset lines. When it oversets a line you either have to catch the stderr messages warning about that (among much other noise) or look closely at the right margin to find often very small amounts of protrusions into the margin. I much prefer groff's process because I know it will never overset and bad spacing catches my eye very easily. Maybe this isn't a good argument against using the Knuth-Plass algorithm for justification, and maybe I just never found the correct way to solve my problems in TeX, but I would like to caution people who think that the implementation of that algorithm in groff is going to lessen the effort that goes into high-quality typography. I should also point out that I think the TeX community is a wonderful group of people. I attended their annual conference a few years ago when it occurred in Toronto and had a really good time. Collaborating and exchanging typographical ideas with them would be of great benefit to both of our communities. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: \: re-enables hyphenation--should it?
On Sat, Jul 25, 2020 at 09:18:56AM -0500, Dave Kemper wrote: > Subject: Re: \: re-enables hyphenation--should it? > > I'd mildly prefer to see \:'s hyphenation-reset behavior changed. \% > changes meaning depending on whether it's at the start or in the > middle of a word, and your examples illustrate that it's acting with > its beginning-of-word meaning when it follows a midword \:, which also > seems incongruous (though necessary if the \: resetting behavior is > retained). Doesn't this depend on the definition of a word boundary? I'm not familiar with groff internals, but thinking about the fact that a word boundary has two modes in vi(1), for example (normally a word being a sequence of alpha-numeric or "_" characters; alternatively being a sequence of anything other than white space), perhaps a word is defined differently in groff depending on circumstances? A URL quite possibly breaks assumptions about words that might be rooted in the early 1970s. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Fri, Jul 17, 2020 at 12:32:54PM -0700, Michael Pirkola wrote:
> Subject: Re: Groff macro to make .UR and .UE links clickable in PDF?
>
> While I agree that a shorter line length is more readable, I
> frequently exit a manpage, maximise the terminal window, then
> reopen it when my goal is to quickly scan the page for a
> relevant option. I find argument lists in particular much
> easier to look through when they take up fewer lines. Manpages
> in particular are less likely to have large paragraphs of text,
> and a long line length commonly reduces an entire topic to a
> single line which I also find more convenient.
You have a point in that scanning for info is not reading, and
therefore doesn't require the same kind of concentration and
doesn't result in as much fatigue. I'm arguing about the
difficulty in trying to read and comprehend all of a text when
the typography makes the eye work harder. So perhaps the default
should be related to the most common way of using man pages.
Somehow, though, if I were the author of a man page (which I'm
not, but I've written lots of text about how to use software) I
would probably want the presentation of my writing to be as
inviting as possible. Using the --help option on a command line
is my preferred way to scan but, of course, when I need more
detail about an option your suggestion makes good sense.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Sat, Jul 11, 2020 at 09:28:45AM +0100, Colin Watson wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > On Fri, Jul 10, 2020 at 11:26:46AM -0400, Steve Izma wrote: > > I think it's an abomination that a man page extends it's line > > length to fit the width of the terminal; built into the macros > > should be a 65- or 70 character maximum width. > > I'd be willing to take a bug report about the way that man-db does this > by default; it's a change I adopted from Andries Brouwer's man way back > in 2001... I apologize for being needlessly sarcastic here. I assumed the source of the problem was long lost on some magnetic tape somewhere. I've submitted a report, which I hope is clear enough. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Fri, Jul 10, 2020 at 06:39:32PM -0500, Nate Bargmann wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > * On 2020 10 Jul 10:27 -0500, Steve Izma wrote: > > I think it's an abomination that a man page extends it's line > > length to fit the width of the terminal;... > > Which is precisely why I have the following environment variable set: > > # Set maximum width of man pages to 80 characters > export MANWIDTH=80 That helps, thanks. I should have RTFriendlyM before posting (i.e., man man). -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Fri, Jul 10, 2020 at 06:18:58PM +0200, Ingo Schwarze wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > Re: changing the URL submitted by an author so that it fits typographical requirements. > There is nothing wrong with the document author doing that in cases > where it works together with the surrounding text, if and when the > surrounding text provides sufficient context. > > But please don't change what the author writes behind the author's > back, and least of all breaking existing documents. That would be a problem, but the publishing process needs to be a collaborative effort meeting the needs of both the typesetter and the author -- the typesetter is, after all, responsible for making the author's text readable. In fact, most publishers (even the publishing co-ops that I'm usually involved with) impose the design rules on the author, but "errors of fact" (which a broken URL would be) need to be fixed with agreement of both parties. > > I think it's an abomination that a man page extends it's line > > length to fit the width of the terminal; > > That's exactly why the mandoc implementation of the man(1) program > doesn't do that. Try it with a very wide virtual terminal window > on an operating system like OpenBSD, Alpine Linux, or Void Linux; > or on Fedora Linux with the "use mandoc as man" configuration option > enabled; or on any other Linux with a mandoc package installed and > enabled as man(1) by hand That's good to know; thanks. > > It's interesting > > that the Python Style Guide insists on a maximum line length of > > 79 characters and recommends 72. A basic premise of python design > > is *readability of code*. > The main reason of keeping the limit at 78 and not reducing it to, > for example, 70 is that many existing manual pages have been written > to look good with a limit of 78, and displaying them with a smaller > width sometimes causes awkward line breaks. Not a huge deal, but > then again, 78 isn't that bad for readability either, in particular > given that there is a left margin of five display columns for mdoc(7) > and seven display columns for man(7) by default. Yes, that's a good point about left margins. But my python reference was about the readability of python code. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Fri, Jul 10, 2020 at 01:48:02PM -0400, T. Kurt Bond wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > > Everyone: Would anyone object if .URL used this strategy for cleaner > > typesetting? > > Please don't do this: there are still web sites out there that only > respond to www.website.tld and not to website.tld. Okay, then; here's another guideline (related to one I've mentioned before): reduce the size of a URL by all possible means until the result is the smallest one that works. In other words, don't display a URL that doesn't work. On the other hand, you could also replace any mention of a URL with the phrase "search for ... using your favourite Internet search engine". That's not only a clearer use of language and way easier to typeset, but it's also likely to survive the disappearance of a website or the relocation of pages. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Fri, Jul 10, 2020 at 02:41:13PM +0200, Ingo Schwarze wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > > .URL https://foo.bar.com/fred/juki/ > > > > would be displayed (in PDF, HTML, and nroff) as simply > > > > foo.bar.com/fred/juki/ > > > > Steve, what do you think of this practice? > > > > Everyone: Would anyone object if .URL used this strategy for cleaner > > typesetting? > > Yes, i do strongly object. > > I think it is very bad practice to omit the protocol from an URI. > For one thing, it results in invalid URI syntax. On top of that, > the fact that this week, the web is a monoculture of https:// neither > means that other protocols don't exist nor that other protocols > cannot become used. > And finally, the omission of the > protocol can - depending on the context - cause confusion because > it removes an obvious indicator that the thing printed is a URI in > the first place, an indicator that the document author may have > relied on. Ingo, I think you're overreacting. I can't remember the last time I had a problem in omitting the protocol in a browser location bar. But the question here is how to *display* a URL in text and my rule of thumb is to reduce the size of the displayed URL as much as possible. If we are talking about interactive documents, like a PDF with clickable (terrible term) links, then I would argue that the underlying link syntax should include a fully compliant address, with protocol. But when it comes to documents meant to be read (on paper or otherwise) optimal line length and the syntax of a proper URL are just barely compatible. It's well established that a comfortable line length for reading is somewhere between about 40 and 70 characters. Most printed books have line lengths of about 24 to 26 picas (27 max). Anything with a longer line was likely designed by someone who rarely reads (unfortunately I have found in my publishing career that most people doing page design or actual layout for books these days don't read much). Anything longer usually adds to eye fatigue because of the distance the eye needs to travel back to the beginning of the next line without losing vertical position. Obviously vertical line space (or "leading") affects this as well. Since most of us who aren't typesetting books are probably typesetting for a letter-sized or A4 sheet of paper, we should be setting type on two columns per page, which usually means a line length of 20 to 22 picas. Most of my typsetting these days is in that format. Way too many URLs don't fit on that size of a line, so chopping off the protocol is entirely practical in order to get consistent word spacing -- which is essential for a smooth, rhythmic (Robert Bringhurst's concept) reading experience. An alternative rule followed by the publishing company I mostly work with these days is to leave the protocol off if the address begins with "www". I think that's a bit of a hack compromise, since it assumes people will only quickly recognize a string of characters as a URL if it begins with either the protocol or something as familiar as "www". I also use colour to indicate URLs in text as an additional aid to recognition, but that's not always practical. I think it's an abomination that a man page extends it's line length to fit the width of the terminal; built into the macros should be a 65- or 70 character maximum width. It's interesting that the Python Style Guide insists on a maximum line length of 79 characters and recommends 72. A basic premise of python design is *readability of code*. The main source of authors for man pages is, I assume, programmers. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Tue, Jun 16, 2020 at 03:00:55PM -0400, Peter Schaffter wrote:
> Subject: Re: Groff macro to make .UR and .UE links clickable in PDF?
>
> I would add that inserting \: (the zero-width break point) before
> or after every forward slash in a URL, depending on the style
> guidelines of a document, saves a lot of manual fiddling when URLs
> must be broken across lines. Not all the fiddling, but enough to
> warrant making it a first line of defence.
Yes, this is a good idea. There are also cases where you want \:
*before* a period, e.g., http://www.somethingVeryLong\:.org/etc,
since it's usually better to have the period start the next line
in order to emphasize that it's a continuation of the URL rather
than the end of a sentence. This might be considered a case of
choosing the least ugly solution.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: Groff macro to make .UR and .UE links clickable in PDF?
On Tue, Jun 16, 2020 at 09:55:01AM -0400, James K. Lowden wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > On Tue, 16 Jun 2020 13:36:41 +0200 > Jan Stary wrote: > > > How do you suggest a long URL should be typeset? > > It's an honest question: I don't know. It seems weird > > to e.g. hyphenate words in URLs, as in http://some.compli- > > cated.doma.in/file.html > > I think the only solution is to wrap the URL, unmodified and > unhyphenated, to fit. To introduce a hyphen would to change the > literal URL. Hyphenation should never change the meaning of the > text. A user copying the typeset URL and pasting it into the > browser's address bar shouldn't have to hunt down spurious > hyphens. I find the whole idea of typesetting URLs in printed matter to be full of contradictions, but this is mostly on account of how contemporary Web frameworks construct URLs for dynamic pages and need all sorts of variables set in the posted URL. If Web sites were set up with mostly static pages in a normally organized filesystem hierarchy, URLs would be simpler and more likely human readable. As it is, no one is going to retype a URL that's longer than a few words from a printed page. From an online PDF, the URL shouldn't actually be typeset, I'd argue, but hidden in the link. Anyway, my strategies for typesetting for a printed document: - test the URL iteratively by removing as much as possible from the end of the URL until you have the minimum number of characters for getting to the page; usually this means removing all the set variables; - if the resulting URL is longer than the output line length, break the line and begin the URL on the next line - there are well-established rules for breaking a URL, which include: never add a hyphen to show a break; break the line such that the beginning of the next line looks like a continuation of the URL, e.g., with a slash; - don't set the URL at all in the body of the text but use a footnote or endnote marker and set the URL in the footnote or endnote, since these are usually set in a smaller point size and gives you more flexibility for fitting on lines; if a text contains a lot of URLS, then set the notes as endnotes in a longer line length, if possible; - some publishers use a style that ignores any part of the URL other than the site location; they expect that once the reader gets to the Web site, they can use the site's search mechanism for finding the appropriate material; - since URLs are notoriously short-lived, encourage authors not to use them at all but to cite printed material rather than online material, or give complete bibliographic information about the citation and a short reference to the home page of the site. One of the key issues is that a printed work is very likely to outlast the accuracy of a URL, so don't diminish the usefulness of a printed work but relying on URLs. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Why does simply creating a diversion produce output?
On Tue, May 05, 2020 at 07:59:45AM +1000, G. Branden Robinson wrote: > Subject: Re: Why does simply creating a diversion produce output? > > > > .di d > > > foo > > > .di > > > .rm d > > > > Output is only sent to the diversion when a break occurs, either > > explicitly with .br, or when enough text has been collected to fill a > > line, or in no-fill mode. Otherwise, the diversion remains empty, but > > a partially collected line exists when the end of input is > > encountered. > > I think I'd like to add that first sentence to the Texinfo manual and > groff(7). At present, the Texinfo manual simply says, "The current > partially filled line is included in the diversion." This refers to any partially filled line occurring before the diversion starts (i.e., at the time of encountering the ".di d"). As I said in a previous message, diversions are completely separate from page traps. In my experience I use diversions most often when I need to measure the size of the output of the contents of the diversion. Then I can decide if the diversion fits in a particular place on the page, then move to that place and output the diversion's contents. In order to prevent partially filled lines going in at the beginning of the diversion, I normally begin a new environment at the start of the diversion. An alternative is to use .box instead of .di. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Why does simply creating a diversion produce output?
On Mon, May 04, 2020 at 10:48:35PM +0200, Tadziu Hoffmann wrote: > Subject: Re: Why does simply creating a diversion produce output? > > > > .di d > > foo > > .di > > .rm d > > Output is only sent to the diversion when a break occurs, > either explicitly with .br, or when enough text has been > collected to fill a line, or in no-fill mode. Otherwise, > the diversion remains empty, but a partially collected > line exists when the end of input is encountered. > This causes a page to be begun, but since the partially > collected line is not forced out, the page remains empty. > > Try the following variations > > .di d > foo > .br > .di > .rm d > > and > > .di d > foo > .di > .rm d > .br > > to see this. That explains why the diversion is empty. But diversions have nothing to do with page traps. The contents of a diversion aren't output until the diversion is explicityly called. I don't see any code to that effect implied or explicit here. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Proposed: drop groffer (was: contrib/groffer/roff2.1.man)
On Tue, Apr 21, 2020 at 10:48:17PM +1000, John Gardner wrote:
> Subject: Re: Proposed: drop groffer (was: contrib/groffer/roff2.1.man)
>
> > Does anyone object to just deleting groffer?
>
> Terminate with extreme prejudice.
>
> IMHO, anything that can be achieved with an alias or shell one-liner really
> doesn't warrant its own executable.
Your humble opinion is concisely stated; I agree with it.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: [d...@cs.dartmouth.edu: Re: weird \s]
On Sat, Apr 04, 2020 at 06:42:37PM -0700, Larry McVoy wrote:
> Subject: [d...@cs.dartmouth.edu: Re: weird \s]
>
> ...
> Anyone arguing for \sDD is just misguided. If you want two things
> it is \s(12, if you want N things, groff gave you \s[1234].
>
> Could we please just converge on this spec? I'm old and tired but
> if we can get agreement on this and noone wants to do the code I'll
> take a swing at it.
I'm in favour of this. If there are important reasons to preserve
legacy documents, put them in a revision control system and use a
sed script (as previously suggested) or something similar to make
a modern version.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: weird \s
On Mon, Mar 30, 2020 at 10:53:23PM -0400, Doug McIlroy wrote: > Subject: Re: weird \s > > Did the author of groff steal the code from Bell Labs? Or did > he merely read the code and preserve the feature in a misguided > nod to backward compatibility? Did he find it by experiment? My understanding of the development comes from people I knew at Softquad Publishing Software in Toronto in the 1980s and early 90s. They licensed the source code for the troff suite (either Kernighan's ditroff or else the Documenters' Workbench code) from AT Their manual, "Text Formatting: Technical Reference" gives a short "Historical Perspective" and points out that for ditroff "Kernighan kept the input language and maintained compatibility with the established pre-processors." Presumably that included the behaviour of \s because that behaviour is described in this technical manual as; \sNN <- 0 or a number from 4 to 39 \s±N <- a number from 0 to 9 etc. The manual I have dates from 1988. In the mid-90s I heard from David Slocombe, SoftQuad's chief programmer, that James Clark consulted closely with SoftQuad about the enhancements they made to the system. I used SoftQuad troff for almost 15 years before switching over to groff, and it was a pretty easy transition, even with the couple of thousand lines of macro code I had written for books and journals typesetting. The main loss in the transition was that no one has implemented for groff the very sophisticated debugging trace output that sqtroff provided. But groff has been significantly enhanced since then. Hope this fills in some historical gaps. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: amusing bug
On Tue, Mar 17, 2020 at 02:04:57PM -0400, Mike Bianchi wrote: > Subject: 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 Yes, that's it. Thanks! -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell (text only; not frequently checked): 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: amusing bug
On Tue, Mar 17, 2020 at 12:48:44PM -0400, Mike Bianchi wrote:
> Subject: Re: amusing bug
>
> I nominate Brian Kernighan.
He's exactly who I had in mind as well. This list of his lectures
on Computerphile provides for great history lessons:
<https://www.youtube.com/playlist?list=PLzH6n4zXuckqZ90zLyy36qjO5YIn1RulG>.
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.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313
cell (text only; not frequently checked): 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: Meeting Minute
On Mon, Nov 11, 2019 at 11:18:31AM +0100, Tadziu Hoffmann wrote: > Subject: Re: Meeting Minute > > > > > \l'\n(.l/1m' > > > > \l'\n[.l]u' > > I think what should be considered here is that groff only does > integer arithmetic. Therefore, in the first case the length > of the line will get truncated to an integer number of ems, > whereas in the second case the length of the line will match > the width of filled text lines as closely as possible within > the limits of the device resolution. Thus I suggest that > the second way is generally preferable. Very good point. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
Re: Meeting Minute
On Fri, Nov 08, 2019 at 01:25:05PM +, Ralph Corderoy wrote: > Subject: Re: Meeting Minute > > You might like to know that the line length is available in a register > to avoid having to repeat the earlier value. > ... > \l'\n(.l/1m' Ralph, isn't this a little clearer?: \l'\n[.l]u' It seems to me that using 'u' for units works for every command that takes a linear measurement and number registers always store values as units. Am I missing an advantage to your suggested style? -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 == I have always felt the necessity to verify what to many seemed a simple multiplication table. -- Ilya Ehrenburg (Soviet author and critic; he's not talking about mathematics)
[groff] groff and pipes
Something I didn't know about our fellow correspondent Doug
McIlroy:
<https://thenewstack.io/pipe-how-the-system-call-that-ties-unix-together-came-about>
Groff would be terribly less useful if it didn't adhere to this
standard. I've always thought of this in terms of groff being a
filter, but I can't remember where I got the "filter" terminology
from.
And can anyone tell me why Donald Knuth did not design TeX this
way? This has always puzzled me and is the main reason I rarely
use it.
Thanks,
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684
==
I have always felt the necessity to verify what to many seemed a
simple multiplication table.
-- Ilya Ehrenburg (Soviet author and critic; he's not
talking about mathematics)
Re: [groff] anyone seen ".ny0" ?
On Tue, Mar 26, 2019 at 12:46:27AM +0100, Ingo Schwarze wrote: > Subject: Re: [groff] anyone seen ".ny0" ? > > Tadziu Hoffmann wrote on Mon, Mar 25, 2019 at 09:55:31PM +0100: > > ... Were any other > > troffs in widespread use at the time (ca. 1985)? > > I doubt it. There have certainly been some niche implementations > at various times and some forks from the main lines, but i never > heard that any important forks diverged much, or that any independent > reimplementations were influential before the advent of GNU troff. A little bit more homework would have been useful here. SoftQuad troff has been mentioned many times in this mailing list. SoftQuad licensed the source code for ditroff from AT and thoroughly rewrote it (including preprocessors, device drivers, etc.). The result was used extensively by large corporations and the U.S. military (not necessarily, from my point of view, something to brag about) for documentation, especially once SoftQuad integrated an SGML front end to the typesetting suite. In my work at Wilfrid Laurier University Press, we used both the Unix-based and DOS-based versions from SoftQuad (and MKS) to typeset books and journals from about 1986 to about 1998, probably tens of thousands of pages. The system was impressive enough in both its results and its design that James Clarke essentially took it as a basis for writing groff. Bizarrely, Wikipedia lists Clarke as a "notable employee" of SoftQuad, but I doubt very much that that was ever the case. I do know that there was significant communication between him and the SoftQuad technical people during the time that he developed groff. Hardly, I'd say, a niche implementation. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 == Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan
Re: [groff] anyone seen ".ny0" ?
On Mon, Mar 25, 2019 at 09:55:31PM +0100, Tadziu Hoffmann wrote: > Subject: Re: [groff] anyone seen ".ny0" ? > > In the Xlib documentation, the ".ny0" first appeared in X11R1 > (apparently with no explanation), X10R4 did not yet have it. > ... > Were any other > troffs in widespread use at the time (ca. 1985)? That's about the time that SoftQuad troff got off the ground, but my old manual (dated 1988) doesn't list a .ny request. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 == One of my most productive days was throwing away 1000 lines of code.-- Ken Thompson
Re: [groff] Announcement and call for project submissions
On Fri, Feb 01, 2019 at 01:33:08PM +, Ralph Corderoy wrote: > Subject: Re: [groff] Announcement and call for project submissions > > I've pointed all this out because you'll encounter it again unless you > think https://www.xaprb.com/blog/you-might-be-right/ Good pointer. It may be right -- -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 == One other point is made by Dr. Grinspoon with a quotation from Archibald MacLeish, and it seems the most important consideration of all. "Knowledge without feeling," the poet said, "is not knowledge, and can only lead to public irresponsibility and indifference, conceivably to ruin." MacLeish said further: "When the fact is dissociated from the feel of the fact, . . . that people, that civilization is in danger." -- Henry Geiger, MANAS Journal, Nov. 1970
Re: [groff] groff as the basis for comprehensive documentation?
On Wed, Apr 25, 2018 at 10:49:25PM +0100, Ralph Corderoy wrote: > Subject: Re: [groff] groff as the basis for comprehensive documentation? > > > When I write, I only want to think about the words on the screen and > > the structure of my argument > > And when you've finished writing, do you not look at an output and spot > problems due to concentrating on the content? It's also troff input, > e.g. `.\&', and although that shouldn't interrupt your flow when > writing, it does need to be considered in some pass. I see what you mean. I didn't clarify that I write using a simple markup scheme (much simpler than markdown-style systems), so I'm not using troff in the source (except for more complicated, short items like posters and theatre or music programmes, in which I'll enter troff requests directly). For longer pieces using only the structural elements I mentioned, I need very little in markings (e.g., blank lines for paragraphs, dashes around subheads). I have simple awk scripts (sometimes a more complicated python script, depending on the output) to run the finished text through groff and to PS or PDF or XML, etc. I'm not sure why you consider `.\&' important: is that for end-of-sentence recognition? I would never start a text line with a character that needs '\&' for escaping, although I'll use it often in my conversion scripts. I very often write at least my first drafts with each sentence beginning a new line, if I want sentence-ending recognition in vim or groff. I've never used double spaces for sentences, but I recognize there are good arguments in favour of it. > > I should not need to make significant changes to the source text in > > order for it to read properly in these different formats. > > Only if you've no errors in the first place, errors that might not show > up if you don't check a formatted output, or check only one. For *content* errors, one should be able to use a text editor that makes the source readable enough to do this (until you reach the author-self-proofing problem I mentioned earlier; then it's up to others to read a cleanly formatted output). For *typesetting* or *style* errors, of course there's going to be back and forth. But I don't reach that point until I'm satisfied with the textual content. After that point and to adjust the typeset output, I work in either the troff or XML source file to add processing instructions (mostly things like kerning and extra spacing, which are really just last-resort fixes to formatting when the troff macro can't handle all possible situations), but since I'm no longer editing the content all this extra markup isn't interfering with reading the text. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [groff] groff as the basis for comprehensive documentation?
On Wed, Apr 25, 2018 at 05:00:01PM +0100, Ralph Corderoy wrote: > Subject: Re: [groff] groff as the basis for comprehensive documentation? > > > I work on mdoc(7) manual pages a lot, and i almost never look at any > > kind of output to see whether the final formatting comes out in the > > desired visual form. While writing, i exclusively think about the > > logical structure of the text and the semantic function of each word > > and symbol. (I do periodically check the rendered console output, > > though - but only because finding typos is easier in the rendered form > > than in the source code.) I certainly never look at HTML or > > PDF/PostScript output to see whether it comes out right. I just > > *know* it will - or if it won't then that's a bug in the formatter > > which i have to fix. > > ... I find looking at the PostScript/PDF valuable > precisely because it's a different rendering and thus shows problems > hidden by the rendering used when writing. I completely agree with Ingo's approach because it demonstrates the whole point of differentiating between content and format. When I write, I only want to think about the words on the screen and the structure of my argument, which is my interpretation of semantic structure -- paragraph breaks (corresponding to the notion of a paragraph presenting a single coherent part of the overall argument), sub-heads to flag a shift in the discussion, blockquotes to distinguish other people's thoughts, etc. Maybe also lists, but not much else structually speaking. This, of course, is a statement about writing in general, not specifically about writing man pages, but I think the logic holds. I also usually assume that I will end up rendering the text in various ways, e.g., typeset on paper, plain text in an e-mail, similarly structured input for a wiki. And the typeset output is not necessarily fixed either: sometimes I'll want it in two columns on a letter-sized page, sometimes a single column on a book page. I should not need to make significant changes to the source text in order for it to read properly in these different formats. We all know that's the job of the tmac package. In respect to proofreading, I don't have problems writing and editing within a text editor. But, over the decades I've worked in publishing, I've come to see it as a rule that authors fairly quickly get so familiar with their text that they see what they want to see, rather than what's actually on the page, so proofreading is never complete until someone else does it. That often means an additional way of formatting the text for others to correct it (e.g., additional line spacing, wider margins for notes). -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [groff] More on stripping
On Sun, Mar 11, 2018 at 12:26:45PM -0400, Peter Schaffter wrote:
> Subject: Re: [groff] More on stripping
>
> Doug's points about the candle not being worth the penny--the
> performance gain of stripped macro files is minimal--and that
> removing comments for the sake of efficiency passes the cost onto
> users, who generally have to acquire the commented/indented files
> separately for debugging and tweaking, are both valid.
I agree. Let's forget the stripping. I find groff lightning fast
regardless of the size of the tmac files. And knowing the
thinking behind the code is essential for progress.
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6
E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it.
-- Brian Kernighan
Re: [groff] [Groff] It is time to modernise "groff"
On Wed, Feb 21, 2018 at 03:03:48PM -0500, Dave Kemper wrote: > Subject: Re: [groff] [Groff] It is time to modernise "groff" > > On 9/4/17, G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > > At 2017-08-31T20:54:10+, Bjarni Ingi Gislason wrote: > >> p) Remove the '-a' option (the ASCII approximation output). > > As one use case, it's important for scripted regression testing. > Running diffs on PostScript output is often not very illuminating, but > running it on -a output easily enables you to home in on exactly what > the typeset difference is between one run and another. In decades of using groff, I'd never thought of this, but it's definitely something I'll start to use. > It also has one very valuable output property: outputting the string > "" to represent hyphens that groff has inserted for word breaks, Also very useful. > Please do not remove the -a option. I agree. I think it should stay. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [groff] [Groff] Unintended impact of strip.sed on om.tmac-u?
On Mon, Nov 13, 2017 at 11:10:04AM -0500, Peter Schaffter wrote: > Subject: Re: [groff] [Groff] Unintended impact of strip.sed on om.tmac-u? > > I have, admittedly, never processed a document larger than a 600 > page novel. I have typeset many books of sizes close to 1000 pages (and often more) that include tables and pic-style graphics, and I find groff to be remarkably fast. When adjusting and correcting the output for books this size, I would normally work on individual chapters (which groff always handles quickly enough to almost immediately update a pdf-viewer window). But I also frequently need to run a complete version of such large books and I doubt that WYSIWYG programs would be noticeably faster. My experience leads me to believe that groff with either stripped or non-stripped macro packages is no impediment to typographical productivity. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [Groff] devpdf U-fonts and Russian
On Fri, Oct 06, 2017 at 05:10:17PM +0200, Tadziu Hoffmann wrote: > Subject: Re: [Groff] devpdf U-fonts and Russian > > Of course, the best solution would be for everybody to stop > using PDF and start using Postscript instead. This is interesting. I thought that PDF had a more efficient way of storing data than PostScript and as a result allowed for faster reading and writing, although I've never looked into the details. I haven't yet switched over from using grops to gropdf, but I was beginning to think it was an inevitable path to better document processing. Can you explain your preference for PostScript a little further? Thanks, -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [Groff] Regarding HTML rendering
On Fri, Aug 18, 2017 at 12:33:12AM +0200, Ingo Schwarze wrote: > Subject: Re: [Groff] Regarding HTML rendering > > Steve Izma wrote on Thu, Aug 17, 2017 at 04:52:56PM -0400: > > > A relatively simple notation like Markdown would also work, > > I agree with all you are saying except this. > > The OP is certainly better off writing his documents in proper > roff(7) or groff_mom(7) and living with slighly quirky HTML output > than writing his documents in markdown and getting crappy output > quality in *all* output formats. Converting markdown into acceptable > roff input is just not feasible - not only because there is no tool > to do it, but also because markdown is just not powerful enough, > even if you were willing to write a new program to do that. Hi Ingo, Thanks for the comments. But I feel like I've sprung a page trap that sent me into an entirely different document by merely using the word "Markdown". You've misunderstood me, since I referred to a "simple notation *like* Markdown [emphasis added]" for which one should use a script to create input for groff. I wasn't at all suggesting using Markdown or anything like it for creating groff source documents because I don't know of any generally available tool that does this. > Besides, i hate the myth being re-iterated that markdown would be > easy to use. It is an extremely hostile, hard-to-use language > because it doesn't have any kind of consistent syntax, but instead > three strongly conflicting ones, so the rules for what any given > input means are usually extremely complicated and counter-intuitive, > and besides, there is almost no markdown document that is portable > because the details of all three syntaxes differ from one implementation > to the other, and there is no lack of conflicting implementations. > > For details why you should never use or recommend markdown as a > source language for any documents, see > > http://undeadly.org/cgi?action=article=20170304230520 It seems to me this argument implies a desire for a general-purpose markup language for creating typeset documents, which I think is an impossible goal. I'm interested in a simple markup notation for writing texts that I will later convert to probably an XML document for long-term archiving and use, and from that to various output formats. If the target is a part of a book, I would need to do it differently than I would if it were a journal article. If it were a poster or some other short, layout-intensive item, I wouldn't bother with markup. Any ascii-based notation like Markdown or MediaWiki can be used or adapted; their backends are irrelevant to this. And many of the complaints you have don't make any difference to me: in forty-five years of typesetting I've never needed to use bold-italic-bold; definition lists are a weird deviation from typographical style -- I would never reproduce in print what the HTML definition list displays in a browser; there are all sorts of ways of handling what you call mixing block and flow (I would call them block-level elements and in-line elements) in converting to groff code with or without a parser. I think what you're saying about line spaces at EOL (an admittedly bizarre notation) that affect list parsing might be relevant to the main problem I have with these types of notations: they insist on list elements being exactly one line long, which is just the result of a syntax inadequate or too lazy for designating the beginning and the end of a list. I would simply add opening and closing list markers to my conversion script (which could be awk, sed, python, etc.). Anyway, simple Markdown and MediaWiki types of notation are important in the area of publishing where I work because we need a text-based system of inputting that can replace the widespread use of word processors. This is obviously an uphill battle, but I've seen the appeal of things like Markdown (probably MultiMarkdown and AsciiDoc) at workshops and seminars, where it has clearly not been difficult to use. LaTeX and groff are not markup languages for structured documents; obviously, they're for presentation. You can fake structure by using high-level macro requests, but then you end up with something like XML without the angle brackets. And the current command set in LaTeX is too verbose and intrusive in a writing context. I think MOM has much more concisely named requests that are meant for semantic clarity. You may be perfectly correct in completely dismissing poor implementations of a tool, but given the need for a simple markup language I think it's a good idea to compare different approaches that have potential to aid writing and that separate content structure from presentation. -- Steve -- Steve Izmasi...@golden.net Home: 35 Locust St., Kitchener ON519-745-1313 Canada, N2H 1W6 cell: 519-998-2684
Re: [Groff] Regarding HTML rendering
On Wed, Aug 16, 2017 at 08:28:53PM +0200, Ingo Schwarze wrote: > Subject: Re: [Groff] Regarding HTML rendering > ... > The roff language is a poor fit for what HTML excels in, > namely, hierarchical representation of information and semantic > markup. The HTML language is a poor fit for what groff excels > in, namely, exact positioning of glyphs and lines on paper. So > the programmer is likely to spend lots of time trying to write > heuristic code to somehow transform the linear flow of pure > formatting instruction roff provides into something structured > and semantically enriched. Yet the user will likely be > disappointed because they won't find the precision and elegance > they are used to from groff PostScript and PDF output in the > HTML result. While I agree with the above analysis completely, I also suggest dealing with the problem by abstracting one level up. The roff language is for typesetting on a cut sheet of paper, whereas HTML is for presentation on a scrolling screen. The only thing they have in common is the content, and attempts to display the content identically on such different media does not result in a pleasant experience for the reader. The three addresses across the top of the letter Mikkel produced are a case in point: for paper output, you know the dimensions within which the three headings can reasonably fit; for output meant for reading in a browser, you have no idea what the dimensions of the screen will be and the right-hand address might disappear completely if set flush right. Anyone who intends to output content to such different media should use some sort of a higher-level markup whose purpose is to delineate the structure of the document, then filter that through the typographic system appropriate for the output medium. This would mean that for paper output the filtered output would produce a MOM source file and the for Web-based output a (probably fairly simple) HTML file. All formatting for the former would be determined by the MOM macro package and for the latter by CSS style sheets, which one would probably need to write. Peter has pointed out that MOM can be used to delineate structure, at least in documents where only high-level MOM macros are used (and not low-level groff requests) with a discipline aiming at strict semantics. And from that, as he also points out, it's not hard to use a scripting language to produce a valid HTML document. A relatively simple notation like Markdown would also work, and XML tagging is often used as well. But in both cases you'll need a fairly sophisticated script for filtering, especially for the groff output, since I don't know of any good generally available tools for this. Such an effort makes the most sense if one adopts this kind of a document-making procedure for regular use. When I use XML for this purpose, I try to keep the tag set relatively small, but broad enough to cover the major semantic elements of the document, e.g., for a book, including tags whose names clearly identify footnotes or endnotes, epigraphs, copyright information, bibilographic and index entries, and more specific author details. A sufficient tag set could be xhtml plus the above. I can keep my documents as valid XML but still insert special typographical instructions either as processing instructions (a last resort) or as attributes to a tag. For example to track kern a paragraph I'll use something like and have my XML parser pass the attribute name and value to the paragraph macro. -- Steve -- Steve Izmasi...@golden.net Home: 35 Locust St., Kitchener ON519-745-1313 Canada, N2H 1W6 cell: 519-998-2684
Re: [Groff] *roff for desktop publishing - is it feasible?
On Tue, Oct 25, 2016 at 10:57:57PM +0200, Tadziu Hoffmann wrote: > Subject: Re: [Groff] *roff for desktop publishing - is it feasible? > > ... > I'd start with some > suitable macros to simplify setting a consistent style > for the whole page. On the other hand, this is probably > why my designs invariably appear somewhat technical and > lack a certain artistic flair. To strain the analogy, > groff is great for making blueprints, not so much for > impressionist paintings. I would give you more (typographical) credit for that. I think the whole point of typography is to make texts more readable than impressionist paintings. I like to read what I typeset, not just look at it. It's also my opinion that so-called desktop publishing has developed primarily for visual artists (i.e., graduates of art schools) and its paradigm has much more to do with the arrangement of objects on a canvas than on a page. Therefore its main tool is the mouse rather than the keyboard, and its main mode is cut-and-paste rather than document structure and flow. For these reasons the paradigm of troff and TeX (I think you could call it "control flow" or programmability, or something like that) just seems uninteresting and obscure to those dominating the graphic arts industry today. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener, Ontario, Canada N2H 1W6 E-mail: si...@golden.net phone: 519-745-1313 cell: 519-998-2684 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? <http://en.wikipedia.org/wiki/Posting_style>
Re: [Groff] groff performance in respect to hardware platform
On Wed, Mar 23, 2016 at 11:21:37PM -0400, Steve Izma wrote: > Subject: Re: [Groff] groff performance in respect to hardware platform > >> ... But I'm wondering if anyone can tell me if groff benefits >> from running on multiple CPU cores and multiple CPUs. >> I assume that another way of asking this: "is groff >> multithreaded?" >> ... >> I'm only considering this in a Linux environment (Debian stable, >> fairly recent kernel). Thank you, everyone, for the responses, which help clarify things considerably. > From: Damian McGuckin <dami...@esi.com.au> > > It is the rendering of the output that takes the time, not the 'groff' > processing. Actually you might also have to think about your graphics display > speed. You probably need to be asking questions of the maintainers of the > viewer that you are using, not 'groff'. Yes, I need to look more closely at this. My pipeline consists of: - a python script reading xml files one at a time, parsing, and doing a fairly simple substitution of xml tags to groff requests (although more complicated than what one can do with sed) - groff, which calls my own set of tmac files, but which is, of course, a pipeline of its own. The output is a PostScript file. Like Clarke, I only need PDF when the job is finished. I start a separate instance of okular to view the PostScript file. I don't think that okular is particularly tuned to PDF to the point that a PS file causes it more work; it might be the reverse. Okular watches the timestamp of the PS file and it appears to me that it's prompt to notice the difference. Damian's comment might be relevant to the viewing process (and definitely for the other graphics-oriented concerns I have) but one counter-indication is how I observe okular working. Up to about 50 pages, the PostScript file is completely written before okular attempts to re-read it. The screen update is very fast. But if I'm viewing, say, page 90 the PS file (being written apparently in chunks by grops) is noticed by okular as having its timestamp changed, so it reads whatever in can get, can't find page 90, so displays page 50. Strangely enough, it doesn't seem to notice that the file has had more pages added to it after this point, so I'm stuck looking at the wrong place in the output. This implies either an I/O problem or else one part of the pipeline (I don't think it's the python parsing) is lagging behind. > From: Clarke Echols <cla...@verinet.net> > > I use vim for all of my editing, and have a function key set up so all I > have to do is press it and it executes groff with the options I need to > get the PostScript output in a default file. > > I then monitor the file with an open gv(1) window that updates every > time I press the function key and the file is rewritten. I then use > ps2pdf to get a PDF file when I'm done. It's fast, easy, and has > never given me any problem about speed. Yes, this is essentially what I've been doing for a long time and it demonstrates clearly to me how much I don't need a WYSIWYG system (e.g., InDesign) for my work. I used to use gv, but I seem to recall changing to okular because of better keyboard shortcuts. > From: Ralph Corderoy <ra...@inputplus.co.uk> > > As others have said, the single program groff isn't multi-threaded code, > but if you give it the -V option then it will print the pipeline of > processes that it's running, and they potentially run on separate cores > at the same time. Plus, as you say, all the other processes that want > to run, e.g. your kernel, desktop, editor, etc., aren't fighting with > the ones you're waiting for. > ... > Run a program like dstat(1), or vmstat(1), during that tedious 250-page > book and see what you can glean from the results, e.g. is it CPU bound, > and how many of your cores are used? Thanks for the suggestion. I'll definitely work on this. > From: Morten Bo Johansen <m...@spamcop.net> > > I don't think so, but you can use GNU parallel. Look at its > manual page, there are lots of examples, also on how to use it > on a single file. > As for python, there is a multiprocessing module. I'll experiment with this as well. > From: Steffen Nurpmeso <stef...@sdaoden.eu> > > Well i guess that you benefit quite a bit due to the piped nature > in between all the several programs that are involved, right? > Unless one part of the pipeline has to wait for more input from > its predecessor it seems to me they can run in full parallel. Ralph's and Steffen's comments reminded me of the pipeline issue (see above), which I hadn't thought of, so now I'm thinking that multiple cores across multiple CPUs has definite advantages for this kind of work. Just in: > From: "James K. Lowden" <jklow...@schemamania.org> > > Looking a
Re: [Groff] groff performance in respect to hardware platform
On Wed, Mar 23, 2016 at 08:25:50PM -0400, Larry Kollar wrote:
> Subject: Re: [Groff] groff performance in respect to hardware platform
>
> > I'm wondering how CPU configurations affect groff processing
> > speed.
>
> ... So any non-netbook, five years old or less, will perform
> pretty well with groff.
I guess I need to re-state the question. I'm quite familiar with
groff's speed, including with 1000-page (or larger) complex
books. But I'm wondering if anyone can tell me if groff benefits
from running on multiple CPU cores and multiple CPUs.
I assume that another way of asking this: "is groff
multithreaded?" I don't know enough about this kind of
programming to answer this by looking at the source code.
I'm only considering this in a Linux environment (Debian stable,
fairly recent kernel).
I suppose another factor is that since the Linux kernel is built for
parallelization, even if groff can only run on a single core,
all the operating system services can run on other cores without
interfering with groff's process. Or do I not know what I'm
talking about here?
When I typeset large books, there are some stages, like adjusting
track kerning on a page, where I want to see immediate results
on my viewer. My current hardware uses a five-year-old four-core
CPU. A section of text maybe 50 pages long will update in my
viewer in less than two seconds. But trying to do this for a
250-page book is tedious. That's why I'm interested in processing
speed.
Thanks,
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313
E-mail: si...@golden.net
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
<http://en.wikipedia.org/wiki/Posting_style>
[Groff] groff performance in respect to hardware platform
I'm wondering how CPU configurations affect groff processing speed. I'm planning to replace my workstation and I'm noticing the availability of a lot of used systems with multiple Xeon CPUs. Some of these are six or seven years old and seem to have been used for graphics of video work -- massive hard disks, 12GB to 24GB of RAM, enough video for multiple screens. I assume that one of the major advantages of Xeon processors over the i7 and i5 lines is their reliability, but I'm wondering if multiple cores (more than 4) and two Xeon CPUs on a system would have a significant effect on groff run times. Or would I need to re-compile groff in order to take advantage of such a setup? Given that these used systems run between about $400 and $2000 and would be a lot cheaper than a similarly equipped i7 or i5, I suspect the Xeon systems would have an advantage using some sort of a power-to-cost ratio, but the math needed for this isn't obvious to me. I'm also interested in bitmap editing (gimp) and batch processing of bitmaps using convert (imagemagick) or python, but groff is my main concern. Any advice? Thanks, -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 E-mail: si...@golden.net == There are 10 types of programmers: those who understand binary and those who don't. -- The Linux Journal
Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff
On Sat, Jan 23, 2016 at 12:17:35PM -0500, Larry Kollar wrote: > Subject: Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff > > > Yves Cloutier <yves.clout...@gmail.com> wrote: > > Markdown and friends are great for > > providing a certain level of document structure, however they don't - to my > > knowledge - provide any facility for specifying document or text styling or > > more complicated document structure. > > That’s the whole point. ;-) Markdown, and most XML-based systems, deliberately > kick the formatting can down the road so you can focus on your content. The > trick > is trusting the back-end will give you the output you need. I was aiming > toward > mostly structural markup in the Groff-based system I used at work for several > years, so I could produce decent HTML when the time came. I strongly agree that formatting comes later, after you've worked out the structure and content of your document. And, as James Lowden says in a subsequent message, you should find a writing system that allows you to concentrate on writing and that creates the XML more-or-less automatically afterwards. I've found that, once the bulk of my writing is done in something like Markdown, that I can produce an XML document that is really not that hard to edit later on. It helps to use a minimalist XML tag set, something like HTML5 with the addition of a few tags related to the type of document you're working on. For a book, for example, I usually need tags for copyright information, tables of contents, footnotes, and a few other things. I also stick to the principle of the tag name being strictly structural; I use attributes for specifically typographical information, e.g., for the odd paragraph that isn't a blockquote () or an epigraph () but needs special spacing: Text At worst, you can use a processing instruction to force a typographical intervention, and that allows you to instruct the parser to ignore the tag for other purposes: could tell groff to start a new page, fairly unobtrusively. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 E-mail: si...@golden.net Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Re: [Groff] Proper Small Caps.
On Tue, Jan 20, 2015 at 07:57:25PM -0500, Doug McIlroy wrote: Subject: Re: [Groff] Proper Small Caps. I recoil from text infected with capital pox, and don't see small caps as much improvement. They do make sense in all-caps text, but sporadic S\s-2MALL\s0 C\s-2APS\s0 or anything like it is not a cure for the pox. I agree with the sentiment; titles, phrases, or quotations (etc.) in all-caps sound like the Emperor inscribing diktats on walls in order to intimidate the plebs. The vast majority of book covers today are in all-caps since subtlety is antithetical to marketing. I rarely have any influence over the covers for the books I typeset, but I swear that when I have the opportunity to design a cover I will never set the title in capitals. Nonetheless, especially in scholarly and political publishing, acronyms are frequently needed. Setting them in small caps lessens their obtrusiveness in the text, I feel. A style that I see in some British publications (e.g., London Review of Books -- maybe it's more commonly accepted) is that if an acronym is pronouceable it's rendered as a proper noun, as Doug mentions about Unix. Large-and-small caps, I think, can work for authors' names or running heads in text sizes smaller than the regular text without seeming to be shouting. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] condition: OR of two string comparisons
On Thu, Nov 20, 2014 at 06:41:49PM +0100, Werner LEMBERG wrote: Subject: Re: [Groff] condition: OR of two string comparisons [Ralph:] I'd like to read `.nr i 3+4*6' and know if that's 27 or 42 without having to know the value of a `new expression syntax' register; code is often read by jumping in at a point and not following from the start of execution. Altering the syntax, with a new request or invalid old expression syntax, gives me that knowledge on the spot. This is a valid concern. Whoever is going to implement one of the suggested solutions: It seems that a poll is needed... I agree with Ralph. -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
Re: [Groff] condition: OR of two string comparisons
On Thu, Nov 13, 2014 at 09:28:05PM +0100, Carsten Kunze wrote: Subject: Re: [Groff] condition: OR of two string comparisons But why not as a first step keep the old syntax and make a real AND and : ar real OR so that .if (\\n(AB5:\\$1foo)(!\\n(.$=2) ... is possible? This is something I'd really like to see. As far as I know, at this point such an expression can be numerical only. -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
Re: [Groff] General nroff/troff question regarding .bp and .ne in diversions
On Thu, Jun 26, 2014 at 06:10:25PM +0200, Carsten Kunze wrote: Subject: [Groff] General nroff/troff question regarding .bp and .ne in diversions I'd like to use a diversion for printing the bibliography. There I'd like to avoid page breaks inside items. I tried to use .ne or .bp, both did not work. For .bp I found in the groff that it does not work inside (not-top-level) diversions, but for .ne it is not mentioned there. ... I assume you want the page break *outside* of the diversion. In other words, read the bibliographic entry into a diversion, check the height of the entry (\n[dn]), and then see if there's enough room left before the page trap. Something like this: .di bib Ayers, Gwendoline M. \fIEngland's First State Hospitals and the Metropolitan Asylums Board 1867-1930\fP. London: Wellcome Institute of the History of Medicine 1971. .br .di .if \n[dn]\n[.t] .bp .nf .bib .fi This assumes that the next trap is the end-of-page (or column) trap. Am I making the right assumptions about what you need here? -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
Re: [Groff] Mission statement - final
On Wed, Apr 02, 2014 at 06:38:49PM -0400, Peter Schaffter wrote: Subject: [Groff] Mission statement - final Groff Mission Statement 2014 Yes, I like it too. Very well stated. As the most widely-deployed implementation of troff in use today, One very minor quibble: you don't need the hyphen after widely. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[Groff] XML as groff input
On Thu, Mar 20, 2014 at 01:06:29PM +, Ralph Corderoy wrote: Subject: Re: [Groff] Mission statement, second draft I read _The TeXbook_ and returned to troff. The input language of troff is superior for mark-up that doesn't clutter the prose, e.g. often small and out of the way at the left of a line, and macro sets have tended to follow this. XML suffers terribly from noise, not intended for human entry, as I think you said elsewhere. asciidoc and friends are too simplified, OK for a github README but not typesetting. Hi Ralph, I think you're pointing at the basic issue here: how we write, i.e., using computers as a composition tool. So I'm changing the subject line, although I think this discussion really belongs on a wiki where we can actually develop and share some good practices. Briefly, when I write I want to see text only with a minimum of markup and with no reason for my fingers to leave the home row, so that's why I suggest something simple like markdown. What do you need when you're at the creative stage for most writing? a blank line for paragraphs, one or two levels of subheads, maybe blockquotes, inline markings for emphasis, titles, etc. All the rest of the apparatus, scholarly or not, can be added on later, when you don't really care about noise. So write creatively first, then think about presentation. Even though we're freed from two-letter everythings by modern troff, for common requests, a `.p' is all that's needed for the reader. A blank line is obviously quieter than .p -- when you're at the writing stage. When that's done, it's pretty easy to convert to XML, and at that point I want clearly marked structure. But in my experience -- I work mostly in scholarly publishing in the humanities and in trade-oriented political texts -- the tag set needed is not much more complicated than HTML5. DocBook is overkill and most publishers smaller than the University of Chicago Press don't have the funds to pay for such detailed markup -- largely because the additional semantics don't result in a more useful book to our audience. When that changes in the future, then we'll add the extra detail -- or noise, or whatever you want to call it. I've argued elsewhere that there's no gain in efficiency to add the detail before it's really needed. Using XML in the source document doesn't prevent you from using the detailed troff commands -- you just divert your efforts to the tmac file. It's the same thing as capturing a complex group of troff requests into a macro that's appropriate for a certain document. E.g., assuming all your first-level subheads should be handled the same way, you wrap up font specs, spacing above and below, justification hyphenation specs, etc., into that macro, rather than repeating the basic requests each time. In other words, an XML tag is equivalent to a macro call. But I think that XML has an advantage in things like this: .H1 This is a long subhead that won't fit on one input \ source line, (so maybe it should be edited) h1 This is a long subhead that can go on as may lines as I want, if I'm inelegant enough to keep it like this /h1 which, in my system, is equivalent to: .h1(( This is a long subhead that can go on as may lines as I want, if I'm inelegant enough to keep it like this .h1)) There are a number of other arguments for having opening and closing macros for an element (even for a paragraph), but this message is already too long. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting dashes
On Tue, Nov 19, 2013 at 03:58:00PM +0100, Tadziu Hoffmann wrote: Subject: Re: [Groff] Typesetting dashes Adding the same amount of stretch to each of the objects in the line maintains symmetry and rhythm. I contest that. Adding the same amount of horizontal motion to all spaces, regardless of their natural width, changes the relative proportions. In the limit of large stretch, the width of a thinspace will approach that of a regular space. But this begs the question of why you wanted a thinspace in the first place, instead of a regular space. Let me rephrase my point (quoted below) about pulling them together; maybe holding is a better word. It seems to me that the purpose of fixed spaces -- em, en, and thin -- is to hold things together (there's a fourth, traditionally -- maybe called a narrow space or a hair space?). An en space is supposed to be the same width of a numeral (or, at least of lining numerals, typically used in tabular material). It is frequently used in lists, endnotes, or footnotes to fix the space between the digit (with, possibly, its punctuation) and the word immediately following it. That space can't stretch along with word spaces, obviously, or the left margin of the text would be ragged. Similarly, an em space is used to hold the first word in a paragraph to a particular position, consistently paragraph after paragraph. I can't think of any other normal use of an em space; traditionally, it might have been used for lining up tabular material, but then it became more common for digit spaces (en spaces) to vary from the traditional one-half em space due to wilder font designs, so you can't always count on an em space being equal to the width of two digits. Maybe the em space, reduced to almost just one function, is becoming obsolete. On the other hand, groff doesn't have an em space. I'm not sure about rules for locales that use a space instead of a comma to separate digits, but I assume it ought to be a thin space so that the different parts of the number hold together in the event of stretches to the word spaces in the rest of line. Presumably you'd always want the space between the digits to be smaller than the word spaces, and if it were to stretch even proportionately on one line and not as much on the next, I think it would look very odd. My problem with a dash joined to adjacent words with a small fixed space or no space is that it can easily pull those words together; yet in terms of readability those words have a weaker relationship to each other than they do to the rest of the words in the phrase they are part of, so pulling them together makes them look almost like a compound word, especially if the spaces on the line are stretched. Here I agree with you 100 percent. That's why I'd want a stretchable space instead of a fixed space. My choice would be a three-quarters emdash surrounded by thinspaces (half a normal space) (which, incidentally, will have the same width as an em-sized dash if the regular space is nominally 1/4 em). However, a stretchable thinspace whose width remains half that of a normal space when the line is spread cannot currently be had with groff. So does this mean that you are arguing for a new set of spaces that behave like word spaces but have a different starting width and stretch proportionately (more or less) along with word spaces? (That means they would also need to shrink proportionately as well.) I'm thinking about the use of spaces traditionally and you're thinking, I believe, about more creative design. Your idea of a stretching fixed space has appeal in some situations, but obviously the stretch would be undesirable elsewhere. Your suggestion requires much more attention to detail (definitely a mark of craft). Sometimes we can afford that and sometimes not. And, of course, adding these to groff would require an overhaul of the HJ routines, not just the addition of new escape characters, because these things would behave unlike any other objects in the system. Yet I'll admit that my idea of dashes is not traditional: I consider a dash not to be a punctuation mark affixed to another object (e.g., as a period to a sentence or a comma to a phrase), but more like an operator between two parallel clauses -- like the boolean and and or between expressions. So it's related to but independent of its surroundings, and using the currently available stretchable word spaces clarify that relationship. Hmmm, trying figure this out has stretched my brain to limit for tonight. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting dashes
On Mon, Nov 18, 2013 at 08:57:36PM +0100, Tadziu Hoffmann wrote: Subject: Re: [Groff] Typesetting dashes ... Anyhow, 1/4 en thus corresponds to half a normal space in groff's TR font. Don't ask me why the \: converts the following space into a nonstretchable (but discardable) space. I'm not really happy with this solution. I'd prefer space that stretches proportionally to the font size, but this doesn't seem to work in groff: groff appears to compute the total stretch divided by the number of spaces, and then *adds* this to *all* spaces, independent of their nominal size. I think this is wrong and should be changed. If I understand the question properly, the implication is that a line might consist of words or characters at different point sizes, therefore the the spaces separating words of the same point size ought to stretch proportionately. (Am I in the ball park here?) If that's the idea, then I disagree. I can't think of a situation where you would want to mix point sizes on a line. Small caps, inferior or superior characters, and so on are ideally taken from fonts at the same point size as the regular text (if they're faked by changing point size, you wouldn't want the spacing around them to reveal the fake). Adding the same amount of stretch to each of the objects in the line maintains symetry and rhythm. I think the same holds true for a line with math characters in it that may need to change their size as part of a formula. My problem with a dash joined to adjacent words with a small fixed space or no space is that it can easily pull those words together; yet in terms of readability those words have a weaker relationship to each other than they do to the rest of the words in the phrase they are part of, so pulling them together makes them look almost like a compound word, especially if the spaces on the line are stretched. -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
Re: [Groff] Where do we go from here?
On Sun, Nov 17, 2013 at 11:00:36PM +0400, Anton Shepelev wrote: Subject: Re: [Groff] Where do we go from here? Peter Schaffter: Werner, you have fulfilled the role perfectly, and I know I speak for everyone on the list when I say you have earned not only our respect, but our ad- miration. Being a lead developer entails qauli- ties that go far beyond coding skills, not the least of which are diplomacy and an unflappable demeanour. You have exhibited both over and over again. Under your leadership, groff has matured wonderfully, remaining an active and vital part of the GNU project. My gratitude knows no bounds. I join these kind words. Thank you, Peter, for stating so well an appreciation of Werner's work. Werner, your ability to find the source of and fix problems so quickly has not only amazed me over the years, it's often helped me to get my typographical work done on time. Thanks again. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting dashes
On Sun, Nov 17, 2013 at 10:51:09PM +0400, Anton Shepelev wrote: Subject: [Groff] Typesetting dashes I should like to typeset em dashes surrounded by thin, say 1/4th en, spaces. To prevent a dash from starting a new line, the first space must be un- breakable. The second one must be discardable. Both spaces must be unstretchable. How to do it? I suggest you rethink the idea of unstretchable. Presumably you are using an em dash to separate phrases, so that it works similarly to a semicolon or a set of parentheses. Even though traditionally em dashes have often been set without any spacing, I feel the effect is to join the two adjacent words together, which can often separate them from their associated phrases. If you use a unbreakable space it should always be equal and never less than the word spaces in the rest of the line. I think for this reason Robert Bringhurst offers as an alternative an *en* dash surrounded by normal word spaces, which will always keep the rhythm of the words on the line consistent and be discarded if they fall at the end of a line without any extra typographical work on your part. I also don't see any reason why a dash can't begin a line; it still retains its function as a separation or introduction to a new phrase. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] What does 'groff foo' do?
On Sun, Dec 02, 2012 at 07:02:21PM -, Ted Harding wrote: To: Groff groff@gnu.org Subject: Re: [Groff] What does 'groff foo' do? On 02-Dec-2012 18:40:11 Clarke Echols wrote: In a recent email the syntax: groff foo ... was used. I've used Unix/Linux for over 25 years, and I've never seen that triple redirect before. What does it do? I get nowhere with a Google search because it ignores the ''. It surprised me too! Never seen it before While everything else does what one naturally expects, 'cat foo' or 'cat foo' seems to be a way of passing what follows the directly to the command, as if equivalent to echo foo | cat. I was confused too, but that's because I've always used the Korn Shell (pdksh under linux). But word is called a Here string in the bash man page. It's also included in the Mir BSD Korn Shell, which looks like it's going to be the universal replacement for pdksh. The above echo foo | ... looks more logical and consistent to me. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Macro packages
On Thu, Oct 04, 2012 at 02:54:10PM +0100, Denis M. Wilson wrote: Subject: Re: [Groff] Macro packages One of my regrets is that there is no troff interface for Lilypond... One of my regrets, as well. Lilypond's basic input system works very well, I find, but I haven't been able to get comfortable with the syntax for positioning adjustments. -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
[Groff] ps: import of an EPS file with binary data
I'm using convert (from imagemagick) to crop and convert pbm images into encapsulated postscript. When I prefix the output filename with eps2: I get a very compact EPS file where the image data is contained as binary like this: userdict begin %%BeginData:72200 Binary Bytes DisplayImage [a few lines of integers] [72200 binary bytes, presumably] %%EndData end The resulting image is displayable (e.g., in okular), but when it gets imported into groff with either .PSPIC or \X'ps: import ...' only the first part of the binary gets cleanly imported into the PostScript output (up to the first newline character) and the rest becomes a series of ^M's -- which print black. I realize that up to now all the images I've been converting to EPS for use in groff contain the image in ASCII format, but I was hoping to reduce file size with this convert output. As far as I can tell, the output conforms to PS LanguageLevel 2 (flagged by the eps2: prefix in the convert commandline). Is there some other flag or option I've overlooked? Thanks, -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
Re: [Groff] ps: import of an EPS file with binary data
On Fri, Jul 06, 2012 at 12:30:44AM +0200, Tadziu Hoffmann wrote: Subject: Re: [Groff] ps: import of an EPS file with binary data convert teapot.ppm teapot.eps2 gs -q -dNODISPLAY -dBATCH -dNOPAUSE ppmtops.ps teapot.ppm teapot.ps There must be a problem with the set of images I'm working on, either with a transparency layer or something to do with re-sizing in convert, so I need to do more testing. The above gs commandline works on other images I've tried, but when I run it on the set at hand, I get a MAXVAL not 255 error. I need more time to work on this. Thanks for the above example, Tadziu. Is there an option to resize and crop the input image? That's the main reason I'm trying to use convert, which works with grops if I don't try to reduce file size with the eps2: flag. Thanks, -- Steve -- Steve Izmast...@press.wlu.ca Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press http://www.wlupress.wlu.ca Waterloo, Ont., Canada N2L 3C5http://nestor.wlu.ca/blog Our e-newsletter http://www.wlupress.wlu.ca/press/General/signupform.shtml
[Groff] Groff and computer education
James Lowden sent me, off list, this link to an article he wrote about the relevance of groff to fundamental concepts of programming and computer use. I assume he's too modest to broadcast it, but I think it's excellent: http://www.schemamania.org/troff/student-troff.pdf Apart from all the typographical issues he raises, I think it shows how groff is a superior utility because it's a programming language, entirely unlike WYSIWYG systems. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Eric Raymond on groff and TeX
On Mon, May 07, 2012 at 03:06:17PM -0400, James K. Lowden wrote: Subject: Re: [Groff] Eric Raymond on groff and TeX ... An in-line element (emphasis, small caps, superior numbers) not only needs surrounding white space (or lack of it) detected and preserved, it also breaks up the enclosing block, leaving a tail (depending on the kind of parser you're using). What is tail here, please? I thought I understood until then. Sorry about this; it's actually hard to explain without a few examples, which is probably too much for this space. To give a simple answer, a tail is the part of a paragraph, for example, that follows an interuption like a few words in emphasis. It's relatively easy to process contiguous data within an element, but you need to do more work to connect things together when they are broken up by other elements. Typographically speaking, it's very important to properly detect and handle the whitespace around the interuption. I've made a lot of notes about this, and I promise that soon I will try to document this and other issues that make XML to groff processing tricky. So far I have always needed to detect and define separately whatever in-line elements a document uses, which means that writing a general-purpose formatter for XML seems virtually impossible. Why is it not possible to divide and conquer? If we know the set of tags and every tag is either block or inline (never both), why can't a dictionary of tag properties permit uniform handling of all in-line elements? That's exactly what you need to do, but it's not general-purpose because each project that has a different DTD would require rewriting the dictionary to include the inline tags for that DTD. As far as I know, there's no conventional way of flagging inline tags in DTDs or schemas. E.g., typical ways of tagging emphasis: i, e1, italic, emphasis, emphasis type=bold. By the way, using groff as part of a pipeline that includes a python script for XML parsing is blindingly fast. On my three- or four-year-old computers I can process a 200 page book in a few seconds. This means, using vi, for example, that you can make a correction in a file, hit a memory key that runs the groff pipeline, and have a postscript viewer (I use okular these days) watch the file for almost instantaneous updates. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Eric Raymond on groff and TeX
seems virtually impossible. Anyway, I don't think we'll get anywhere arguing that using troff codes in source documents is forward-looking. At the same time I see nothing being developed that comes close to groff's typographical abilities. The so-called justification routines used in ePubs is horrendous (they don't bother with hyphenation, unless the broken word from the original print version has been inadvertently left in). -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6p:519-745-1313 Work: Wilfrid Laurier University Pressp:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] groff 1.21 released
On Mon, Jan 03, 2011 at 10:32:26AM +0100, Tadziu Hoffmann wrote: Subject: Re: [Groff] groff 1.21 released Groffers everywhere, I'm sure, join me in expressing our appreciation. Joined :) Me too! :-D I, too, very much appreciate your efforts, Werner. Thanks and all the best for the new year. -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Copy register value to another register?
On Sun, May 30, 2010 at 05:41:51PM -0600, Clarke Echols wrote: Subject: [Groff] Copy register value to another register? I'm attempting to capture the current value of the vertical position register ( \n[nl] ) and set another register to that value so I can use it to return to the current location for further output. If I have inline code like this: .nr returnlocation \n[nl] do some stuff here .sp |\n[returnlocation]u it works as expected. But I prefer to use a macro like this: .de macro .nr returnlocation \n[nl]u \Preserve location to return to. other code But when I do that, the register [returnlocation] is assigned a value of -1 when I call the macro. You need to double the backslashes when setting the register from within a macro. If you don't, you get the current position at the time that the macro is being defined, which is likely to be before any output has occurred. The current position on a page before any output or any breaks is always -1, i.e., a value less than zero. The position 0 is the top of the page, but only after output is triggered. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] French punctuation
On Wed, May 19, 2010 at 10:39:20AM +1000, Robert Thorsby wrote:
Subject: Re: [Groff] French punctuation
Without trying to re-open the debate about the correct spacing
between the dots in the ellipsis, my Bible on the subject [the NSW
Government Printer's Printing Style Manual first published in 1966,
revised in 1969] predates computer technology and states that the
separation between the dots in an ellipsis shall be an en-quad -- and
woe betide any mere mortal civil servant who sent an MS to the Govt
Printer with an instruction to do otherwise.
But it's an interesting debate.
I think most North American style guides agree that if the
sentences on either side of the missing material are
grammatically complete, then the truncated matter should end with
a period (i.e., no space before), followed by three ellipsis
characters, followed by a word space. The Chicago Manual of Style
elaborates on this fairly clearly, but it also quotes from a
supporter of the model that Tadziu would prefer -- three dots
only under all circumstances. I think the former model is easier
to read, regardless of the existence of a capital letter
following the break. If the capitalized letter is a proper noun,
then the reader needs to stop and think about what's going on.
But typographically, the key issue is the spacing of the
ellipses. In the 70s with phototypesetting, I think it was pretty
standard to use a period and three en leaders followed by a
breakable and paddable word space; an en leader consisted of
an en space plus a period (one character altogether). This was
also the character used to build a trace of dots across the
page, as in a price list or a table of contents. So this agrees
with the Australian example from Robert above.
The Chicago Manual prefers 3-to-the-em for spacing. Robert
Bringhurst (in The Elements of Typographic Style) calls that
spacing thick spaces and considers such a style to be another
Victorian eccentricity. He seems to prefer the ellipsis
character built into the font he uses in his book, although he
cautions that different font families and different text sizes
might require a different treatment.
In any case, I don't think you want paddable or breakable word
spaces between the dots, since the three (or four) lose their
clarity if they're broken at the end of a line.
On a related topic: is anyone having a problem with the French
hyphenation dictionary? I can't get it to work with 1.20.1, even
though there's a note in the ChangeLog about fixing a typo in
tmac/hyphen.fr. From what I can tell the only difference between
that file in 1.20.1 and the previous version is the removal of a
comment character before \patterns{. Is there something else I
should be checking? Does it have anything to do with utf-8 or
preconv?
Thanks,
-- Steve
--
Steve Izma
-
Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872
Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125
E-mail: si...@golden.net or st...@press.wlu.ca
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Kernpairs and hyphenation
On Sat, Jan 02, 2010 at 06:05:40PM +0100, Werner LEMBERG wrote: Subject: Re: [Groff] Kernpairs and hyphenation I just noticed that groff wouldn't hyphenate fragment into frag-ment in Times-Italic. (In Times-Roman this works.) Turns out this has to do with there being two kernpairs, ra and ag -- if I remove either one from the font definition file the word gets hyphenated correctly. This should be fixed in the current CVS (since 2009-Sep-08). I should have reported earlier that I've used this version since September on hundreds of pages and it works well and definitely solved the hyphenation/kerning problems I had. Thanks again. -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Filling the last line before new indent
On Thu, Dec 10, 2009 at 07:21:52PM +1100, Miklos Somogyi wrote: Subject: [Groff] Filling the last line before new indent Once I solved this problem, but I can't recall it now. Any ideas please? Hi Miklos, Maybe someone's mentioned this already (I get the digest version of the mailing list); I think all you need to do is start a new environment before resetting the indent (or doing anything else that causes a break). The main text will be buffered. However, the indent will occur a line earlier then in your current situation. -- Steve -- Steve Izma Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press FAX: 519-725-1399 Waterloo, Ont., Canada N2L 3C5st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] hyphenation differences between fonts
On Tue, Sep 08, 2009 at 09:19:12AM +0200, Werner LEMBERG wrote: Subject: Re: [Groff] hyphenation differences between fonts But why should pair kerning matter in the hyphenation procedure? Or am I missing something here? I can confirm your observation, and I'll debug the problem soon. This is fixed now in the CVS, I hope. The patch changes just a single digit (see below). Please test. ... Thanks very much, Werner, it appears to work now. I'll do more thorough testing over the next two days. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca
[Groff] hyphenation differences between fonts
I have an Adobe Type 1 font, Minion-Regular, that doesn't hyphenate the way my other fonts do. For testing, I created a test file with a line length of 1P (I don't know of another way of testing hyphenation) like this: .ll 1P .fam T foreground .br .fam MIN foreground .br .fam GA foreground .br Running this through troff, I get this intermediate output: x T ps x res 72000 1 1 x init p1 x font 21 TR f21 s1 V12000 H72000 md DFd tfore Chy h3330 n12000 0 V24000 H72000 tground n12000 0 x font 52 MINR f52 V36000 H72000 tf H74920 to H80060 tr H83610 te h40 tg h110 tr H96050 tound n12000 0 x font 53 GAR f53 V48000 H72000 tfore Chy h3660 n12000 0 V6 H72000 tground n12000 0 x trailer V792000 x stop You'll note that both Times (TR) and Garamond (GAR) produce two lines fore- and ground, but the same word in the MINR font doesn't break at all. I've tried this with many different words, and I think it has something to do with kerning pairs. The Minion font has tons of kern pairs in its AFM file, and one of them is e g. The above output shows that the e and the g are kerned by 40 units (which is the value in the AFM file multiplied by 10). Neither the Times or the Garamond have a e g kerning pair, and in fact Minion seems unusual in that it has a vastly larger number of kern pairs for lower-case letters. One would think that good font design would make most of them unnecessary. But why should pair kerning matter in the hyphenation procedure? Or am I missing something here? -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Underlining in groff
On Thu, Jul 30, 2009 at 09:51:12PM -0400, Peter Schaffter wrote: Subject: Re: [Groff] Underlining in groff ... I don't suppose there's any chance of underlining for the PostScript device being implemented in groff itself, is there? Sure would make things a lot easier. I second the motion If so implemented, it would probably also allow accurate strike-through (maybe?). It's not that I want these for typographical reasons: these two forms are useful in manuscript markup to show copy-editing changes or suggestions. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting Software
On Thu, Jun 04, 2009 at 09:11:18PM -0400, Peter Schaffter wrote: Subject: Re: [Groff] Typesetting Software FWIW, I write structured plain text files and pass them through sed to introduce groff or LaTex formatting. Aside from keeping the files clean/readable, it makes things easier when I want to recycle them--say, into html. Normally, I toss the formatted files when my pipeline's complete; only rarely do I keep them, and that's usually only for micro typography, like creating beautiful rag or hanging punctuation outside the right margin. Good for you, Peter. I think this is the best way to write: concentrate on the text and pay minimal amount of attention to formatting, while structuring the text to make the conversion to groff straight-forward. I like something similar to Restructured Text for this and I'm starting to experiment with Wiki markup as well. Groff's abilities as a filter make this very expedient. I'm also experimenting with creating an xml document from the initial simple markup as well. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting Software
On Thu, Jun 04, 2009 at 12:05:27PM +0100, Keith Marshall wrote: Subject: Re: [Groff] Typesetting Software On Thursday 04 June 2009 01:36:10 Steve Izma wrote: Pdflatex is just a tool for going from latex source files to PDF output --a convenience tool, like lilypond --pdf; I think someone has crafted a shortform to accomplish this with groff as well, I suspect you may be referring to my `pdfroff' tool here. No, actually; I thought someone had come up with a kind of -Tpdf? but given the filtering abilities of groff (with PS output) and ps2pdf, this is pretty trivial. While it is true that pdfroff can readily accomplish the trivial conversion from groff -- PostScript -- PDF, that is *not* what this tool is primarily about. The real reason for the creation of pdfroff was to facilitate the production of PDF documents including interactive cross references, as established through the use of the `pdfmark' macro set. The processing needed to implement that extra level of PDF functionality is anything but trivial, (and most of it occurs as multiple-pass groff processing, long before any PostScript is ever generated). Your throw away this is pretty trivial remark does rather tend to sell pdfroff (and pdfmark.tmac) short. I'm familiar with your pdfroff and I think it's extremely interesting, so I definitely didn't mean to trivialize that. Pdfroff is going to become more and more important because of the need for publishers to produce sophisticated PDFs with lots of cross references and internal links for on-line reading and e-book readers. We've got a series of books that I want to enhance with pdfroff, but I've gotten stymied by the fact that the author insists on unstructured subheadings. Instead of a normal hierarchy (e.g., h1 h2 h2 h1 h2 h3 h3 h1, etc.) she insists on sticking in subheads wherever she feels like giving more emphasis to a section. It makes the table of contents look very messy as well. Sometime soon I will look more closely at pdfroff to try and work around this. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting Software
On Wed, Jun 03, 2009 at 08:55:23AM +0100, John¹ wrote: Subject: [Groff] Typesetting Software Many years ago, when type used to be set by hand, I was one of those who did the typesetting. I am now looking at the methodology of using either Groff or LaTex to produce print ready text. Can anyone briefly tell me if Groff does the same job as LaTex? Obviously there will be a bias in asking this group but does one have an advantage over the other? For me, a big difference between the two is that groff is a filter and tex is not. In other words, if you want to convert your input from some customized markup to groff input, you can put groff in the middle of a pipeline and get extremely fast results. With tex and latex you need to use intermediary files. Also, I've always had to run latex twice in order to get cross references to update; no different than groff. () ascii ribbon campaign - against html mail /\- against microsoft attachments This is a great signature line, which I haven't seen before. Does it have an open-source licence so that I can use it too? -- Steve -- Steve Izma Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press FAX: 519-725-1399 Waterloo, Ont., Canada N2L 3C5st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Typesetting Software
On Wed, Jun 03, 2009 at 08:57:32PM +0200, Tadziu Hoffmann wrote: Subject: Re: [Groff] Typesetting Software using 'pdflatex' on the other hand allows to keep everything as pdf. that's nicer. PDF sucks. It's not programmable, and mostly impossible to write and edit by hand. Not sure what you're getting at here. Pdflatex is just a tool for going from latex source files to PDF output --a convenience tool, like lilypond --pdf; I think someone has crafted a shortform to accomplish this with groff as well, but given the filtering abilities of groff (with PS output) and ps2pdf, this is pretty trivial. I also find it much safer to keep a copy of the output of a complex project (like a book) as well as the source code; macro package interaction with groff can change in subtle ways over the years and you can't count on reproducing a book in precisely the same way by re-running it ten years later (or 15 or so years, as I've tried once or twice). And if you try, you might find yourself needing to re-write the index. PDF is the most compact format for output that I know of. -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener N2H 1W6 p:519-745-1313 FAX:519-579-9872 Work: Wilfrid Laurier University Press p:519-884-0710 ext. 6125 E-mail: si...@golden.net or st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Creating Word/rtf output
On Tue, Mar 03, 2009 at 07:52:40PM -0700, Clarke Echols wrote: Subject: Re: [Groff] Creating Word/rtf output ... My only problem is not being able to embed PS or Type1 fonts into the PDF files. Haven't figured out the magic to do that... But if the printer has standard PS fonts on their system and I ship a PDF using PS font metrics, I think it's supposed to work. It would be nice if there was a nice easy way to load Type1 fonts on an Ubuntu Linux system and get real fonts printed on an HP LaserJet 4200 (black/white) or 4600 (4-color) like I have. My experience is that grops always embeds fonts (other than the basic 35 PostScript ones) in its output and that ps2pdf preserves this. It appears that you could also get grops to embed any of the 35 PS fonts by naming them in the download file in the devps directory, but I've never needed to do this for Times, Helvetica, etc., in files I've sent to various printshops over the years. By a nice easy way, do you mean a single command? I wrap afmtodit and pfbtops into a shell script that also creates a line for the download file, but the way you do this depends on how you've organized .afm and .pfb files and encodings, textmaps, etc. Since sometimes I get fonts that don't have afms, I need to download them from Adobe's site, so almost all the difficulty for me is getting the fonts and related files into the right places. Is that what you mean by not having a nice easy way? -- Steve -- Steve Izma Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press FAX: 519-725-1399 Waterloo, Ont., Canada N2L 3C5st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] Creating Word/rtf output
On Tue, Mar 03, 2009 at 10:36:13AM -0500, Robert Goulding wrote: Subject: [Groff] Creating Word/rtf output OK, so I've almost finished writing an entire book with groff. Nothing fancy involved: no equations or pictures, but LOTS of footnotes and refer tags. I'm 2 weeks away from submitting the manuscript, and have just let the editor know that I can send him pdfs, and gnu troff source files -- or, if those really won't fly, very simply formatted HTML files; to which he replies: GNU troff?? What is that? These days the publishers really want either MSWord or TEX files. We can try the HTML result, but I predict lots of issues in the typesetting! You'll be correcting proofs for weeks. I always thought that publishers wanted well-typeset output. Maybe some don't care Why don't they let you produce the final pages for them? That should save them a bundle. If the copy editor insists on on-line editing, then maybe converting to HTML and putting the results on a wiki for collaborative editing would work (I'm about to try this myself with an author). Moving those changes back into your groff source files should be a lot easier than dealing with the footnote problems you mentioned. If the copy editor edits on paper, then there shouldn't be any issue at all, as long as the publisher gives you clear specs for what they want for final pages. But I've been producing PDFs from groff for printers for about fifteen years now, so there's certainly no technical impediment to providing typeset pages to publishers. (You better get the copyright page correct though.) -- Steve -- Steve Izma Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press FAX: 519-725-1399 Waterloo, Ont., Canada N2L 3C5st...@press.wlu.ca A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [Groff] problem with nested diversions
On Mon, Aug 18, 2008 at 07:48:58PM +0200, Werner LEMBERG wrote: Subject: Re: [Groff] problem with nested diversions [**] That's why I find Werner's solution a bit ugly, because it has to unformat processed text. I was aware of a solution using .de, however, this isn't always applicable. Additionally, he had a specific request about `\!' which I tried to answer. Finally, I don't think at all that my solution is ugly :-) Much thanks to both of you. I've got Werner's solution mostly working in my situation, but I'm still testing. For some reason, different amounts of text in the footnote seem to trigger different reactions in the formatting. I'll report back as soon as I have something more scientifically established. (As well, I have comments about all the comments.) Thanks again, -- Steve -- Steve Izma - Home: 35 Locust St., Kitchener (519) 745-1313 FAX (519)579-9872 Work: Wilfrid Laurier University Press (519) 884-0710 ext. 6125 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED]
[Groff] problem with nested diversions
I can't figure out how a nested diversion fits into the text flow
when its parent diversion is being output. The calls for the
macro containing the nested diversion seem out of place relative
to the text flow.
I emulate the problem with a single block of text captured into
diversion a; it contains calls to a pair of footnote macros
that need to capture the text between them for positioning at the
bottom of the page (or after the main diversion has been output).
For reasons outlined at the end of this message (which gives
the details of the project where this problem arose), I can't
process the footnote when the parent diversion is being read; it
must only be processed when the diversion is being output. And
so I re-embed the pair of macro calls in the text with \!. But
when the macros are finally called on the output of the parent
text, they don't properly capture the footnote text that they had
originally surrounded.
Here's the text sample (complete sample is attached, along with a
PDF of the output):
.di a
Even without publication, Nightingale's \fISuggestions for
Thought\fP attracted much scholarly attention. Several editions
of excerpts have been published. Three books of excerpts, and a
separate edition of ``Cassandra,'' were published later in the
twentieth century.\c
.fn(( 1
Michael D. Calabria and Janet A. Macrae, eds.,
\fISuggestions for Thought by Florence Nightingale\fP.
.fn))
As usual the official biography, E.T. Cook's \fIThe Life of
Florence Nightingale\fP, can be counted on for excellent
background on the purpose and writing.
.br
.di
.nf
.a
.sp
.fnote
The two footnote macros test to see if they're inside diversion
a; if so, they set the superior figure, which should follow
immediately after the last word of the text before the macro call
(i.e., century). Then they embed a call to themselves before
quitting:
.de fn((
.ie '\\n[.z]'a' \{\
. nop \s-2\u\\$1\d\s0
. nop \!.fn(( \\$@
.\}
.el \{\
. ev note
. di fnote
. nop \\$1.
.\}
..
.de fn))
.ie '\\n[.z]'a' \!.fn))
.el \{\
. br
. di
. ev
.\}
..
The output shows the following fragment captured in the
diversion fnote:
dra,'' were published later in the twentieth century.1
Michael D. Calabria and Janet A. Macrae, eds., Sug-
This is printed at the bottom of the page. The text block itself
is interrupted at Cassan- and then continues with:
gestions for Thought by Florence Nightingale
As usual the official biography, E.T. Cook's ...
so no text actually goes missing.
It appears that the captured text is part of a re-formatted input
stream, starting immediately after the last full output line
rather than at the position where the embedded macro is called.
The parent diversion is being output in no-fill mode.
Any ideas?
I'm using groff 1.18.1 on a Debian system.
Why do I need this?
I have a project that requires two columns per page, but each
column is a separate flow of text, like a table with two text
blocks side-by-side. The left column represents an original
manuscript and the right column the published version. (It's
actually much more complicated than this, but I don't think the
additional details make a difference in this problem.)
Because of the differences in the text, the blocks are rarely the
same size. But when the texts come back into sync, they need to
both start in the same vertical place on the page, just like a
new row in a table.
If the left block runs past the bottom of the page, its run-over
contents need to be captured in a diversion and kept until the
right block is printed on the current page. At the start of the
next page, the remains of the left block are output first before
the next pair of blocks is processed.
The problem arises when a footnote occurs in the diverted remains
of the left block. I don't want the footnote to be added to any
collection of footnotes from the previous page, so I re-embed the
pair of macro calls in the text with \!. But when the macros
are finally called on the output of the remains in the next page,
they don't properly capture the text that they had originally
surrounded, as shown above.
I could probably process the footnote while the remains are
being diverted by putting it into a separate diversion from
all the ones that will actually be output on the current page.
Then I would use that separately diverted footnote to start the
collection of notes for the next page. This would avoid the need
for embedding the footnote macros. But I still hope that the
simpler method outlined above can be made to work, or at least I
hope I get an explanation for its behaviour.
Thanks,
-- Steve
--
Steve Izma
Computing Systems Administrator 519-884-0710 ext. 6125
Wilfrid Laurier University Press FAX: 519-725-1399
Waterloo, Ont., Canada N2L 3C5[EMAIL PROTECTED]
.sp 1i
.po 1i
.ps 11
.vs 13p
.ll 20P
.de fn((
.ie '\\n[.z]'a' \{\
. nop \s-2\u\\$1\d\s0
. nop \!.fn
Re: [Groff] nroff vs. troff conditional using escapes?
On Tue, Feb 26, 2008 at 02:01:57PM +0900, Michael(tm) Smith wrote: Subject: Re: [Groff] nroff vs. troff conditional using escapes? So I think what would actually best for me to try to do is have my app always generated the \c before and after the string, and to preserve any whitespace that follows the string... I convert a lot of xml to groff using python with various parsers (sometimes built-in python parsers, sometimes external like nsgmls, which is extremely fast). I find that I can solve most inline spacing problems with the solutions you and Clarke have discussed, i.e., any time the parser outputs a text line my script prepends \ and appends \c. Also, it seems to me that if a \c starts a line, it gives the same effect as being appended to the previous text line, but I rarely need to deal with this. Using such a python script as a preprocessor for groff is very fast and allows you to do various kinds of string manipulations at very little speed cost. For that reason, I've never bothered to go the XLST route. -- Steve -- Steve Izma Computing Systems Administrator 519-884-0710 ext. 6125 Wilfrid Laurier University Press FAX: 519-725-1399 Waterloo, Ont., Canada N2L 3C5[EMAIL PROTECTED]
