Re: Kemper notectomy spreads, thousands of bytes saved

> On Feb 26, 2024, at 12:13 AM, G. Branden Robinson > wrote: > > Maybe Dave got it written up in the Journal of the American Documenter's > Association? ;-) > > https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=9b6c25510bdb54b4f7f9abbfaf6d136c65202d99 Bravo to Dave! — Larry

Re: Macro package loading best practices

> Dave Kemper wrote: > > On 2/22/24, G. Branden Robinson wrote: >> I've come to think that a set of "best practice" for *roff document >> composition is to: >> >> A. Load your desired full-service macro package (if any) on the command >>line with `-m`. >> B. Load any auxiliary macro pac

Re: [idea] troff -Troff

I’m a little late to the party, but I’ve read Alex’s original post over several times, and I have to wonder if everyone is over-thinking this. > On Feb 16, 2024, at 10:21 AM, Alejandro Colomar wrote: > > Hi Branden! > > I've been thinking about a suggestion I've done in the past. I wanted a >

Re: CHECKSTYLE suggestions: unnecessary quotations and unnecessary \f escape

Ingo Schwarze wrote: > > Alejandro Colomar (man-pages) wrote on Sat, Mar 19, 2022 at 05:07:09PM +0100: > >> While fixing style issues in the man-pages project, >> I'm finding a few recurrent issues that I think you could warn about: >> >> Unnecessary quotations: >> >> [ >> .I "foo bar" >> .I

Re: [BUG] groff: inconsistent behavior of " to separate arguments

