[bug #62233] [doc] Stop referring to Roff as a group of languages

URL: Summary: [doc] Stop referring to Roff as a group of languages Project: GNU troff Submitted by: alhadis Submitted on: Wed 30 Mar 2022 12:49:36 PM AEDT Category: General

Re: Question on hyperlinks in groff

Hi Chems, When reading the s.tmac file, specifically the description for the .[ > macro, it mentions a macro called .#, but I can't find its definition > anywhere. > Both the .[ and .# macros belong to the Mono package . This is a project of mine (i.e., not part

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

> GMail did the exact same thing to me with the same 3 emails from Ingo. > His messages since then _seem_ to have gotten to me reliably. I recently had to add a Gmail filter to mark e-mails from Ingo as *NOT* spam. He e-mailed me again recently and I nearly missed it under the usual deluge of

Re: Five glyphs: a minor PostScript challenge

> > Does anyone have enough PostScript wizardry to achieve any of this? I do. I'm quite fluent in PostScript programming, and your suspicions about the dynamic glyph generation are correct. I'll have a more

Re: Groff hanging when called from Java

Are you sure the process isn't waiting for input from an interactive (TTY-attached) STDIN stream? Try sending ^D (CTRL+D), which should tell it that it's reached EOF. I don't know much about Java, only that it's weird and gross (so I have to assume writing to /dev/stderr or even /dev/console

Re: Should vertical motions be in vees or ems? Where does the baseline go?

l did not have drawing capability, so it created > > horizontal lines as a row of underscores. The vertical position and > > thickness of such a line is determined by the current font. Later, in > > ditroff, Kernighan introduced \D drawing capability. Then the position > > and thickne

[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

Follow-up Comment #15, bug #60602 (project groff): > In fact, a C version of cat2dit that would run on V7 Unix under SIMH would, in my imagination, kick ass. (People really wanted one, back in the '80s.) Then there would be no data migration issue or octal dumping to mess with. Run SIMH in a

[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

Follow-up Comment #14, bug #60602 (project groff): > this GitHub project seems not to have been updated in a while (December 2019, IIRC), and Node itself has moved on. That's not how things work in the JavaScript world. ECMAScript, unlike Python, is designed to remain compatible with all

[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

Follow-up Comment #8, bug #60602 (project groff): > Excellent! Except...maybe my JS environment is too old? `Array.prototype.flat` was only added to the ECMAScript spec in 2019, so it's possible your version of Node.js is outdated. If your distro's lagging behind (i.e., upgrading doesn't

[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

Follow-up Comment #6, bug #60602 (project groff): > Now all I need is a way to get V7 troff CAT output out of the SIMH instance I'm running. > […] > Maybe I can od(1) it and then parse it back into a real stream. That's exactly what I do. I use this

[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

Follow-up Comment #4, bug #60602 (project groff): > because I have nothing that can interpret the Graphic Systems C/A/T command stream the former produces. I do : $ cat2dit -Tps < output.cat | grops

Re: No rule to make target `tmac/mdoc/doc-common', needed by `all-am'. Stop.

Hi Axel, Before running ./bootstrap from the root directory, make sure *all *build artefacts are wiped: git pull && git checkout -- . && git clean -xfd I recall seeing this exact error a while ago when attempting to recompile Groff. It might be related. On Fri, 29 Oct 2021 at 05:18, Axel

Re: Portability to Mac OS X (was: Sed failure in contrib/sboxes on MacOS)

I want an excuse to separate Groff from the TeX world as much as humanly possible…) On Fri, 29 Oct 2021 at 04:27, John Gardner wrote: > In lieu of escaped newlines and awkward sed(1) formatting, you can use > the following line to insert an empty line: > > /^Before$/ { N; s/\n/&&/;

Re: Portability to Mac OS X (was: Sed failure in contrib/sboxes on MacOS)

In lieu of escaped newlines and awkward sed(1) formatting, you can use the following line to insert an empty line: /^Before$/ { N; s/\n/&&/; } Note that BSD sed(1) is picky about braces and semicolons. I have groff building successfully on Mac OS X now. > I recently upgraded to macOS 12.0.1

Re: Sed failure in contrib/sboxes on MacOS

> > Yes. Mac OS X, at least the version I have access to, uses Bash 3.2 as > its script interpreter, and zsh 5.8 as its interactive shell. > It's more complicated than that. Apple have announced that the default shell (Bash 3.2) will be removed in a future version of macOS, meaning ` /bin/sh`

Re: Two trivial questions

Initially, I pronounced it /ɡɹɔːf/ . Recently, I've begun pronouncing it /ˈdʒiːɹɒf/ , though I sometimes still mentally read it as the former. IMHO, I think we should put our foot down

[bug #61265] macOS sed(1) warns during `make install`

URL: Summary: macOS sed(1) warns during `make install` Project: GNU troff Submitted by: alhadis Submitted on: Sun 03 Oct 2021 06:34:41 AM AEDT Category: None

Re: We have OSC 8 terminal hyperlink support now

I know it's probably a bit early for this discussion, but somebody on GitHub raised a good question : Why x-man-page? dnf reports that yelp & khelpcenter provide man:// - but > has no providers for

Re: We have OSC 8 terminal hyperlink support now

Hi Brandon, That's one small step for a man... one giant leap for man(1)-kind. ;-) Brilliant work! I can't wait to update Mono.tmac to include it! Is there any reliable way for a macro-package to detect support for this at runtime? Also, I spotted a typo in

Re: PROPOSED: semantics for an output line length of zero

9-07T23:22:13+1000, John Gardner wrote: > > I'm not sure I understand the issue here. For the purposes of > > line-wrapping and word-breaking, `.ll 0` is essentially the same as > > `.ll 1u`... isn't it? Even in situations when a typesetter's quantum > > of motion accommodat

Re: PROPOSED: semantics for an output line length of zero

]u long. yields I am 1u long. but also I am 0u long. Am I missing something? On Sun, 5 Sept 2021 at 03:36, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > I'm proposing this on behalf on John Gardner, who raised it in a > Savannah ticket[1]. > > I asked him:

[bug #61089] [troff] assertion failed: 'desired_space.is_zero() && nspaces == 0'

Follow-up Comment #12, bug #61089 (project groff): > What do you expect the semantics of an output line length of zero to be? Like this : This is your line-length This is your line- length on drugs Basically, print as many characters as you can fit up

[bug #61089] [troff] assertion failed: 'desired_space.is_zero() && nspaces == 0'

Follow-up Comment #9, bug #61089 (project groff): > John, is this enough information for you to put together a (much) smaller reproducer? Aye, I narrowed it down to the following test-case: 01 .de _ 02 .na 03 .nh 04 .ll 0 05 .di A 06 \&\\$1 07 .di 08 .br 09 .. 10 ._ "

[bug #61089] distribute_space(): assertion failed:

Follow-up Comment #2, bug #61089 (project groff): > So the change that introduced this assertion failure is somewhere further up the call chain. Is there anything I can do to pinpoint it? ___ Reply to this item at:

Re: Groff examples repository

> > Since John Gardner will (rightly) insist that examples of mdoc(7) code are > nothing more than mere examples of roff(7) code To quote Heisenberg: *"You're goddamn right."* ;-) The Groff examples repository is now available on the web at > https://froude.eu/groff >

[bug #60305] chem(1) still links to long-gone http://cm.bell-labs.com/

Follow-up Comment #4, bug #60305 (project groff): > But tomorrow archive.org could cease to exist. That's an incredibly unlikely scenario that--if it were to happen--would impact a lot of high-traffic sites (like Wikipedia) that rely on Archive.org for reliable citations. It would be noticed

[bug #61089] distribute_space(): assertion failed:

URL: Summary: distribute_space(): assertion failed: Project: GNU troff Submitted by: alhadis Submitted on: Mon 30 Aug 2021 12:57:35 PM AEST Category: Core Severity:

Re: Use various macro packages in the same page (was: Re: Plan 9 man added a new macro for man page references)

> > But the mdoc(7) and man(7) languages can also be regarded as languages > with a grammar I wish people would stop referring to these as "languages". They're macro packages, plain and simple: their "syntax" is that of the language they're written in, Roff. How mandoc(1) implements and parses

Re: Question about ?roff on Reddit

> > John's a sneaky devil. I've never seen the .cw request used in anger > before I'm sorry, I meant to write `.cs`, which was superfluous anyway (since I already set line-length to 1n, which forced lines to be wrapped). I was in a rush and hastily repurposing code from an earlier snippet

Re: Modernising UNIX manpages.

> > I would like to investigate the possibility of using Markdown as an > alternate format for UNIX man-pages. You picked the worst possible markup imaginable. Not just for man pages, but for any technical documentation, *period*. If you're interested in "modernising", I suggest rewriting man

[bug #60305] chem(1) still links to long-gone http://cm.bell-labs.com/

Follow-up Comment #2, bug #60305 (project groff): > I already removed the URLs last September as commit 83326197dce94750d5cb71a4c84402bdb2f3b558. Oops. I just noticed my earlier search for `cm.bell-labs.*` was matching stale artefacts built earlier last year. After running `make clean`, I can

[bug #60305] chem(1) still links to long-gone http://cm.bell-labs.com/

URL: Summary: chem(1) still links to long-gone http://cm.bell-labs.com/ Project: GNU troff Submitted by: alhadis Submitted on: Tue 30 Mar 2021 03:09:14 AM AEDT Category: Core

Re: Interesting articles

Of course, *both* solutions are inadequate when you consider languages other than English (especially agglutinative languages like Hungarian and Turkish). For example, how many "words" are in "

Re: Mangled pdf in Chrome browser?

Also perfect on macOS. Big Sur 11.2.1, Chrome 88.0.4324.182 (Official Build) (x86_64) On Sun, 21 Feb 2021 at 05:35, Heinz-Jürgen Oertel wrote: > Am Samstag, 20. Februar 2021, 17:42:09 CET schrieb Peter Schaffter: > > A user contacted me off list saying that the example pdf file at > > > >

Re: ^G

.com> wrote: > Hi Wim and John, > > At 2021-02-02T23:11:39+1100, John Gardner wrote: > > Hi Wim, > > > > Roff syntax permits certain ASCII control characters in identifiers. > > They're typically used by older macro-packages to avoid naming > > conflicts

Re: ^G

Hi Wim, Roff syntax permits certain ASCII control characters in identifiers. They're typically used by older macro-packages to avoid naming conflicts, or in contexts when an arbitrary delimiter may appear in legitimate texts (such as the .tl request). Acceptable control characters are: - ^B

Re: Huge Filesize of PS file 12M

> > Because I still see a lot of this [in the Postscript file]. Can I somehow > remove them. I don't need all those special characters. In PostScript, you can "initialise" an array with a value with /Encoding [ 255 {/.notdef} repeat ] def % Set array entries individually Encoding 0

Re: Groff algorithm

Both syntax highlighting and elegant algorithm specifications would make great preprocessors. ;-) I find the latter works best when used tastefully (and never, *ever* in a manual page). It'd be trivial to write an Awk script for replacing basic-looking keywords, substituting them with proper

Re: [HELP] [bug #55475] Segmentation fault in libgroff:relocatep

> > In fact, we could really use ongoing assistance from someone with a > Windows environment to test builds on. These VirtualBox images might help to bridge a few gaps… - https://archive.org/details/ie6.xp.virtualbox - https://archive.org/details/ie8.xp.virtualbox -

mdoc: `.Os` macro should stop validating versions

As of this writing, the latest releases of Darwin are 20.2.0 (stable) and 20.3.0 (beta), respectively corresponding to macOS 11.1 and macOS 11.2 beta. However, the `doc-operating-system-*` strings defined in tmac/mdoc/doc-common-u only count up to 19.2.0. Obviously, keeping this list up-to-date

Re: End-of-sentence spacing

> > It was neither the only, first, last, or most vituperous critique of Two > Spaces: There has been a rising tide of condemnation of the practice in the > media, as shown by Googling "two spaces after period". > I condemn two spaces, period. Worst\. Indentation style\. Ever. On Tue, 22 Dec

Re: groff: grops and grodvi crash on invalid input

gnored (For reference, it's complaining about the \X'meta: …' directives I embedded in a few macros) On Mon, 23 Nov 2020 at 02:46, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-11-23T00:10:15+1100, John Gardner wrote: > > IMHO, it would be more intuitive to make this >

[bug #59498] Unescaped wildcards in `strip.sed`

Follow-up Comment #3, bug #59498 (project groff): [comment #2 comment #2:] > The only change here is the escaping of the leading dot in the requests, right? Yep. The change is literally just sed -e '10,11 s|/|/\\|' ... but I'm new to Savannah and have no idea how I'd go about submitting a PR

Re: groff: grops and grodvi crash on invalid input

> > He declared a groff-compatible ps device resolution of 72000 but didn't > scale his arguments. That's assuming he didn't patch devps/DESC locally with an arbitrary ` sizescale` or `unitwidth` parameter (which may have been an attempt to make coordinates easier to visualise). But your point

[bug #59498] Unescaped wildcards in `strip.sed`

URL: Summary: Unescaped wildcards in `strip.sed` Project: GNU troff Submitted by: alhadis Submitted on: Sun 22 Nov 2020 07:13:12 PM AEDT Category: Macro - others

Re: groff: grops and grodvi crash on invalid input

> > In the meantime, John Gardner, who's written his own "ditroff" > interpreter in JavaScript, might be able to offer some useful insights > on the well-formedness of your sample documents. Sorry, I completely missed this. The samples look fine. Try converting their

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

> > A pity there’s no OpenType version. Somebody already made one , although the link they gave is dead. Fortunately, I saved it. One of these days I'll do a high-quality, hand traced version that matches

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

The rest of this reply addresses a few details. > > Yours, > Ingo > > > John Gardner wrote on Mon, Nov 02, 2020 at 11:24:49PM +1100: > > > I think it's time we took constant-width fonts seriously when > > preparing output for the terminal. Here me out on this: > >

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

I think it's time we took constant-width fonts seriously when preparing output for the terminal. Here me out on this: You see, I've never, *ever* needed fancy typography when typesetting code samples, which are invariably set in a fixed-pitch (monspace) typeface. The use of a fixed-pitch font

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

> > To summarize: It seems that there is only a single platform left today > that by default uses a bitmap font for terminals with symmetric ` and > ' characters. This sort-of proves my point, doesn't it? It gets even worse. See, whenever you edit source code, symmetric quote-pairs look like a

Re: Small offset in overlapping Polygons

Mischeen minder kleuren ofzo? ;P (grapje) Nah, looks good. Bravo! On Mon, 2 Nov 2020 at 07:42, Wim Stockman wrote: > So I finished my first small project in groff. Wanted to share with the > community. > If you have any suggestions let me know. > Kind regards > Wim Stockman > > P.S. Keep up

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

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 . It's the only

Re: Observations using utmac

in question). Cheers, — John On Sun, 1 Nov 2020 at 23:32, Pierre-Jean Fichet < pierrejean.fic...@posteo.net> wrote: > > Hello John, > > Thank you for the help. > > John Gardner wrote: > > > It will work when using neatpost and ps2pdf. Neatpdf is great, but as > &g

Re: Observations using utmac

> > It will work when using neatpost and ps2pdf. Neatpdf is great, but as > far as I know, it does not support pdf links yet. It doesn't have to. You can embed PDF-specific features by using PostScript's pdfmark operator

Re: Learning troff - where to start?

> > Maybe we should throw our sources onto Github? Please do. On Fri, 16 Oct 2020 at 14:23, Larry Kollar wrote: > > 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: > >> >

Re: Learning troff - where to start?

> > The UTP Revival Project recreated the source code because Tim and Sale > were unable to locate a copy of the original source. Does anybody know of a similar effort to recreate the source code of the last revision of CSTR #54? (November 1992). On Wed, 14 Oct 2020 at 13:20, Damian McGuckin

Re: Learning troff - where to start?

> > I learned troff entirely from ctsr54. It is not for nothing that > it remains the canonical starting point for exploring groff. I strongly second this. Newcomers should at least be comfortable changing fonts, adjusting margins, and controlling paragraph filling/adjustment. Then they'll move

Re: [DRAFT] introduction to *roff concepts

> > proportionally-spaced font The correct term is "proportional font". The term "tabulation stop" seems overly pedantic Agreed. I'd shorten it to tab stop instead. On Tue, 13 Oct 2020 at 17:42, Dave Kemper wrote: > On 10/10/20, G. Branden

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

> > .SH id=foo class=bar > Your title here Another problem my earlier idea would solve: .SH Your title here \!x X meta: set id foo \!x X meta: set class bar Or, given that \! is subject to diversions, something like: .SH Your

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

om> wrote: > At 2020-09-28T16:37:55+1000, John Gardner wrote: > > Nope, not at all. It's a hand-written portrayal of what I consider to > > be a "perfect" rendition of a man page in HTML. > > That sure looks nice! I hope some day a man(7) page will become worthy > of such love. :D > > Regards, > Branden >

Re: Groff bug: echo foo | groff -Pbar

AM G. Branden Robinson < > g.branden.robin...@gmail.com> wrote: > > > At 2020-09-28T03:44:41+1000, John Gardner wrote: > > > The error I get with groff 1.22.4 is different: > > > > > > $ echo foo | groff -Pbar > > > grops: can't open file 'bar' > > > > I can't reproduce this either, with groff 1.22.4 (Debian) or groff git > > HEAD. > > > > Regards, > > Branden > > >

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

> > Going the reverse direction, groff=>markup language (e.g. HTML), > it is equally evident that only conversions from a known macroset > are going to produce semantically clean results Forget about macro sets, and focus on the Troff pipeline itself. Here's how I'd do it: infer |

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

"perfect" rendition of a man page in HTML. On Mon, 28 Sep 2020 at 12:29, Larry Kollar wrote: > > 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 wa

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

Ironically, modern HTML isn't too dissimilar to nroff(1) output. For a start, document structure and content hierarchy is critical for readability, be it for humans (TTY output) or browsers (web-pages). Secondly, most presentational details are lost because they're irrelevant to the target

Re: Groff bug: echo foo | groff -Pbar

Does it make a difference if you add a prologue file named `bar`? From grops(1): *-P**prologue-file* Use the file *prologue-file* (in the font path) as the prologue instead of the default prologue file *prologue*. The error I get with groff 1.22.4 is different: $ echo foo | groff -Pbar grops:

Re: Let's Play: Use the Source, Luke! (was: .ie as target of .if)

I'm assuming the logic you've described applies to `.while` requests too? (IIRC, this is the only other conditional that shares the semantics of `.ie` and `.if`). The next conditional handles input in...non-copy mode, a thing that no > *roff documentation I have ever seen has a name for. (This

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

wrote: > At 2020-09-18T01:18:06+1000, John Gardner wrote: > > To preserve metadata, or identify regions of semantic or structural > > interest, write a preprocessor to delineate unprocessed roff(7) syntax > > with device control functions: > > > > .TH \X'meta: begin t

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

> > You are tearing me apart, Lisa! Oh hai, Markdown. (For those who don't get these references, consider yourselves blessed...) On Sun, 27 Sep 2020 at 16:26, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-09-16T03:25:54+1000, John Gardner wrote: >

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

> > 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. Markdown has only one feature: readability. Prove me wrong. On Sun, 27 Sep 2020 at 14:14, Larry Kollar wrote: > A little late to the party, but I do have

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

On Thu, 17 Sep 2020 at 23:24, Ingo Schwarze wrote: > Hi, > > John Gardner wrote on Wed, Sep 16, 2020 at 03:25:54AM +1000: > > Somebody wrote: > > >> this *isn't* the same to me: attributes are for metadata > >> and tag contents are for data > > > That

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

> > i also love yaml because it has references, datatypes, overwritting > features Hence why I jokingly call YAML my favourite programming language, taking a stab at its egregious complexity. In all seriousness though, if you need semi-programmatic features like variable references and custom

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

ing if $HOME/ > man.local does not exist; you may wish to include one in /etc/ > skel or an equivalent account configuration system. Further‐ > more, a security-sandboxed man(1) program may lack permission to > open the file. > > I reckon I could add

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

> > this *isn't* the same to me: attributes are for metadata and tag contents > are for data That's what I mean: there isn't always an obvious distinction between data and metadata. For structured HTML-like documents, it's common to see attributes used for anything not seen by readers (i.g.,

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

For output destined for terminal display, it's easy to uphold this convention: .if n \{\ .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ \\$1 .tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz .\} The important part is that the source argument be expressed using "proper"

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

XML is verbose, cumbersome to read and write, and has two different ways to express data structures: My stupid document true Conversely, JSON is more concise and predictable: { "title": "My stupid document", "enabled": true } XML isn't an easy format to (correctly) parse,

Re: .ie as target of .if

No, it isn't valid. What .if and .ie do is read one line, then decide whether it gets processed or skipped, depending on the condition. The real magic is in the \{ sequence, which is the only thing in the Roff language resembling a "multi-line" statement. Troff, in a manner befitting a text

Re: mechanism to inhibit adding new hyphens to hyphenated words?

> See CSTR 54, §13. https://troff.org/54.pdf Or better yet, https://troff.org/54.pdf#page=25 This should link directly to page 25 in PDF-savvy browsers (named destinations can also be deep-linked in such a fashion, although this requires knowledge of the anchor's internal ID, which is usually

Re: Plan 9 man added a new macro for man page references

> Embedding a full URL in man pages sources to an inherently relocatable page hierarchy is a bad idea. I'm sorry, what. man://1/grep man://grep/1 man:grep(1) Syntactic bikeshedding notwithstanding, I fail to see why using the ` *scheme*:*path*` syntax could be construed as a bad idea. (Unless,

Re: Groff should not permit ANSI escapes using \N'27'

d earlier. Is this really our problem to solve? Nope. Pretend this thread never happened. On Fri, 7 Aug 2020 at 00:29, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-07-28T00:26:49+1000, John Gardner wrote: > > Hi folks, > > > > Raw escape characters (U

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

In all fairness, the only thing stopping me from attempting this is my lack of confidence (and general dislike) of C++. Eventually, I might take a crack… probably in an effort to marry the miracle called variable fonts with my love of Troff, fuelled by my lifelong obsession

Re: [Heirloom] Using the Symbola font in Heirloom troff

> Looking at the postscript output there is a "/uni1F0A1 9429 def" and a > "/uni1F10A" in a "/Encoding-@15@36 [...] def"; is that part of the font > machinery? (I'm sadly ignorant of PostScript, alas.) Kind of. PostScript predates Unicode, sadly, and has limits on how many glyphs can be mapped

Re: [Heirloom] Using the Symbola font in Heirloom troff

e: > Thanks for the tip! As it turns out, I am using the OTF. > > On Wed, Aug 5, 2020 at 12:24 AM John Gardner > wrote: > >> > The version I got was .ttf, not .otf >> >> I opened both the original OTF <https://dn-works.com/ufas/> and the >> Fon

Re: [Heirloom] Using the Symbola font in Heirloom troff

> The version I got was .ttf, not .otf I opened both the original OTF and the FontLibrary.org TTF in Glyphs ; the OTF has 12,589 glyphs, whereas the TTF only has 7,956 glyphs. Try the OTF version of

Re: Quick question: how to do .index in groff?

If it DOES get implemented in Groff, please name it `.indexof`. The name `.index` is so horribly misleading I'm almost tempted to submit a PR just to rename it. On Fri, 31 Jul 2020, 2:41 pm B 9, wrote: > "Denis M. Wilson" wrote: > > > Sorry, the macros I've written are .strchr and .strrchr. >

Groff should not permit ANSI escapes using \N'27'

Hi folks, Raw escape characters (U+001B) get stripped from source-code during formatting, but inserting one is still possible using \N'27': \N'27'[4mI don't remember underlining this.\N'27'[0m This has potential security implications for people using `less -R` (and can still mess up terminal

Re: Groff vs Heirloom troff

> yes. but it doesn't mean we can't unite at some point You misunderstand. Some people don't *want* to unite. Some might actively resist an attempt at "unification". On Mon, 27 Jul 2020 at 18:50, Marc Chantreux wrote: > > Lack of "unity" is part of what makes open source what it is. > > yes.

Re: Groff vs Heirloom troff

Even if the entire world agreed on licensing, there'd still be disagreements about implementation or philosophy. Lack of "unity" is part of what makes open source what it is. On Mon, 27 Jul 2020 at 07:34, Marc Chantreux wrote: > hello Ingo, > > thanks for this detailed anwser. > > > The reason

Re: how far can i go with grotty?

> > On Sat, Jul 25, 2020 at 02:57:13PM +1000, John Gardner wrote: > > > > > > also: i need "sed '/^$/q'" at the end of my filter because groff > > > renders a lot of empty lines at the end of the output whenever i > > > use b in my tbl forma

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

> > That groff cannot do the first at all, and requires external helpers > (one of them not even shipped with the package) for the latter two, > ironically makes it look more outdated than its "heirloom" counterpart. What I find laughable as that neither of them support right-to-left languages,

Re: Quick question: how to do .index in groff?

> > but I guess that's an indication I'm thinking about things in the wrong > way. Possibly. What exactly have you been using `.index` for? By the way, is it a goal of groff to support the Heirloom Troff extensions? Nope, more like the other way around. Groff is the dominant Troff

Re: how far can i go with grotty?

> > also: i need "sed '/^$/q'" at the end of my filter because groff > renders a lot of empty lines at the end of the output whenever i > use b in my tbl format. i don't know how to remove it. sed -e :a -e '/^\n*$/{$d;N;};/\n$/ba' On Sat, 25 Jul 2020 at 04:28, Tadziu Hoffmann wrote: > > >

Re: Quick question: how to do .index in groff?

> > Indexing is quite complicated Denis: he's not referring to *content* indexing, but a Heirloom Troff request named `.index` which should arguably be named `.indexof` instead. It simply returns the index of a substring if found within a larger string, presumably returning -1 to indicate

Re: Format-agnostic hyperlinks

algorithm in Groff. ;-) Points for even knowing what that is.  On Fri, 24 Jul 2020 at 16:54, B 9 wrote: > John Gardner wrote: > > > > Does your package interpret the URL that's passed in? > > > > Nope, not at all. URLs are passed through verbatim; authors can always > a

Re: Quick question: how to do .index in groff?

You might be able to achieve this using Groff's .while, .length, and .substring requests. Not sure what use-case a substring's index could be in Roff though... On Fri, 24 Jul 2020 at 09:13, B 9 wrote: > Heirloom Troff has a handy string search function called .index which > works like this: >

Re: Format-agnostic hyperlinks

ve for proper HTML output, but that's a project for another day (or year, more than likely...) On Fri, 24 Jul 2020, 9:09 am B 9, wrote: > John Gardner wrote: > > > Recent discussion on this list about PDF and HTML links galvanised an > > earlier attempt of mine to implement hype

Format-agnostic hyperlinks

Hey folks, Recent discussion on this list about PDF and HTML links galvanised an earlier attempt of mine to implement hyperlinks in Troff in a device- and package-agnostic manner: It's still very much a W.I.P., but .[ "here's what I've done so far" ](

Re: Groff on Windows (for PDF output)?

Hi Blake, Try this , if you haven't already. Make sure you have GhostScript installed too. On Thu, 23 Jul 2020 at 07:12, Blake McBride wrote: > Greetings, > > I am trying to get Groff working on Windows. I have looked at MinGW, > GnuWin32,

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

e: > On Tue, 30 Jun 2020 03:08:04 +1000 > "G. Branden Robinson" wrote: > > > At 2020-06-14T14:40:44+1000, John Gardner wrote: > > > Why are we using Info, again? Was it because of GNU policy? > > > > Yes. https://www.gnu.org/prep/standards/stan

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

> I never saw the point of groff_diff(7). It's an excellent summary of how groff differs to classical troff, highlights potential portability issues (a.k.a., "groff-isms"), and also documents known incompatibilities with legacy syntax. If maintaining groff_diff(7) alongside another document with

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

, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-06-14T14:40:44+1000, John Gardner wrote: > > Why are we using Info, again? Was it because of GNU policy? > > Yes. https://www.gnu.org/prep/standards/standards.html#GNU-Manuals > > Aside from the

<    1   2   3   4   >