Re: Proposed: make \X read its argument in copy mode

Hi Branden, So instead of: > \X'ps: \fB\s(12\m[red]big bold red text in my device command\fP' > > one would write: > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP I believe you meant to provide an example more like this? \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

l get to work. *John Gardner wrote yet another [cat2dit] but it's in JavaScript so not > maximally convenient for a Unix command line grognard.* Thanks for reminding me, Branden. :) I've yet to get V7 Unix working with the latest release of SimH, so that's kind of stalled my abil

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

! — John On Thu, 18 Jan 2024 at 01:08, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2024-01-18T00:43:41+1100, John Gardner wrote: > > I'm a professional graphic designer with access to commercial typeface > > authoring software. Send

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

> https://usenet.trashworldnews.com/?thread=614089 posted February 1988 > Perl Kit, Version 1.0, Copyright (c) 1987, Larry Wall Excuse my Roff,[1] but holy f\*(&#g shit. Is this where it all started? Did one of my favourite programming languages begin with this very newsgroup post? D—amn. Thanks f

Re: Proposed: make \X read its argument in copy mode

> > This assumes you know both the desired font and the desired colour, which > might be defined at other places in the document and not under your control. Yeah, I know. I was trying to gauge how Groff's escape sequences might benefit an \X'…' sequence, and the PostScript I gave was a contrived

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

have, the merrier. As for the scan that Branden and I were referring to, I've uploaded a copy to Dropbox <https://www.dropbox.com/scl/fi/xdkq15am4zon6uosbk0m9/CSTR_54_1976.pdf?rlkey=edu8ftqj33klr6lpjcrjlpdxm&dl=0> for you. Cheers, — John On Thu, 18 Jan 2024 at 18:00, Mychaela Falconia

Re: Proposed: simplify `mso` request

Hi Branden, Wouldn't this conflict with behaviour documented in groff_tmac(5)? From the section *"Inclusion"* (emphasis mine): GNU troff offers an improved feature in the similar request “*mso* > *package-file-name*”, which searches the macro path for > *package-file-name*. Because its argument i

Re: The chat bots have come for groff users

> > Terminals support only four font names: R, I, B, and BI; the *grotty*(1) > man page says more. Attempting to select any other font name will fail; > like much else in Unix, *roff font names are case-sensitive. *groff* > 1.23.0 started issuing diagnostics upon font selection failure in many more

Re: Macro package loading best practices

I tend to begin my documents with the following comment, designed to illustrate for the author what macro packages are used by the document, which preprocessors are needed, etc: .\" uses: -mpdfmark -man -rLL=80 tbl pic eqn I opt for a *descriptive* directive instead of a *prescriptive* one ("uses

Re: Macro package loading best practices

ages do look to see if they’ve already been invoked before > > running through the whole shebang again. > > > > In the case of those of us who have specialized[2] -ms, it would make > > even more sense to use .mso instead of the command line “option.” > > Our modifi

Re: The chat bots have come for groff users

… ugh… Stack Exchange is dead. There is no future, only underwhelming AI gibberish and inevitable model collapse. On Wed, 28 Feb 2024 at 08:27, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2024-02-28T07:30:37+1100, John Gardner wrote: > > > Terminals support onl