> Alejandro Colomar (man-pages) wrote: > > On 3/20/22 10:36, G. Branden Robinson wrote: >> Yes, something about this should become part of groff(7). In >> groff_man_style(7), I have restricted the discussion to advising people >> to use the \(dq special character (also spellable as \[dq]). >

Re: nesting lists in man(7) pages

Ingo Schwarze wrote: > > G. Branden Robinson wrote on Wed, Aug 11, 2021 at 01:16:45AM +1000: > >> but I reckon I should actually step up and try to improve one of the >> generator tools, like pod2man > > That would be a noble deed because pod2man(1) is a very useful tool > and produces almost

Re: WAYTO: indexed man pages

James K. Lowden wrote: > > gromunity: > > In working with my GUI man page viewer (not ready for its first > audition yet) I found myself asking how indexes could be implemented in > current and future man systems, and what groff would have to produce > for a viewer to provide an index affordanc

Re: Modernising UNIX manpages.

JM Marcastel wrote: > I would like to investigate the possibility of using Markdown as an alternate > format for UNIX man-pages. > (Cf. https://github.com/marcastel/marcastel/discussions/7) > > Rather than re-inventing the wheel I would ideally like this to become part > of an existing tool

Re: man-intro (was: getting more out of man pages with less(1) )

James K. Lowden wrote: > Attached is a straw man 1st draft of what an introduction to the man > system might look like. If it clears the threshold of raspberries, > perhaps we can mold it into something useful. > > I think the page should be called man-intro, or intro-man. (Need > help?

Re: Auto-resize paper size during document run?

James K. Lowden wrote: > >> Of course, I can typeset the table separately and assemble the pdf >> pages by hand, but a solution totally controlled from within the >> groff file would be great. > > Not an answer, but in ancient times, your output would have gone a > printer, which might have had

Re: "point size" is not usable as a term

Thank you, Peter and Keith, for saying what I was about to say, and saying it far better (not to mention “bringing receipts” as the cool kids put it). Everyone I know in the tech writing world uses “point size,” including myself. Sure, when one thinks about it, it’s like saying “inch length.” But

Re: Interesting articles

> On Mar 26, 2021, at 4:03 AM, Ulrich Lauther > wrote: > > On Thu, Mar 25, 2021 at 10:30:57PM -0400, Larry Kollar wrote: >> Sometimes, my Twitter feed coughs up some cool articles, like >> this one: "Performance comparison: counting words in Python, >&g

Interesting articles

Sometimes, my Twitter feed coughs up some cool articles, like this one: "Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust” https://benhoyt.com/writings/count-words/ The Awk solution was by far the shortest by line count. Since the runtime for all the different so

Re: [PATCH] mdoc: Update operating system release numbers

Ingo Schwarze wrote: >>> 2. The concept of encoding names and versions of all operating >>> systems is not sustainable in the long run. > >> This was probably a product of its times; there was BSD, only one BSD, >> and then there was System V, and the importance of that conflict caused >>

Re: .EM found missing

\G. Branden Robinson wrote: > > At 2020-11-15T14:13:38+, Dorai Sitaram via wrote: >> UTP strongly hints that the -ms macros have the end-of-input trap .em >> pre-set to a defined macro called .EM, with the implication that if >> the user wants to affect end-of-input behavior they can append

Re: [DRAFT] Revised groff ms manual for review

G. Branden Robinson wrote: > Happy Halloween! > > Ready for something on the gory and disturbing side? I got six staples in my head, day before Halloween. They’re out now, but I had a live-action creepshow going for the day. Bring it. :D > I feel like I'm about 40% of my way through a huge u

Re: What is the difference between GNU groff and Mac OS X groff

Michail Vidiassov wrote: What options are needed to make GNU groff behave the same as Mac OS X groff? > >>> Do >>> export GROFF_NO_SGR=yes >>> in the shell and then try your groff command again. > >> OK. This works. Thanks. >> So, that is the change between 1.19.2 and 1.22.4? > >

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

Werner LEMBERG wrote: >>> There's a Linux version too, if you're interested: >>> https://github.com/talamus/solarize-12x29-psf >> >> A pity there’s no OpenType version. > > Attached :-) Bitmap font embedded in a TTF? Looks nice at its native size, anyway. — Larry

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

John Gardner wrote: > It's called Sun Gallant Demi (or simply "Gallant", as no other weights or > variations of it exist). It's the default console font of SPARC > workstations and SunOS/Solaris; OpenBSD used to use it, until they switched > to a much blander console font

Re: "can't transparently output node at top level"

be > ignored. OK, that’s good. Can you suggest what caused the “unrecoverable error” from Ghostscript at the end of the make run? Thanks, — Larry > ‐‐‐ Original Message ‐‐‐ > Le mardi 20 octobre 2020 06:19, Larry Kollar a écrit : > >> I pulled the latest down, a

Re: UTP Revisited: scoping the project

Ingo Schwarze wrote: >> I've not used another editor where you can pipe chunks of >> text *ad hoc* through scripts or even awk/perl one-liners. > > That doesn't require vim(1) at all. I do that all the time > with vanilla vi(1), for example "!}fmt" to automatically > line-break a paragraph of

Re: UTP Revisited: scoping the project

Marc Chantreux wrote: > > hello, > >> - Update Chapter 3 to cover Vim (including gvim) > > please don't! > > what's nice about reading UTP is to discover the elegance and simplicity > of it all … > > i'm a vibrant fan of vim but i have to admit that even to me, vim don't > belong to this w

UTP Revisited: scoping the project

To be honest, I can’t believe over a fourth of my life has gone by since we started the transcription. Now, with sources where everyone can grab them, maybe we should talk about what we want to do for UTP Revisited. These are just off the top of my head: - Update Chapter 3 to cover Vim (includ

"can't transparently output node at top level"

I pulled the latest down, and did “make.” Things went OK until I got down to the documentation: > GROFFcontrib/mom/examples/letter.pdf > troff: contrib/mom/examples/letter.mom:12: error: can't transparently output > node at top level > GROFFcontrib/mom/examples/mom-pdf.pdf > troff: c

Re: Learning troff - where to start?

> On Oct 16, 2020, at 6:49 PM, Deri wrote: > > On Friday, 16 October 2020 04:23:21 BST Larry Kollar wrote: >>> There is a version with clickable contents and index here:- >>> >>> https://github.com/DeriJames/UTP-1.1/raw/master/utp_book.pdf >> >

Re: Learning troff - where to start?

Deri wrote: > The UTP Revival Project recreated the source code because Tim and > Sale >> were unable to locate a copy of the original source. It is located at: >> >>http://home.windstream.net/kollar/utp/ > > > There is a version with clickable contents and index here:- > > https:/

Re: Learning troff - where to start?

Damian McGuckin wrote: > > The UTP Revival Project recreated the source code because Tim and Sale were > unable to locate a copy of the original source. It is located at: > > http://home.windstream.net/kollar/utp/ > > What an undertaking! > > There is a sentence on that page > >

Re: (off topic?) Docbook? Re: manlint?

John Gardner wrote: > Ironically, modern HTML isn't too dissimilar to nroff(1) output. True. Upon seeing HTML for the first time (around 1986 if IIRC) I was struck by the similarities between it and the -mm macros. > … instead of trying to preserve fonts, colours, margins and columns when > g

Re: (off topic?) Docbook? Re: manlint?

James K. Lowden wrote: >> 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. > > If you limit the feature set to what markdown does, -ms macros are > readable too. It's a little tricky to set up an auto-increme

Re: (off topic?) Docbook? Re: manlint?

A little late to the party, but I do have some experience here. > 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. I’m not going to pronounce Docbook

Re: Description of the naming conventions for variables, macros, etc in MS?

T. Kurt Bond wrote: > Is there a description of the naming conventions used in the groff ms > macros for variables, macros, and so forth? An * seems to mean > internal and ! seems to mean array, for instance. What does @ mean? I think it’s an internal destination-like thing. For example, a l

Re: \: re-enables hyphenation--should it?

On Jul 31, 2020, at 6:41 PM, Dave Kemper wrote: > > On 7/31/20, Larry Kollar wrote: >> It’s a space, which I would presume ends a word. A zero-width space, >> by definition, but still a space. > > I suppose that depends where you're getting your definition. Th

Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)

Dave Kemper wrote: > On 7/31/20, Steve Izma wrote: >> 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. > > Do you kno

Re: \: re-enables hyphenation--should it?

It’s a space, which I would presume ends a word. A zero-width space, by definition, but still a space. I think I’ve run into the same issue, and put \% after the space to prevent hyphenation without thinking much about it. — Larry > On Jul 24, 2020, at 11:40 PM, G. Branden Robinson > wrote: >

Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)

> It's not a question of which implementation has the bigger market > share, but which has the richer feature set. Currently each of them > can do things the other can't. There’s `.if [.g]` and `.if [.neat]` to test for a Groff or Neatroff environment, respectively. Presumably, Heirloom has a si

Re: Future of groff Texinfo manual (was: documentation of hyphenation)

G. Branden Robinson wrote: > > Hmm! It seems the ms stuff in our Texinfo manual may have started life > as an ms document after all. > > IIRC, Larry Kollar is sometimes seen on this list. Maybe he'd be > willing to share a copy of the ms sources so we don't have t

Re: weird \s

Doug McIlroy wrote: > > I've been writing the ugly \s360 since ancient times. Groff still thinks > this means a 36-point 0. But man 7 groff says it means a 3-point 60: > > \s±N Set/increase/decrease the point size to/by N scaled points; N is > a one-digit number in the range

Re: Do you use the test-groff script?

Ingo Schwarze wrote: >> If you use test-groff, > > *Please don't!* I find it useful for checking a new version before I do “make install.” If you meant “don’t use it as your usual way to run groff,” I’d agree. But for testing? It does what I think it should.

Re: GNUism in groff tests, was: pic anomalies

G. Branden Robinson wrote: > A rock star cowboy with a smoke machine to conceal the spit and bailing > wire in his implementation is hailed as a genius. > > An engineer who spends effort building a robust system is regarded as a > cost center. Can I steal these quotes (with attribution)? The

Re: Looking for informations

Ingo Schwarze wrote: > Writing good documentation requires good understanding of the source > code of the program. While writers documenting free software often > have that, translators almost never have it. Translated documentation > is almost always of much lower quality than the real thing

Re: [groff] Small general question concerning ms macro package

> On Aug 21, 2019, at 8:45 AM, Mikkel Meinike Nielsen wrote: > > No haven't done any prosper "homework" before asking. Just wanted to here > your opinion. Actually what I won't is a text box or a very specificly > placed column of text. Much can be found by doing “man groff_ms” (assuming your

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

> On Jul 2, 2019, at 8:20 PM, John Gardner wrote: > >> *There were 24 lines per page unless over-ridden on the command line.* >> *The tool was real unix tool, lean and mean with only a few arguments.* >> *It was far less functional than either 'more' or 'less' but it did**let >> you page throu

Re: [groff] Problems with -Thtml

Blake McBride wrote: > Greetings, > > I composed a user manual with MM. Looks great. I now need an HTML > version. I tried: > > groff -Thtml -mm build-manual.mm >build-manual.html > > The HTML file I got is unusable. It has the following problems: > > 1. The escape sequence '\s0' does

Re: [groff] GNU troff version 1.22.4

> Bertrand Garrigues wrote: > > After a last commit (copyright year displayed on 'groff --version'), > I've created tag 1.22.4 and pushed the official package on GNU ftp. > Below is the annoucement done on the GNU info mailing list. Bravo to all who participated in the release! Too bad we cou

Re: [groff] mom: blockquotes lose indent across page breaks

Ingo Schwarze wrote: > Peter Schaffter wrote on Tue, Dec 18, 2018 at 01:41:45PM -0500: >> On Tue, Dec 18, 2018, Ingo Schwarze wrote: >>> Peter Schaffter wrote on Mon, Dec 17, 2018 at 08:55:04PM -0500: > I've updated mom-2.4.tar.gz on mom's website, > >>> Never change tarballs after they

[groff] Work-related rants

They have some groff-relevance, so I thought I’d share. Both have to do with our recent move to DITA at work. Rant the First: conditional page breaks = Like *roff, making a PDF from DITA involves going straight from source through a formatting processor to PDF. Unli

Re: [groff] Regularize (sub)section cross references.

> On Dec 14, 2018, at 2:13 PM, Ingo Schwarze wrote: > > G. Branden Robinson wrote on Fri, Dec 14, 2018 at 10:46:57AM -0500: > >> […] >> . >> -See the >> -.B BUGS >> -section below. >> +See section \(lqBugs\(rq below. > > ... but i disagree with this particular change s/BUGS/Bugs/. > > There

Re: [groff] Release Candidate 1.22.4.rc3

Ingo Schwarze wrote: > >> Being a fan of semantic markup myself, I'd normally agree. >> On the other hand, wouldn't the groff manpages always come >> with a groff formatter? > > Don't FreeBSD manual pages always come with FreeBSD and Linux manual > pages always with Linux? No, they dont't, i

Re: [groff] Release Candidate 1.22.4.rc3

Ingo Schwarze wrote: >> * My semantic macro package extending groff_man(7), if I can get it >> where I'm happy with it and folks on the list don't bleed from the >> eyes about it. > > That would be a HUGE step backwards, making the groff manual pages > even less portable (they are already am

Re: [groff] Release Candidate 1.22.4.rc3

Ingo Schwarze wrote: > While i'm well aware that what i'm saying here is a commitment to > a huge project, i'm willing to translate the whole groff texinfo > documentation into groff_mdoc(7). That’s going to be an impressive undertaking. I’m trying to visualize the results—would you make each

Re: [groff] man-page fixes

> Damian McGuckin wrote: > > In what seems like a gazillion years ago, both DEC and IBM wrote manuals > using a subset of English to make their manuals easy to read for those for > whom English was not a native language. I would love to be able to find the > rules which governed the writing

Re: [groff] man-page fixes

Ingo Schwarze wrote: > Doug McIlroy wrote on Thu, Nov 15, 2018 at 08:40:14PM -0500: > >> Regardless of standards considerations, if there's any advice >> that needs to be hammered into man authors, it's to be concise >> and accurate, but not pedantic. As Will Strunk commanded, >> "Omit needle

Re: [groff] Bold v Italics: Dawn of Justice

> Ingo Schwarze wrote: > >> Use italics > >> for environment variables, >> for enumeration or preprocessor constants in C, > > I don't particularly like that, and i also don't particularly like > Werner's alternative suggestion of setting them in bold; i'd prefer > roman, even though that al

Re: [groff] Inexplicable error using tbl(1) 1.19.2 on macOS

> John Gardner wrote: > > Now, we all know Apple are clueless and continue to ship the most ancient > versions of software fathomable, but I find it impossible to believe that > at some point in Groff's history, there was a published tbl(1) release > whose only purpose was to spit confusing er

Re: [groff] Creating a numbered list without macros

> Ralph Corderoy wrote: > > We're not entirely sure what he wants. ... Perhaps troff syntax, even with > mainly light-noise macros, would be off-putting to his users and so he's > wanting a pre-processor that produces troff. The input language could > be largely based on indentation, for exa

Re: [groff] Groff & tbl as a report generator

Blake McBride wrote: > Thanks. I've seen a tool or two that converts HTML to PDF in the past but > I immediately shied away from them for the following reasons. > > 1. I figured HTML was just too loosey-goosey with the layout. I wanted > better control. > > 2. I figured HTML didn't deal with

Re: [groff] Spooky action at a distance in line adjustment...sometimes

> Ancient history: when I wrote BCPL roff, I immediately noticed the > page-level density gradient from thick on the left to thin on the > right if padding spaces were inserted from the right. I next tried > randomly distributing the padding. This was even worse because it > led one to perceive

Re: [groff] Now online: gropdf / grops previewer

John Gardner wrote: > Well, here it is: > > https://rawgit.com/Alhadis/Roff.js/web-demo/index.html > Oh, cool. It’s like a web version of xditview(1). If it can update live, I’d use it as a previewer. Larry

Re: [groff] groff as the basis for comprehensive documentation?

Some of this is really cool, and ties in with a couple things I’ve tried in the past. John Gardner wrote: > *1. Handling semantics* > We all know you can't draw semantics from cold, low-level formatting > commands. But for certain contexts - hierarchically sorted documents, > consistently inden

Re: [groff] groff as the basis for comprehensive documentation?

John Gardner wrote: > It's ironic how this convention of unconventional formatting has stuck > around since the beginning, but in over 40 years of writing manpages, > nobody's been able to agree on a consistent way of hyphenating the damn > word. > > Manpages, man-pages, or man\(empages? I’ve

Re: [groff] groff as the basis for comprehensive documentation?

Ingo Schwarze wrote: > So yeah, even though proportional font is slowly becoming more > widely used, you may be right: The legacy of Wolfram Schneider's > FreeBSD man.cgi is still pretty widespread and even motivated Michael > Stapelberg to use a fixed width font for Debian, even though the > r

Re: [groff] groff as the basis for comprehensive documentation?

John Gardner wrote: > It's easier than you think.You just have to separate presentational > semantics from structural and content-related ones. I’m fond of saying ‘All you have to do is…’ is one of the biggest lies ever told. ;-D > I've seen grohtml's complexity and was bewildered. Hence why

Re: [groff] groff as the basis for comprehensive documentation?

Nate Bargmann wrote: > I have long been involved with a project that has lacked good > documentation for nearly all of its existence. We've had documentation, > but it isn't in a good format for generating man, HTML, or PDF versions. > > Long ago I started with Docbook and then that got to a po

Re: [groff] Macros in their own package ...

> Ralph Corderoy wrote: > >> I’m typesetting entire books out of Markdown (specifically, > >> MultiMarkdown). > > And that's the problem. Markdown is ill specified, poorly thought out, > and in consequence there are many dialects of Markdown. I always find it amusing when someone on a *roff

Re: [groff] Macros in their own package ...

> John Gardner wrote: > >> There are been attempts (doclifter and -Thtml being two of the most >> ambitious) to make *roff output interchangeable with the rest of the world > I have something planned. But it's so ruthlessly absurd nobody would take > it seriously without proof. =) Hence why I'

Re: [groff] Macros in their own package ...

> John Gardner wrote: > > Apropos of compatibility outside `groff`... > > Does anybody know of an exhaustive list of *roff implementations still in > common use? (Including legacy repositories of historical interest) > > The current Roff interpreters I'm aware of are: > > 1. *GNU Troff

Re: [groff] Compilation of 1.22.3 doesn't work properly

Robert Marks wrote: > I have twice downloaded 1.22.3 and compiled it, following the INSTALL > instructions. > > Seems to compile correctly. > Then I install it. > > Then try to process a file (which works fine on another Mac Book Air of > mine). > I get the following error messages on processi

Re: [groff] A typo on fsf groff wiki page, and question about releasing

> John Gardner wrote: > > I'm wondering how many people here might react if I suggested porting the > entire Geoff codebase to JavaScript… LOL go for it! I often joked that nothing useful was ever written in Javascript. That hasn’t been true for a while, but it would be cool to see how you han

Re: [groff] [UTROFF] About fonts

> Pierre-Jean wrote: > > Hello alls, > > > Heirloom Troff can mount OpenType fonts like any other font. It > can also define all kind of ligatures, adapt the kerning, and > enables the OpenType features, as follow. > >.fp 1 R LinLibertine_R otf >.flig R ct \[c_t] st \[s_t] >.featur

Re: [groff] Unintended impact of strip.sed on om.tmac-u?

> Ralph Corderoy wrote: > >* The body of a 'while' request is treated like the body of a > 'de' request: 'gtroff' temporarily stores it in a macro that > is deleted after the loop has been exited. It can > considerably slow down a macro if the body of the 'while' > reque

Re: [groff] [Groff] What does the "-u" in ".tmac-u" mean?

> Werner LEMBERG wrote: > > It's not about saving disk space. Remember that groff is an > interpreted language *without* a translation to an internal > representation.[*] This means, for example, that a comment within a > loop with 1000 repeats gets parsed a thousand times, again and again. >

Re: [Groff] parallel text processing ; vertical and horizontal mode

E. Hoffmann wrote: > > Hello *roffers. > > Excuse me if this question has been answered zillions of time, > or if it is all absurd, but I don't find an answer ... > > I want to typeset parallel texts, like a translation, the original > *always* in the left column, the translation *always* rig

Re: [Groff] Elegant -ms and -mpdfmark documents

> Kristaps Dzonsons wrote: > > Hello groffers, > > I have a survey question regarding -ms and -mpdfmark documents. … > > To wit, I > wonder if anybody who uses -ms and -mpdfmark has any suggestions on > settings to improve the legibility of produced documents. I used ms + pdfmark extensively

Re: [Groff] It is time to modernise "groff"

Modernizing is all well and good, but many people use groff to typeset legacy documents. Indeed, one could argue that groff has done an excellent job of walking that line between modernizing and backward compatibility. We have long names, HTML output (however crude), and a lot of people on this

Re: [Groff] grops:signatur.eps:15: not an integer

> mikkel meinike wrote: > > The eps I used was generated with > > sam2p > > Now I tryed to generat it with gimp and I don't get the error massag from > using that file I remember this happening with some other tool I used to create EPS files. The same tool could produce EPSF files, and they

Re: [Groff] Regarding HTML rendering

Ingo Schwarze wrote: > > ... > > 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. > > Besides, i hate the myt

Re: [Groff] Inappropriate info page!

> Werner LEMBERG wrote: > > Whilst reading the info pages on Groff I came upon the following >>> >>> What following? You have forgotten to add a quote. >> >> He refers to doc/groff.texi line 5060. The wording is questionable >> indeed. > > Oh. I would have never expected that Larry K

Re: [Groff] groff developments - query about any interest?

> Peter Schaffter wrote: > > On Tue, Nov 15, 2016, John Gardner wrote: >> ...I've decided the project *will *be named on NPM as *nroff*, >> with the human-readable title being "Node-Roff". Since any >> *reasonable* person can see why that's an appropriate name for a >> *node-based roff* generat

Re: [Groff] colorized man pages

> Steffen Nurpmeso wrote: > > |still working with a text terminal, I'd expect escape codes to > |be your daily bread and butter, not something to scoff at. > |(Unless I'm missing the good-natured, approving irony here?) > > Yah! It seems control codes won't go away, Unicode adds > some

Re: [Groff] Converting basic units to inches in PostScript

> Damian McGuckin wrote: > > On Wed, 3 Aug 2016, Larry Kollar wrote: > >> Is there some reason you can?t use device-independent units like inches or >> ens? >> >> .in 1i \? One inch indent on all devices >> .in 6n \? Six ens, (1 en is roughly the

Re: [Groff] Converting basic units to inches in PostScript

> John Gardner wrote: > > I'm using the dl register to set page indent with .in, which works fine in > nroff, but generates absurdly large sizes in groff. For instance, a > diversion with a width of 624 in TTY output becomes 286946 in PostScript. > > I'm aware this is connected to the matter of

[Groff] Tines 1.10, an outliner/planner/organizer/notebook

At the end of last year, I forked the moribund console-based hnb outliner code and launched Tines. I’ve mostly focused on improving its planner capabilities… and why am I nattering about this on the Groff list? Version 1.10 has an option to export to groff -ms (or Markdown) through XSLT. You ha

Re: [Groff] Still No Luck Accessing Characters From Zapf Dingbats (Or Any Other Strange Font)

> On May 8, 2016, at 6:27 PM, Henry McGilton > wrote: > > So I am on El Capitan, and I am using the groff which comes installed > with El Capitan, GNU groff version 1.19.2 > > Invoking groff as suggested by Werner: > > groff -k -Tps foo.tr > foo.ps > > groff: invalid option -- k I’ve just

Re: [Groff] .if !dTS - GNU extension?

I’ve looked through this thread and Ingo’s presentation, and several things stand out: * I guess one of the primary issues here is that Groff is GPL, and a BSD distribution wants BSD licenses. That’s valid, if you’re willing to live with the corner-cases. Then again, using something like XHTML

Re: [Groff] groff performance in respect to hardware platform

> Steve Izma wrote: > > I'm wondering how CPU configurations affect groff processing > speed. On a 2007 MacBook Pro, groff would produce a 900-page manual with a few graphics in 2-3 minutes. That was two groff runs to get cross-refs right, including index generation, followed by a ps2pdf run.

Re: [Groff] bad QE in -ms

> Carsten Kunze wrote: > > Doug McIlroy wrote: >> Bad case I: [...] > > It neither works in groff nor in heirloom roff as specified (in original -ms > specification). > > I suggest to make .QS, .QE, .QP work as specified for traditional -ms without > any warnings. Then there may be some re

Re: [Groff] bad QE in -ms

> Doug McIlroy wrote: > > The -ms macro QE typically draws a misleading diagnostic, "unbalanced QE". > This breaks old documents that expect QP-QE (quoted paragraph) to narrow > the text and then restore it. The groff QE does not restore. > > In fact, QE is aliased to RE, which means it will ca

Re: [Groff] pdfmark XN help

> Anton Shterenlikht wrote: > > I discovered pdfmark macro today. > I like it, and would like to use it's > facilities for hyperlinking and automatic > table of contents. > > However, pdfmark.pdf included in groff-1.22.2 > stops just at this point. > Section 3.1.1.1. "The XN Macro" is empty, >

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

> Steve Izma wrote: > > Larry Kollar wrote: >> Subject: Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff >> >> ... Markdown, and most XML-based systems, deliberately >> kick the formatting can down the road so you can focus on your content.

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

> Steffen Nurpmeso wrote: > >> Or plain SGML that i think could use > like/. I think plain SGML is still an interesting language, much >> better than what XML made of it. Aha, I was trying to remember that in SGML. XML explicitly removed all the shortcuts, and introduced the concept of “well-

Re: [Groff] groff ms: Is there an order to setting PS and VS versus PO and LL

(Ted Harding) wrote: > The ms macros have a somewhat deeply hidden mechanism of > storing the existing values of page-offset, line-length > and the like which can cause the kind of effect that Dorai > observes. > > If I intend a non-default page offset (e.g. 0.75i) to be in > force from the ver

Re: [Groff] Lack of professionalism ....

> Tadziu Hoffmann wrote: > >> [...] that this is yet another instance of ungainly galloping >> gnus departing from Unix's original path of simplicity and >> transparency. > > Not really. Unix nroff had an option to create a "compacted" > version of a macro package, which was used because the c

Re: [Groff] OT: PubCSS: Library of CSS and HTML for Academic PDF and HTML.

> Ralph Corderoy wrote: > > Thought this might be of interest to some of the list, despite involving > XML! > >https://github.com/thomaspark/pubcss/#readme > >PubCSS is a library of CSS stylesheets and HTML templates for formatting >academic publications for print and the web. > >

Re: [Groff] adding non-native font directories [Was: fontconfig]

Having “.fam OCR” fail doesn’t surprise me, because it would expect fonts OCRR, OCRI, OCRB, and OCRBI. But “.ft OCRAExtended” should have worked. Has anyone else successfully used site-font? I admit that I’ve always dumped custom fonts into the regular fonts directory. — Larry > On Mar 7, 2015

Re: [Groff] fontconfig

> On Mar 2, 2015, at 6:01 PM, SGT. Garcia wrote: > > is it possible to use fontconfig font families with groff? google is > failing to find anything. I think not. Groff (and other *roff variants) have their own directories and special file formats for font metrics—the data that determines how

Re: [Groff] Blast from the past

> Steffen Nurpmeso wrote: > > Heinz-Jürgen Oertel wrote: > |Am Montag, 9. Februar 2015, 16:19:51 schrieb Peter Schaffter: > |> Groffers -- > |> > |> I don't see any mention of this in the list archives, and it's too > |> wonderful to miss. If you want a glimpse of days gone by, have a > |> lo

Re: [Groff] Proper Small Caps.

> Steve Izma wrote: > > On Tue, Jan 20, 2015 at 07:57:25PM -0500, Doug McIlroy wrote: >> 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 cu

Re: [Groff] [Groff-commit] GNU troff branch, master, updated. dcdf54071d1369e724cffe2e2cfbf0461a3611d1

On Jan 6, 2014, at 2:20 AM, Werner LEMBERG wrote: >> Up to now I was able to friendly ignore it as long as groff wasn't >> affected. [...] > > I'm very sorry that I've inadvertently written to the list; it should > have been a private reply. Bernd, I apologize for `talking behind > your back',

Re: [Groff] extended font macro

Werner LEMBERG wrote: .FONT I text1 R text2 I text3 R text4 is equivalent to .IR text1 text2 text3 text4 >>> >>> I don't particularly like the idea; changing the font for >>> individual strings is very low level manipulation. Groff does have >>> established syntax for that > > I d

Re: [Groff] _Unix Text Processing_ Fails to Build.

Sorry about the long-delayed response, guys. I've been up to my eyeballs with both fiction and reality this month. I must be crazy to have agreed to launch two novellas two weeks apart. :-P I'll apply the Chapter 9 patch, as the patched groff is unlikely to be universal any time soon. In the m

  1   2   3   4   >