Re: An exercise for the brain(-software) (bug #65474)

Well I clearly failed said exercise, because my brain has no idea what the hell it just read. On Thu, 4 Apr 2024 at 08:48, Bjarni Ingi Gislason wrote: > Give more people a chance to see, think and learn. > > The following is from the groff bug report #65474 > > spurious "warning: unbalanced

Re: [PATCH] nextup.3: minor improvements

Hi Vincent, So ideally, the fallback for "±0" should be "+0 or -0", which is > much more readable and less ambiguous than "+-0" or "+/-0". For approximating ± in ASCII, is there some reason \z_+0 hasn't been considered? I'm asking earnestly, as I'm primed to assume overstriking hacks have alrea

Re: [PATCH] nextup.3: minor improvements

this niche, we may as well go all the way. Regards, — John On Fri, 9 Aug 2024 at 16:19, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2024-08-09T15:53:30+1000, John Gardner wrote: > > Hi Vincent, > > Not to horn in, but I think I'm

Re: [PATCH] nextup.3: minor improvements

Hi Branden, Numeric expressions are already valid conditional expressions, so all we'd > need here is a syntax for interpolating an output device parameter. […] As > it happens, `\T` is *not* yet taken. True, but for fields that have lengthy values, it might help to have a syntax for testing the

Re: [PATCH] nextup.3: minor improvements

y with the existing *"+0 or -0"* language is probably the best fallback. Regards, — John On Fri, 9 Aug 2024 at 19:25, Vincent Lefevre wrote: > On 2024-08-09 15:53:30 +1000, John Gardner wrote: > > Hi Vincent, > > > > > So ideally, the fallback for "ą0" s

Unicode support for Troff-specific symbols

In Unicode 13.0, a new block was added to support graphical symbols used on legacy systems,[1] particularly those represented by obscure character encodings (like ATASCII ).[2] I'm wondering if

Re: GNU maintainership update

Congrats, Branden! [1] https://xkcd.com/149/ Fixed that for you: [image: sandwich.png] On Sat, 31 Aug 2024 at 08:26, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi folks, > > Bertrand and I have heard back from the GNU maintainers team. As of > yesterday, they have offere

[Groff] .if !dTS - GNU extension?

Hey everybody, I was digging through Groff's source code when I happened across this line : printf(".if !\\n(.g .ab GNU tbl requires GNU troff.\n" >".if !dTS .ds TS\n" >".if !dTE .ds TE\n" Perhaps I

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

Oh, erm, whoops. Well in my defence, searching for "d" didn't get me terribly far, haha. Thanks! Out of curiosity, would there be any way in classical troff to detect if a macro is defined? Short of diverting the output of .pm I mean... On 28 April 2016 at 03:10, Werner LEMBERG wrote: > > > Thi

Re: [Groff] Permissible characters for hyphenation

> > I have been convinced that soft hyphen is a control character and > not something visual, Almost correct. Soft hyphens *do* describe potential breaking points, but they only become visible when surrounding text is broken. For instance, assume this line had soft-hyphens every 20 characters:

Re: [Groff] Permissible characters for hyphenation

at 23:20, Steffen Nurpmeso wrote: > Hello! > > John Gardner wrote: > |> I have been convinced that soft hyphen is a control character and > |> not something visual, > | > |Almost correct. > | > |Soft hyphens *do* describe potential breaking points, but they

[Groff] GroffHub

Hello everyone! Over the last four months, I've been working on a TextMate-compatible grammar to improve the highlighting of Roff source on GitHub. I submitted my pull request earlier today, and the effect on

Re: [Groff] GroffHub

Thank you! The hardest part was definitely the repeating-font macros

Re: [Groff] GroffHub

> > *That's why .ig doesn't cause subsequent lines to be ignored.* Uh, actually, I completely forgot about that macro... That actually *can* be handled in a line-based fashion, because TextMate operates by opening "scopes" in response to patterns. Thanks for picking up on that! *And why \\fB ins

Re: [Groff] GroffHub

> > *CSTR 54 has a list of the original ones. :-)* Haha, don't worry, I was actually going through it page-by-page when I wrote this. =) I simply meant that I forgot about how that particular macro should affect highlighting. *After a .ft with no arguments, it seems.* Okay, you've just pointe

Re: [Groff] GroffHub

is is a bug with GitHub's Lightshow, which I reported <https://github.com/github/linguist/issues/3130> with something sitting halfway between relief and irritation. I always knew it had buggy handling of newlines, which I attributed to a different regex engine, but yeah, uh,

[Groff] "Bib" preprocessor?

A program called *bib* appears to exist (or have once existed) that was supposedly similar or identical to *refer*. However, aside from a few fleeting references to its existence on Wikipedia and Troff.org , I'm fin

[Groff] Converting basic units to inches in PostScript

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 device resolution, but is there any

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

Hey guys, Hrm, well, adding the `u` suffix to `.in` *did* change the indentation, but it's suddenly too small. If you're curious, the code may be found here . Be aware this was written strictly as a personal challenge; no macros or GNU extensions were us

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

> Use .in \\nWu (capital "W"). Your "W" is the address width in device units. Uh... yeah, you're 100% right. I'm an idiot, haha. I must've been randomly trying different divisions before I knew to append the "u", heh. Thank you!!! On 4 August 2016 at 01:27, Tadziu Hoffmann wrote: > > > Hrm,

Re: [Groff] colorized man pages

Sick-humoured folks might get a laugh out of this gem of ignorance: http://npmjs.com/package/woman Only peripherally-related, but worth a laugh. Regarding what's being said: I agree with Ingo and Denis. The limited formatting of manpages is actually their best feature, because it forces authors

Re: [Groff] colorized man pages

Adding colours to manual-pages is a solution to a problem that doesn't exist. It's purely aesthetic. As both a graphic designer *and* a programmer, I can say with confidence that both disciplines exist to solve problems. If colour is what helps a reader navigate a manpage's content, then the conte

Re: [Groff] colorized man pages

Speaking as a terminal addict, I can confirm that I feel infinitely more productive where single-key shortcuts are burned into my brain. It's true: it takes practice to get used to, but once you've grokked with a shell, you'll understand what true flexibility really is. > Am I the only one who fi

Re: [Groff] colorized man pages

Ah, that reminds me of Hasklig , which also uses ligatures to improve the readability of combined character operators. :-) That Iosevka font looks ace! It's such a shame it feels too squashed on the eyes though (at least to me). Apropos of fonts, does anybody know

Re: [Groff] colorized man pages

Hi Peter, That does look useful, thanks! On an unrelated note, the changes to Roff's syntax highlighting that I mentioned a few weeks ago are now live on GitHub. On 27 August 2016 at 02:05, Peter Schaffter wrote: > John -- > > On Fri, Aug 26, 2016, John Gardner wrote: > &

Re: [Groff] *roff for desktop publishing - is it feasible?

I like to think of Roff as the assembly language of desktop publishing: anything is possible, but don't expect it to be easy. =) On 24 October 2016 at 20:28, Gerard Lally wrote: > On Mon, 24 Oct 2016, at 04:58, Clarke Echols wrote: > > Twenty years ago, I used troff to create camera-ready artwo

Re: [Groff] *roff for desktop publishing - is it feasible?

I feel too young for this mailing list. GROFL. On 25 October 2016 at 02:28, Ted Harding wrote: > On 24-Oct-2016 12:28:05 Gerard Lally wrote: > > On Mon, 24 Oct 2016, at 13:18, Damian McGuckin wrote: > >> On Mon, 24 Oct 2016, Gerard Lally wrote: > >> > >> > I anticipate *roff satisfying 95% of m

Re: [Groff] *roff for desktop publishing - is it feasible?

That's simultaneously impressive and revolting. Great work! I'm going to be sick. (the typophile in me wants me to hang myself) On 25 October 2016 at 09:46, Gerard Lally wrote: > On Mon, 24 Oct 2016, at 23:38, Tadziu Hoffmann wrote: > > > > Just for the lulz, check this out: > > > > www.usm.

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

> > I'm flabbergasted how people can call code interesting that nobody has > seen yet Heh. Even if it were written in Whitespace ? ;-) While we're on the topic of projects and hypothetical interest, maybe I should bring this up...

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

page from declared option descriptions and filtered readme text, then work off that. I want to name the project `nroff` which is a clever contraction of "Node Roff", but this feels morally wrong somehow.. =) On 15 November 2016 at 14:15, James K. Lowden wrote: > On Tue, 15 Nov 2016 1

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

> > *- "...and show me the manpage which your module produced out of it."* *- "Show me one manpage your module has produced."* It sounds like you read my e-mail in reverse before giving up halfway through to shoot vitriol, because the first paragraph states quite clearly it's *an idea:* *> Whil

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

> > *"There is a reason I am keeping these ramblings off-list."* Well you haven't stated the reason, so I'll assume it's fear of opprobrium. *Nota bene:* every reply you send will be publicly echoed back to the mailing list. I've zero patience for arguments, especially one triggered by a modest

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

off". Since any *reasonable* person can see why that's an appropriate name for a *node-based roff* generator. Thanks for the motivation Jan... when something I love working on works somebody up, it gives me incentive to work on it harder. =) On 15 November 2016 at 20:00, John Gardner wrote: &

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

The Germans have a word for what I'm feeling right now, and it's *fremdschämen...* > *I just don't think this is much relevant to groff itself.* Well, it's now come down to sick amusement from seeing unsubstantiated criticism from somebody who *very very blatantly* has no idea what he's talking

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

Sorry about that... I only meant to catch passing opinions, but let things slip... I'll follow up with a future thread with feedback once there's something ready to show. :) On 15 November 2016 at 22:57, Ralph Corderoy wrote: > Hi John, > > > I plan to develop a Node.js module to generate manp

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

> > even though massive amount of *manpower* has been put in this I'm calling you out on that pun. =) Regarding HTML... I fully hear what you're saying. Somebody asked for a realtime preview of manual-page editing for Atom (a text editor which

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

27;ll stop explaining, because I'm sure half of this list are cringing at how absurd this all sounds (don't worry, I'm inclined to agree with you). #younger-generation On 20 November 2016 at 03:05, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Sun, Nov 20, 201

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

ot;man-pages" that uses it for easy/obvious manpage generation. On 28 November 2016 at 12:54, Larry Kollar wrote: > > > Peter Schaffter wrote: > > > > On Tue, Nov 15, 2016, John Gardner wrote: > >> ...I've decided the project *will *be named on NPM a

[Groff] What does .\" NS mean in the unstripped tmac files?

I'm digging through Groff's source, and I found this puzzling acronym littered throughout tmac/doc-common-u: .\" NS Dd user macro (not parsed, not callable) .\" NS set document date .\" NS .\" NS modifies: .\" NS doc-date-string .\" NS doc-command-name .\" NS .\" NS local variables: .\" NS

Re: [Groff] What does .\" NS mean in the unstripped tmac files?

Excellent sleuth work, Ralph! (As always) Thanks! However, I was more curious about what it was an abbreviation for, believing it was "recently" added (with "recent addition" meaning anything added to Groff's codebase within the last 10 years). Given Roff's longevity, it becomes easy to forget ho

Re: [Groff] What does .\" NS mean in the unstripped tmac files?

40, Ingo Schwarze wrote: > Hi, > > oops, just noticed when looking at John's initial message: > > John Gardner wrote on Sat, Feb 25, 2017 at 07:38:52PM +1100: > > > I'm digging through Groff's source, and I found this puzzling acronym > > littered throug

Re: [Groff] Nesting font macros in man pages

This touches on something I experienced recently. I wanted to write a JavaScript module that would help developers generate manual-pages for their projects (because there's a searing lack of manpages in the Node community...). I ended up ditching that idea when I realised developers would still be

[Groff] Problems with arcs and angles

Hello! Some time ago, I announced my intent to build a man-page previewer for a text-editor named Atom . Work is coming along nicely: this page was generated using a lightweig

Re: [Groff] Problems with arcs and angles

/ 180; > } If you tinker with the angles passed to `startAngle` and `endAngle`, you'll see how the curvature is calculated. Honestly, I'm starting to think this implementation is really backwards. Kernighan's approach is much easier to get my head around... On 28 April 2017

Re: [Groff] bug in macro '.IR' (was ASCII Minus Sign in man Pages).

Yikes, that's an ugly dark side. > Those artificial barriers make it even more important that those > people who do not mind signing an FSF Copyright assignment do > actively contribute, and if that should result in an invitation to > join the groff project, become committers and help to review a

Re: [Groff] bug in macro '.IR' (was ASCII Minus Sign in man Pages).

ld be taken too seriously, BTW. On 28 April 2017 at 23:32, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Fri, Apr 28, 2017 at 11:14:55PM +1000: > > > ISC forever! > > Well, kind of "no" in the present context. > > While i do personally prefer the ISC l

Re: [Groff] Problems with arcs and angles

Sorry for the delayed response. Some pull-requests needed tending to before I had a chance to go through all this. First, thank you all so much for your help and patience! It truly means a lot. I've not yet got arcs drawing correctly, but I feel I'm coming close. Branden's pointers on trigonometry

Re: [Groff] Nesting font macros in man pages

Chained commands are easier to follow with syntax highlighting: [image: Inline images 1] But I'm still in agreement with Ralph here, at least with regards to complex formatting. Lines like `.It Ar radius` are fine, but the Ns and No commands... ugh. Even when formatting with mdoc, I find it benef

Re: [Groff] Nesting font macros in man pages

> > *By mixing low-level roff(7) syntax into your mdoc(7) document, like > defining* *your own macros, you gratuitiously endanger portability.* ... *You are being selfish. If you forcefully redefine standard macros, the > result* *will look unnatural to *everyone else** Some documents I write

Re: [Groff] Applications of \c in man pages in the wild [LONG]

> > Oh, and pointers to a site that times out: Strange, the site loaded perfectly fine for me. There's not much on the page, though: *Deroff 2.0* Deroff removes roff constructs from documents for the purpose of indexing, > spell checking etc. My own implementation is a little smarter than >

Re: [Groff] ASCII Minus Sign in man Pages

> > For that to paste from a man page, viewed as UTF-8 TTY, Erm, I may be missing something, here... but if monospaced hyphens and minus signs are optically indistinguishable, what's the worth in differentiating between either? IMHO, if any change is to be made, it should be with grotty's handli

Re: [Groff] Critique this bold-italic private macro for man pages

Is there literally no way to identify when a modern (non-GNU) troff is being used? On 4 May 2017 at 05:46, Carsten Kunze wrote: > > Carsten Kunze hat am 3. Mai 2017 um 21:37 > geschrieben: > > > > > E.g., ncurses uses these conditionals in many of its pages: > > > > > > .ie \n(.g .ds `` \(lq >

Re: [Groff] Problems with arcs and angles

) + pow(endY - centreY, 2)) > startAngle = atan2(startY - centreY, startX - centreX) > endAngle = atan2(endY - centreY, endX - centreX) On 30 April 2017 at 20:18, John Gardner wrote: > Sorry for the delayed response. Some pull-requests needed tending to > before I had a chan

Re: [Groff] Problems with arcs and angles

Fair enough. Well, the grops code worked for me too <https://github.com/Alhadis/language-roff/commit/ec8e287cb35f7a91924e02e09af68202d8cddade>, actually. Thanks to everybody again for their help. =) On 9 May 2017 at 21:23, Deri James wrote: > On Tue 09 May 2017 13:55:38 John Gard

Re: [Groff] Problems with arcs and angles

> > *The documentation is correct. The code is wrong. Later code copied > earlier code.* Ugh, that's even more confusing. Looks like gropdf's comments could do with a clean-up: these lines had me confused as well: # do it in 4 pieces my $totang=($endang-$startang)/4; > # Now 1 piece > my $x0=

Re: [Groff] mom : unicode in .INCLUDE'd files

I was bitten by preconv(1) quite recently, actually. Gonna back Ingo here. Can I semi-seriously implore the world to only use UTF-8, and pretend other encodings don't exist? Squash everything into the same shuttle as EBCDIC and blast it into the sun. Heh, another recent (and unpleasant) experience

Re: [Groff] mom : unicode in .INCLUDE'd files

heard plenty before, haha. On 23 July 2017 at 03:19, Keith Marshall wrote: > On 22/07/17 15:06, John Gardner wrote: > > I was bitten by preconv(1) quite recently, actually. Gonna back Ingo > > here. Can I semi-seriously implore the world to only use UTF-8, and > > prete

Re: [Groff] mom : unicode in .INCLUDE'd files

> > UTF-8 and UTF-16 Text Encoding Detection Library That was posted in *2014?? *Suddenly I've forgotten if time's flowing backwards or forwards... What's the rationale for choosing UTF-16 in the first place? It offers nothing that UTF-8 can't already handle... (to my flimsy understanding) On 2

Re: [Groff] mom : unicode in .INCLUDE'd files

Strange, I remember reading that the extra storage space required for regular 7-bit characters is what crippled the adoption of Unicode. Prior to UTF-8, I mean... I wonder if the serviette (napkin) which Ken Thompson plotted UTF-8 on has a home in the MIT museum somewhere... =) On 23 July 2017 at

Re: [Groff] Bitstream vera sans

Hey there, If you have FontForge 's command-line tools installed, you can use this shell function to quickly convert fonts to AFM: $ convert-font Vera.ttf afm H

Re: [Groff] Bitstream vera sans

x27;ve added the list's address for you. =) On 9 August 2017 at 22:49, Pedro A. López-Valencia wrote: > > > On Tue, Aug 8, 2017 at 11:15 PM, John Gardner > wrote: > >> Hey there, >> >> If you have FontForge >> ​...​ >> >> >> > ​Plea

[Groff] Reliably identifying a running Roff processor

The other week, I had an itch to write a Roff snippet to report the name of a running Troff implementation. While this is *not* meant for serious use, it *does* work well to distinguish mandoc(1), groff(1) and Heirloom: .\" Identify the formatter processing the document. .\" The program's name is

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

I'm wondering how many people here might react if I suggested porting the entire Geoff codebase to JavaScript... . On 9 Jan 2018 6:19 am, "Werner LEMBERG" wrote: > > >> Also, groff code is quite old and looks more like 'C with class' > >> and doesn't use templates > > > > Yes, that's in it's f

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

making Groff (or any other *full *Troff implementation) available to pipe the preprocessed and processed page elements to the JS-based postprocessor. Which is why porting Groff's codebase to JavaScript is making it seem more and more like such a great idea... On 10 Jan 2018 1:26 am, &quo

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

> > > *I don’t know exactly, but I usually do configure —prefix=/usr so the > install overwrites the existing groff.Which reminds me… I recently upgraded > to High Sierra. I have to re-install.* I find it helpful to always check Homebrew's formula file (if there is one) to see how they deal wit

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

the backburner due to a broken laptop and no money to replace it. Yours and theirs, - John On 10 January 2018 at 07:38, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Tue, Jan 09, 2018 at 07:24:25PM +1100: > > > I'm wondering how many people here might react if I s

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

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 * (~1989/

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

consequence of its barbaric simplicity. It's convenient for comments and blogs, but it damn well needs to stop there. I can't count how many shitty manpages I've seen that have been the direct result of automated markdown processing. Ugh, don't get me started... On 25

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

> > *It relies on DocBook, which has by far the lowest quality man(7) code > generator on the planet.* I'd say second-lowest... you should see marked(1)'s output: https://github.com/markedjs/marked/blob/master/man/marked.1 On 6 March 2018 at 03:50, Ralph Corderoy wrote: > Hi Ingo, > > > > It'

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

Sidenote: I recently refactored Node.js's manpage to use mdoc macros, advising the project maintainers to stick to to mdoc whenever possible. I linked to OpenBSD's mdoc reference and explained that mandoc itself isn't a full-featured roff interpreter, so

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

I'm not sure whether to stay quiet or point out that you may have misread me... I'm referring to a select choice of words that just happens to neatly fall against the 72-character limit... =) Here's the commit message I was referring to: Like man(7), mdoc(7) is a macro package for marking up comp

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

Deri, that book looks like a fantastic example or something I can show to demonstrate the capability of my Troff Renderer (which is currently blocked on more mathematical-related nonsense...Do you have the Roff source for that book, perchance? On 17 April 2018 at 03:33, wrote: > On Monday, 16 A

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

-left corner of the screen... well, you can't just scroll into -345cms looking for where the mangified content went... :( On 17 April 2018 at 04:05, ZEN wrote: > I am afraid it is at home, I am in Cornwall at the moment, will send it to > you next week. > > > > On 16 April 201

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

> > *Groff is not the ideal system for generating HTML.* It's easier than you think.You just have to separate presentational semantics from structural and content-related ones. Personally, I feel HTML generators should emit only semantic markup and leave it to structure and external stylesheets

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

> > > *This is the thing I miss most about Konqueror: you could type a URI > like**“man:mdoc” > and it would format and display the page* There'll be a feature like that in Atom. The editor recently introduced a feature where extension authors can register an external/custom protocol to open lin

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

om/Alhadis/Stylesheets/master/complete/manpage/manpage.css> : On 21 April 2018 at 05:54, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Sat, Apr 21, 2018 at 04:19:06AM +1000: > > > My Troff previewer will be doing just that for > > man://mandoc/1/. =) >

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

ly presentational one to readers, but one that can have an adverse effect on screen-readers and other accessibility software which interpret ALLCAPS as a list of letters to read back to the user, one by one... On 21 April 2018 at 07:43, Keith Marshall wrote: > On 20/04/18 19:19, John Ga

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

Every instance of the "SHOUTED" headings can be uppercased too, even when used outside their role as a heading. The CSS to achieve this: a[href="#name"], a[href="#description"], a[href="#authors"] { text-transform: uppercase; } Will typecast any link pointing to in majuscule "NAME". It's all C

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

this list reading this email... *"Hah! Good luck building your magical, semantic-detection from > pixel-drawing commands, kid!"* Brace yourselves for the gory details of how I'm gonna have a crack at this... On 21 April 2018 at 09:04, Steffen Nurpmeso wrote: > John Gardner w

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

First, leave performance expectations at the door. The ambitious experiment I describe below is intended to provide airtight handling for a conversion medium which is inherently lossy (Roff -> HTML/SVG/CSS/et al, Markdown, and Markdown with GitHub-flavoured options). *1. Handling semantics* We al

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

and repeating default properties. Many values aren't actually doing anything, and several rulesets are empty altogether. I can't go on. I'm feeling queasy with fremdschämen. Seriously. On 21 April 2018 at 07:19, Ingo Schwarze wrote: > Hi John, > > John Gardner wrot

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

Hi Branden, I'll reply to your query about pan-and-zoom transformations in another thread, as I'm preparing a demo/preview to help explain what I mean. =) Just responding to your other points: > > > > *the forced-full-capitalization of section titles in man page sources is > aninformation-destro

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

*> The section heading examples in man-pages(7) are in all upper case.* 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. Manpag

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

> > None of those, and certainly not an em dash. It's `man page', short for > `manual pages'. Haha, don't worry! =) I was being facetious. Probably could've communicated the joke better with `man\D'l 99n 0'pages` instead. In all seriousness, I can be horribly inconsistent with hyphenation in gen

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

lities and assistive technologies were too complex to be addressed by CSS alone, so it was deferred to WAI-ARIA instead... On 22 April 2018 at 00:54, John Gardner wrote: > None of those, and certainly not an em dash. It's `man page', short for >> `manual pages'. >

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

.imgur.com/OMjYcDl.png> is what I'm looking at right now... I keep forgetting how this must look to users of other mail clients... :( On 22 April 2018 at 01:06, Larry Kollar wrote: > Some of this is really cool, and ties in with a couple things I’ve tried > in the past. > >

[groff] Now online: gropdf / grops previewer

Well, here it is: https://rawgit.com/Alhadis/Roff.js/web-demo/index.html Some modifications were needed for web-delivery, and performance still isn't optimal, but it works. You'll need a relatively recent browser to use it (anything released within the last year should do). Few things to note be

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

s charged with no such meaning. Also, consider enclosing each section and subsection in an element with an ID (the way I've done). If an author wants to style .Nm differently in the preamble, for example, they can use #name dfn . Nitpick: consider renaming .selflink to .permalink instea

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

ndard Symbols L - Symbol - serif - oblique The first two are included in the URW Base35 fonts, which as I explained are sanely omitted from the web-demo, as it would add a big hit to load-time. =) Could you try installing the StandardSymbolsPS font from GhostScript's fonts repo? On 23 April 201

  1   2   3   4   >