Re: spaces in file names and before comments

On Mon Feb 24, 2025 at 3:52 AM CET, G. Branden Robinson wrote: > At 2025-02-24T03:36:28+0100, onf wrote: > > On Mon Feb 24, 2025 at 2:36 AM CET, G. Branden Robinson wrote: > > > [...] > > > My lodestar on this point is that we can use C and the shell to create >

Re: spaces in file names and before comments

ompatibility (and making adding comments to these requests annoying) for the sake of supporting them isn't worth it. ~ onf

Re: double quotes in file names: another groff 1.24.0 caveaty

kip_line(); > } > > [...] > Any objections to this being in my next push? Not really. ~ onf

Re: double quotes in file names: another groff 1.24.0 caveat

On Sun Feb 23, 2025 at 11:38 PM CET, G. Branden Robinson wrote: > At 2025-02-23T21:21:37+0100, onf wrote: > > For all the other requests which use filenames (hpf, hpfa, lf -- am I > > mistaken, or did we forget about lf? --, nx, so), it treats spaces as > > an argument separa

Re: double quotes in file names: another groff 1.24.0 caveat

On Sun Feb 23, 2025 at 1:50 PM CET, Dave Kemper wrote: > On Sat, Feb 22, 2025 at 7:29 PM onf wrote: > > I won't mind too much if this change ends up in groff as it's > > currently being proposed. I would just find it unfortunate, because > > I am pretty sur

Re: how to prevent wrapping between "--" and "longoption" for html output?

s like you want to get a regular hyphen in the output, not a minus or dash. That has a very simple solution: use an actual hyphen (-) instead of the special character \-, which means minus. ~ onf

Re: line width and table width

ion is to wait until someone fixes the bug in ms you just discovered. A quick fix is to re-define the TS and TE macros to do nothing, i.e. .ds TS .ds TE ~ onf

Re: spaces in file names and before comments

By the way, On Sun Feb 23, 2025 at 12:53 AM CET, G. Branden Robinson wrote: > At 2025-02-22T23:23:35+0100, onf wrote: > > If that's an accurate characterization, then please explain what that > > NEWS file is about, because I don't get it. > > Again your reference

Re: double quotes in file names: another groff 1.24.0 caveat

Hi Dave, On Sun Feb 23, 2025 at 12:59 AM CET, Dave Kemper wrote: > On Sat, Feb 22, 2025 at 4:24 PM onf wrote: > > The combination of points 1, 5, and 5b seems to imply that > > .nx nx \" load file nx > > > > will be interpretted as loading file 'nx &#

Re: spaces in file names and before comments

This change, as it stands, is unlikely to be picked up by neatroff 2a. because it breaks backwards compat with older versions of neatroff 2b. because it would necessitate ugly changes to the code 3. Given the above, that the price for simplifying groff's grammar is decreased interoperability. That's all I was trying to say, thanks. ~ onf

Re: double quotes in file names: another groff 1.24.0 caveat

Hi Branden, [re-arranging] On Sat Feb 22, 2025 at 9:37 PM CET, G. Branden Robinson wrote: > At 2025-02-22T16:38:00+0100, onf wrote: > [...] > > I feel like changing ab, hpf, hpfa, nx, so, and tm (the others aren't > > implemented by neatroff) to allow spaces in the middle

Re: double quotes in file names: another groff 1.24.0 caveat

On Sat Feb 22, 2025 at 4:46 AM CET, onf wrote: > On Sat Feb 22, 2025 at 2:06 AM CET, G. Branden Robinson wrote: > > if I follow through on Savannah #66625, > > I mean to preserve traditional AT&T troff behavior of `tm` and `ab` in > > compatibility mode, mainly because I

Re: double quotes in file names: another groff 1.24.0 caveat

On Sat Feb 22, 2025 at 2:06 AM CET, G. Branden Robinson wrote: > At 2025-02-22T01:31:28+0100, onf wrote: > > On Sat Feb 22, 2025 at 12:12 AM CET, G. Branden Robinson wrote: > > > At 2025-02-21T15:22:02+0100, onf wrote: > > > [...] > > > > Ideally, `so` woul

Re: double quotes in file names: another groff 1.24.0 caveat

On Sat Feb 22, 2025 at 12:12 AM CET, G. Branden Robinson wrote: > At 2025-02-21T15:22:02+0100, onf wrote: > [...] > > Ideally, `so` would behave like `tm` except it would trim spaces > > at the end, but I understand that this would be adding yet another > > special cas

Re: Interpolation and formatting

On Sat Feb 22, 2025 at 12:21 AM CET, G. Branden Robinson wrote: > At 2025-02-22T00:11:13+0100, onf wrote: > > By the way, Heirloom troff has floating point registers. > > Just converting the type backing groff's registers from `int` to `long` > is a significant refactor

Re: double quotes in file names: another groff 1.24.0 caveat

On Fri Feb 21, 2025 at 3:22 PM CET, onf wrote: > Ideally, `so` would behave like `tm` except it would trim spaces > at the end, but I understand that this would be adding yet another > special case. > > Honestly, I never liked the fact `ds` doesn't trim trailing spaces. >

Re: Interpolation and formatting

f arithmetic > in the groff language. (Our Texinfo manual covers the same material.) > Among other things, it notes that division truncates rather than > rounding. > [...] By the way, Heirloom troff has floating point registers. ~ onf

Exclamation mark doesn't work as a tag name

ping tag containing whitespace: Tg \e! ERROR: skipping tag containing whitespace: Tg \&! Given that .Tg . succeeds in creating a tag named '.', I consider this behavior a bug. Thanks, onf

Re: double quotes in file names: another groff 1.24.0 caveat

On Fri Feb 21, 2025 at 3:14 PM CET, onf wrote: > Well, I have thought about it a bit since yesterday and I think making > `so` similar to `tm` would be a better idea: > $ 9 nroff << EOF > .tm Lorem ipsum dolor \" print to stderr > EOF > Lorem ipsum dolor S

Re: double quotes in file names: another groff 1.24.0 caveat

On Fri Feb 21, 2025 at 4:39 AM CET, G. Branden Robinson wrote: > At 2025-02-21T04:30:57+0100, onf wrote: > [...] > > Is my understanding correct that this change affects compatibility > > mode too, > > Yes. > > > thus lessening compatibility with DWB troff? >

Re: double quotes in file names: another groff 1.24.0 caveat

r Heirloom Doctools > troff, DWB 3.3 troff, or Solaris 10 troff. ...or neatroff. Is my understanding correct that this change affects compatibility mode too, thus lessening compatibility with DWB troff? ~ onf

Re: idea for groff

On Thu Feb 20, 2025 at 5:59 PM CET, Douglas McIlroy wrote: > The idea that the argument of .so might contain unquoted spaces is > anathema--contrary to groff convention and fortunately not supported. As far as I know, .so currently doesn't support spaces even when quoted. ~ onf

Re: Idea for groff

c expansion (as described in the section on “Expansions”). ~ onf

Re: how to prevent wrapping between "--" and "longoption" for html output?

Hi Benno, On Mon Feb 17, 2025 at 12:17 PM CET, Benno Schulenberg wrote: > Op 16-02-2025 om 16:55 schreef onf: > > Sounds like "modern" web browsers just break lines poorly. I have > > replicated what you are describing in Firefox 128.7.0esr. > > I've checked th

Re: [PATCH v1] CONTRIBUTING.d/style/c: Add coding style for the example programs

Hi Branden, On Sun Feb 16, 2025 at 4:19 AM CET, G. Branden Robinson wrote: > At 2025-02-09T03:48:33+0100, onf wrote: > > On Sun Feb 9, 2025 at 3:20 AM CET, onf wrote: > > > [...] > > > TL;DR: > > > With the default settings, a tab essentially trans

Re: [off-topic] game theory and macroeconomics

On Sun Feb 16, 2025 at 5:18 PM CET, G. Branden Robinson wrote: > At 2025-02-16T16:46:44+0100, onf wrote: > > > Surely this oversight has nothing to do with the ownership of most > > > consumer debt [] by those occupying the commanding heights of our > > > economi

Re: [off-topic] game theory and macroeconomics

On Sun Feb 16, 2025 at 5:18 PM CET, G. Branden Robinson wrote: > At 2025-02-16T16:46:44+0100, onf wrote: > > > Surely this oversight has nothing to do with the ownership of most > > > consumer debt [] by those occupying the commanding heights of our > > > economi

Re: [off-topic] game theory and macroeconomics

On Sun Feb 16, 2025 at 4:46 PM CET, onf wrote: > I heard that they eventually modified the game by introducing the > possibility that, from time to time (at random), your collaboration > appears to the other player as defection (and vice versa) to model > real world misunderstanding

Re: how to prevent wrapping between "--" and "longoption" for html output?

, --view Just view the file and disallow editing: read-only mode. This mode allows the user to open also other files for viewing, unless --restricted is given too. In short, I would consider this to be a bug in the respective browsers. ~ onf

Re: [off-topic] game theory and macroeconomics

On Sun Feb 16, 2025 at 4:51 AM CET, G. Branden Robinson wrote: > At 2025-02-16T04:37:46+0100, onf wrote: > > > https://www.youtube.com/watch?v=BOvAbjfJ0x0 > > > > Take note that (IIRC) the conclusion of research surrounding the > > Prisoner's Dilemma ha

Re: Proposed: Rename "scaled points" + Rationale behind "scaled points"

Hi Branden, On Sun Feb 16, 2025 at 5:22 AM CET, G. Branden Robinson wrote: > At 2025-02-10T18:23:14+0100, onf wrote: > > Speaking of ignoring scale indicators, I wonder why `cs` still > > ignores them in groff? > > I think for the same reason that they're ignored in

Re: [PATCH] Correct quotes in pic(1) manpage

On Sun Feb 16, 2025 at 4:25 AM CET, G. Branden Robinson wrote: > At 2025-02-16T04:19:20+0100, onf wrote: > > On Sun Feb 16, 2025 at 4:01 AM CET, G. Branden Robinson wrote: > > > With the quotation marks, it seemed to lie toward the "mind-reading" > >

Re: [PATCH] Correct quotes in pic(1) manpage

Hi Branden, On Sun Feb 16, 2025 at 4:01 AM CET, G. Branden Robinson wrote: > At 2025-02-16T03:50:30+0100, onf wrote: > > Seems like you are assuming bad faith where there is none. I was not > > trying to characterize your train of thought. > > With the quotation marks, it see

Re: [PATCH] Correct quotes in pic(1) manpage

On Sun Feb 16, 2025 at 3:17 AM CET, G. Branden Robinson wrote: > At 2025-02-16T02:44:12+0100, onf wrote: > > Seems like you found yourself in a familiar situation: > > "This under-documented code seems stupid. Was the person who wrote it > > really that stupid,

Re: [PATCH] Correct quotes in pic(1) manpage

On Sun Feb 16, 2025 at 3:50 AM CET, onf wrote: > > [The GNU pic(1) page unfortunately is one of our "diff" pages (like eqn(1)) > > [...] > > [...] > Then there is also eqn(1): I can't read...

Re: [PATCH] Correct quotes in pic(1) manpage

m I missing something?" Experience has taught me to approach seemingly non-sensical code with caution. ~ onf

Re: Proposed: Rename "scaled points" + Rationale behind "scaled points"

ators, I wonder why `cs` still ignores them in groff? Seems similar to `ps`... ~ onf

Re: Proposed: Rename "scaled points" + Rationale behind "scaled points"

EOF 10 4 720 10 4 In that case, the behavior described above seems unique to neatroff, which does support units in ps argument, but doesn't (yet) support fractional font sizes. ~ onf

Re: Proposed: Rename "scaled points"

s to an integer > > Surprise: in a font description file "scalesize" is called "sizescale". > [...] Huh? $ groff -v GNU groff version 1.23.0 [...] $ man 7 groff_diff | grep scalesize | wc -l 0 ~ onf

Re: Proposed: Rename "scaled points" + Rationale behind "scaled points" (was: Proposed: Rename "scaled points")

Hi Branden, On Sun Feb 9, 2025 at 3:28 PM CET, G. Branden Robinson wrote: > At 2025-02-07T16:20:23+0100, onf wrote: > > I've been wondering lately about the rationale behind solving the > > problem of font sizes being integer-only by adding scaled points. > > It'

Re: mdoc style

Hello Ingo, thank you for your detailed response. On Sun Feb 9, 2025 at 7:38 PM CET, Ingo Schwarze wrote: > onf wrote on Sat, Feb 08, 2025 at 01:35:31AM +0100: > [...] > > 1. Escape sequences in the sense of inline commands, i.e. how to mark > > up syntax like \f[font]? Do

Re: Report a Plan9 bug

e only maintained version of Plan9 is 9front. http://lists.9front.org/ You might be able to get some direct contact info by cloning git://git.9front.org/plan9front/plan9front and running git blame on /sys/src/libc/fmt/seprint.c [1] Good luck. ~ onf [1] I assume you meant seprint, not seprintf, which seems non-existent.

Re: [PATCH v1] CONTRIBUTING.d/style/c: Add coding style for the example programs

On Sun Feb 9, 2025 at 3:20 AM CET, onf wrote: > [...] > TL;DR: > With the default settings, a tab essentially translates into a > horizontal motion. [...] > This is because tab stops are related to the beginning of a paragraph > rather than the beginning of an output line a

Re: [PATCH v1] CONTRIBUTING.d/style/c: Add coding style for the example programs

= 2; } re‐ turn 0; } This is because tab stops are related to the beginning of a paragraph rather than the beginning of an output line as one would expect. The desired behavior can be enabled with the request .linetabs, but this is groff-specific and not supported by other troffs. ~ onf

Re: Floating vertical displacement for titles

Hi Walter, On Sat Feb 8, 2025 at 12:40 PM CET, Walter Alejandro Iglesias wrote: > On Fri, Feb 07, 2025 at 08:33:20PM +0100, onf wrote: > [...] > > Your approach seems unnecessarily complicated. Unless I am missing > > something, what you are trying to do with > > \v

mdoc style (was man(7), the hyperlink tagging challenge, and what's a node?)

Hello Ingo, On Fri Jan 24, 2025 at 7:51 PM CET, Ingo Schwarze wrote: > onf wrote on Fri, Jan 24, 2025 at 12:59:03PM +0100: > > On Fri Jan 24, 2025 at 4:15 AM CET, Alexis wrote: > > >> (My first port was of the documentation for the s6 package, and > >> unfortunately

Re: Floating vertical displacement for titles

-- > > How can I achieve that trick (or alike) from the macro? (Thus avoid > having to add the label to each title in the document.) Your approach seems unnecessarily complicated. Unless I am missing something, what you are trying to do with \v'\\n[.v]u/5u' can be achieved via .sp 0.2v or its equivalent .sp 0.2 ~ onf

Rationale behind sizescale / scaled points

much more straightforward solution, which wouldn't require new units or a new DESC entry. Am I missing something? Thanks, ~onf

Re: a multilingual hyphenation challenge

On Wed Feb 5, 2025 at 12:56 AM CET, onf wrote: [...] > I thus intuitivelly expected environments to save all formatting-related > properties. s/\./, including hyphenation settings./

Re: a multilingual hyphenation challenge

On Tue Feb 4, 2025 at 10:13 PM CET, Dave Kemper wrote: > On Tue, Feb 4, 2025 at 1:54 PM onf wrote: > > In other words, hyphenation language setting is not local to the > > environment... which seems like a really unintuitive behavior, > > Being one of the disqualifieds from t

Re: a multilingual hyphenation challenge

e is spent in one long effort to escape the commonplaces of existence. These little problems help me to do so. EOF My life is spent in one long effort to escape the commonplaces of existence. These little problems help me to do so. ~ onf

Re: a multilingual hyphenation challenge

is to explain why the > word "commonplaces" hyphenates in the second exhibit but not the first. [...] Let nroff explain it: $ nroff -ww << EOF .tm \n[.hla] .ev epigram .hla fr .tm \n[.hla] .ev .tm \n[.hla] EOF en fr fr In other words, hyphenation language setting is not local to the environment... which seems like a really unintuitive behavior, by the way. I hope there are plans to change this? ~ onf

Re: Some requests for refer(1) and "-me" macro package

On Wed Jan 29, 2025 at 10:22 PM CET, G. Branden Robinson wrote: > At 2025-01-29T16:56:25+0100, onf wrote: > > On Wed Jan 29, 2025 at 9:27 AM CET, G. Branden Robinson wrote: > > > I forgot to mention that the quoted presentation corresponds to the > > > `cflags` re

Re: Help with diversions to handle widows (or orphans?) ;-)

On Wed Jan 29, 2025 at 7:36 PM CET, Walter Alejandro Iglesias wrote: > On Tue, Jan 28, 2025 at 10:40:36PM +0100, onf wrote: > > On Tue Jan 28, 2025 at 9:02 PM CET, Walter Alejandro Iglesias wrote: > > > [...] After a week of > > > struggling, I got the code below, it&#x

Re: Some requests for refer(1) and "-me" macro package

On Wed Jan 29, 2025 at 9:27 AM CET, G. Branden Robinson wrote: > At 2025-01-28T18:40:15-0600, G. Branden Robinson wrote: > > At 2025-01-28T18:35:25-0600, Dave Kemper wrote: > > > On Tue, Jan 21, 2025 at 8:11 AM onf wrote: > > > > I think groff would benefit

Re: Help with diversions to handle widows (or orphans?) ;-)

ny reason (besides implementation difficulty) this hasn't been added as a function to the formatter itself? ~ onf

Re: Help with diversions to handle widows (or orphans?) ;-)

27;t tell the truth and problems will appear. :-) > > I'd appreciate if anyone could give me some clues on how to get a more > solid solution or a better approach. > [...] You might find the following useful: https://lists.gnu.org/r/groff/2003-01/msg00024.html ~ onf

Re: man(7), the hyperlink tagging challenge, and what's a node?

backdoor code. The trace I was analyzing indeed shows that during a pubkey login the exploit code is invoked [...] TL;DR: OpenSSH does not depend on xz in any way, but a patched version distributed by Debian et al. makes it an indirect run dependency, which enables the exploit. Also, the exploit is injected into the binary only when building Debian or RPM packages. ~ onf

Re: man(7), the hyperlink tagging challenge, and what's a node?

oc's mdoc(7) would be appreciated! Thanks, ~onf

Re: man(7), the hyperlink tagging challenge, and what's a node?

a random collection of a few ports i have currently installed: > arara(1), bib2gls(1), bzless(1), python3.12.1(1), practically all > FFmpeg manuals, [...] The ffmpeg manuals are generated from Texinfo via texi2pod and pod2man, by the way. ~ onf

Re: man(7), the hyperlink tagging challenge, and what's a node? (was: ripgrep author seems happy with groff_man_style(7))

misperceptions might arise. > > And in this retitled thread I'll deal with the technical points. In > another thread, if I make time for it, I'll respond to your and onf's > rebuttals to my historical narrative. I think onf in particular assumes > that I'

Re: ripgrep author seems happy with groff_man_style(7)

Hi, On Wed Jan 22, 2025 at 8:36 PM CET, Ingo Schwarze wrote: > onf wrote on Mon, Jan 20, 2025 at 11:13:57PM +0100: > > On Mon Jan 20, 2025 at 10:22 PM CET, Ingo Schwarze wrote: > >> [...] > >> Since this point keeps getting discussed, i'll briefly mention &g

Re: Putting UTF-8 in grout (was: ripgrep author seems happy with groff_man_style(7))

On Wed Jan 22, 2025 at 12:14 AM CET, onf wrote: > On Tue Jan 21, 2025 at 11:39 PM CET, G. Branden Robinson wrote: > > At 2025-01-21T22:31:44+0100, onf wrote: > [...] > > > Given how difficult adding full Unicode support to groff, and > > > contributing to the format

Re: Putting UTF-8 in grout (was: ripgrep author seems happy with groff_man_style(7))

On Tue Jan 21, 2025 at 11:39 PM CET, G. Branden Robinson wrote: > At 2025-01-21T22:31:44+0100, onf wrote: > > On Tue Jan 21, 2025 at 8:29 PM CET, G. Branden Robinson wrote: > > > Yeah, but I won't have to go sticking my hand into unfamiliar places > > > in the f

Re: Putting UTF-8 in grout (was: ripgrep author seems happy with groff_man_style(7))

On Tue Jan 21, 2025 at 8:29 PM CET, G. Branden Robinson wrote: > [...] [rearranging] > > Given onf and Peter were generally supportive of seeing UTF-8 in > > grout, and your defence of it was described as "making it perfect for > > most people would make it horrible for

Re: ripgrep author seems happy with groff_man_style(7)

Hi, On Tue Jan 21, 2025 at 8:19 PM CET, G. Branden Robinson wrote: > At 2025-01-21T16:05:18+0100, onf wrote: > [...] > > Don't get me wrong, it's nice that one can link to a specific > > (sub)section of an HTML manpage, but that's completely missing the > &

Re: Unconventional *roff practices

sn't try to abstract stuff away and does things in the simplest way possible. This means you have to support elaborate typesetting demands yourself, but also that it's much easier to understand and debug. ~ onf

Re: ripgrep author seems happy with groff_man_style(7)

Hi Branden, On Tue Jan 21, 2025 at 6:59 AM CET, G. Branden Robinson wrote: > At 2025-01-20T01:48:19+0100, onf wrote: > > Actually, BSD mandoc does implement this, it's just documented at > > a poorly visible place in the docs. BSD mandoc's man(1): > > MANPAGER &

Re: Some requests for refer(1) and "-me" macro package

haracters after which words may be broken (even when hyphenation is disabled) without inserting hyphens. That allows one to specify / as a potential breaking point to the formatter. ~ onf [1] https://github.com/n-t-roff/heirloom-doctools

Re: ripgrep author seems happy with groff_man_style(7)

rve as an abstraction over a language deemed too complicated or unwieldy. See markdown, which was originally designed to simplify writing stuff on the web[1] and its original spec even allows embedding HTML tags into it, or scdoc, which is something like markdown for man. ~ onf [1] The way in which static site generators like hugo use it is likely what it was intended for.

Fwd: Re: ripgrep author seems happy with groff_man_style(7)

It seems the mailing list doesn't like my message for some reason. Let me try again for the 3rd time... Forwarded message from onf on Mon Jan 20, 2025 at 2:27 PM: Hello Ingo, On Mon Jan 20, 2025 at 3:27 AM CET, Ingo Schwarze wrote: > onf wrote on Mon, Jan 20, 2025 at 01:48:19AM +0100

Re: ripgrep author seems happy with groff_man_style(7)

On Mon Nov 4, 2024 at 4:03 PM CET, onf wrote: > On Mon Nov 4, 2024 at 1:45 AM CET, Alexis wrote: > > "onf" writes: > > > While you can absolutely get a list of manpages containing a > > > specific term of a specific type with apropos (like the example >

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

On Sun Jan 19, 2025 at 5:38 PM CET, onf wrote: > On Sun Jan 19, 2025 at 3:04 PM CET, Ihor Radchenko wrote: > > "onf" writes: > > >> I am wondering if the situations like the above should be caught by > > >> groff linter. Currently, t

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

On Sun Jan 19, 2025 at 3:04 PM CET, Ihor Radchenko wrote: > "onf" writes: > >> I am wondering if the situations like the above should be caught by > >> groff linter. Currently, they seem not. > > > > They actually are: > > ... > > troff:

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

On Sun Jan 19, 2025 at 8:43 AM CET, Ihor Radchenko wrote: > "G. Branden Robinson" writes: > >> What about \fC\f[CR]Lorem\fP\fP? > > > > Unreliable. As onf pointed out, not only is the font selection not > > backed up by a stack, but it the identity of &qu

Re: About how centering affects horizontal movements

exact commands as well. > More late, this useful explanaition from Werner Lemberg (thank you > both!) > > https://lists.nongnu.org/archive/html/bug-groff/2010-01/msg4.html > [...] > So, adapting Werner Lemberg's reasoning to my case: > [...] > Then I applied that reasoning to my adaptation of Tadziu's hack: > > .ds 90 \R'w \w'\\$*''\ > \v'\\nwu-\\n[.v]u'\ > \h'(\\n[rst]u+\\n[rsb]u)/2u'\ > \X'ps: exec gsave currentpoint 2 copy translate \ > -90 rotate neg exch neg exch translate'\ > \Z'\\$*'\ > \X'ps: exec grestore' > > But that works as expected only if you use \Z: > [...] > Or, if instead of using '.ad c' or '.ce' you center your text manually > in the page: > [...] > You can also center perfectly your text with .ce and without \Z by > removing the division by two from the \h move (third line). > > [...] > \h'\\n[rst]u+\\n[rsb]u'\ > [...] > > All that solutions work but I'm still not able to decide which is the > consistent one. :-) I would expect the last one to be the one, but note that I know very little PostScript and I don't have the time to study the outlined solutions. When I tried using these PostScript commands before, they didn't seem very intuitive, so personally in your use case I would probably generate the text to be rotated as a separate PDF and then rotating it and either overlaying it over or adding it to the main PDF with some PDF manipulation software instead of trying to solve it entirely in troff. > Thank you again onf! I'm glad it helped. ~ onf

Re: About how centering affects horizontal movements

On Sat Jan 18, 2025 at 8:09 PM CET, onf wrote: > [...] > > \Z'123456789' > > .rj > > 123456789 > > $ groff -Tutf8 | sed "s/ /'/g" > '''''''''''''''''&#x

Re: About how centering affects horizontal movements

ally being centered, eh? $ groff -Tutf8 << EOF | sed -E "s/ /'/g" .ll 20 .pl 1 .nf .rj \h'4n'OneTwo EOF ''''''''''''''OneTwo Right, it's being right-justified, presumably as a side effect of the way groff handles centering. TL;DR: When centering, horizontal motions become part of the line and centered with it. When using \Z in centered lines, the text actually becomes right justified. > [...] > Also, given what the documentation explains about \Z, I don't understand > the effect it has in this example either. (If any part of the manual can > help me understand this behavior, there's no need to waste your time > explaining it, just point it out to me.) I doubt the behavior of \Z shown above is intended. ~ onf

Why does \p schedule a break?

Hi all, does anyone know the rationale behind the \p escape scheduling a line break at the next word boundary instead of breaking the line right away? Thanks, ~onf

Re: Differences in `ne` and `bp` line-breaking behavior

On Thu Dec 5, 2024 at 3:47 PM CET, onf wrote: > On Thu Dec 5, 2024 at 3:57 AM CET, G. Branden Robinson wrote: > > At 2024-12-04T14:46:00-0500, Peter Schaffter wrote: > > > How about > > > > > > .ne d Spring the next vertical postion trap if it is nearer th

Re: [demo] Decoupling alignment from adjustment

On Fri Jan 10, 2025 at 7:41 PM CET, onf wrote: > I've been playing a bit with neatroff lately, and tried separating > alignment from adjustment that we've discussed here before. I am > attaching the (mostly complete) patch below.[1] > > It adds new request .al (align) wit

[demo] Decoupling alignment from adjustment

but am not sure if it's worth the breaking change. To test it: git clone https://github.com/aligrudi/neatroff_make cd neatroff_make make init cd neatroff git apply path/to/patch cd .. make neat neatroff/roff -F. INPUT.tr | neatpost/pdf -F. -pa4 > OUTPUT.pdf ~ onf [1] If

Re: duffman(1) (was: diffman(1))

Hi Alex, On Fri Jan 10, 2025 at 10:17 AM CET, Alejandro Colomar wrote: > On Fri, Jan 10, 2025 at 05:30:59AM +0100, onf wrote: > > On Thu Jan 9, 2025 at 2:59 PM CET, Alejandro Colomar wrote: > > > I have added a duffman(1) program (script) to the Linux man-pages repo. >

Re: duffman(1) (was: diffman(1))

pub/scm/docs/man-pages/man-pages.git/tree/scripts or here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/src/bin ~ onf

Re: SY $3

On Thu Jan 9, 2025 at 11:02 PM CET, Alejandro Colomar wrote: > Hmmm, I personally use this style when programming. I use tabs in code, > but in function prototypes, I use 4 spaces for line continuation. I > find it more readable in source code. >

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

Hi Branden, On Sat Jan 4, 2025 at 7:37 AM CET, G. Branden Robinson wrote: > At 2025-01-04T01:23:02+0100, onf wrote: > [...] > > Speaking of the left italic correction (\,), could you please give me > > some example(s) where it's actually useful? I have yet to see a singl

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

Hi Branden, On Fri Jan 3, 2025 at 9:38 AM CET, G. Branden Robinson wrote: > At 2025-01-02T15:29:59+0100, onf wrote: > > I don't know why it took me so long, but I think what you're looking > > for is this: > > \fC\f(CRLorem\fR > > Not a bad idea, but while

Re: [BUG] ox-man: Nested markup is broken (was: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)])

On Thu Jan 2, 2025 at 6:47 PM CET, Ihor Radchenko wrote: > "onf" writes: > [...] > > It's important to understand that troff commands don't really use > > nesting or a stack as one might be used to from HTML and similar > > markup languages. That's

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

Hi Ihor, On Wed Jan 1, 2025 at 1:30 PM CET, onf wrote: > On Wed Jan 1, 2025 at 10:38 AM CET, Ihor Radchenko wrote: > > >> Also, what if we leave \fC and add \f[CR]/.EX on top? > > >> AFAIU, the worst case scenario for \fC is that it does nothing. By > > >&g

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

acing and sometimes ignored? > > Yes. A blank line is ignored when the formatter's "no-space mode" is > enabled. > > [...] Just to clarify, .sp is ignored in such cases as well. ~ onf

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

add blank after blocks (or displays) of code. Extra > vertical space after seems to be reasonable. They are equivalent as far as troff formatters are concerned. The question is whether they are equivalent to the various other programs that attempt to interpret man source code directly. So I guess this depends on whether you're targetting only troff (+ BSD mandoc) or not. Branden will likely tell you more about this topic. ~ onf

Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

t blank line is sometimes interpreted as > vertical spacing and sometimes ignored? A blank input line is equivalent to .sp unless the .blm request was called to change this behavior. .blm is groff's invention (see groff_diff(7)). ~ onf

[PATCH groff] Allow manually disabling building the Texinfo manual

add option --disable-info-doc to ./configure which disables building the Texinfo manual as if makeinfo was missing except that no warnings are emitted --- As discussed in https://savannah.gnu.org/bugs/index.php?66583#comment15 configure.ac | 6 +- doc/doc.am | 2 +- m4/groff.m4 | 10

Re: Proposed: QS/QE macros for quotation in man(7)

> > that \[Bq] and \[rq] would achieve the same effect as the > > IBM Courier example. > > Attached is a PDF showing the differences. If you zoom > in, you can see that the \[lq] in IBM Courier, which is > bottom-heavy (like the \[lq] in Times), is not the same > as \[rq] in Adobe Courier, which is top-heavy. I get that, but by using \[lq] and \[rq] you end up with a top-heavy right quote anyway, so how does that make a difference? ~ onf

Re: On code quality, C, and C++ (was: Proposed: QS/QE macros for quotation in man(7))

On Fri Dec 20, 2024 at 10:54 PM CET, onf wrote: > Let's say I want to check out the need method of curdiv. > To do that, I first need to figure out what object it is. > Searching for curdiv eventually reveals it being declared > in div.cpp as type `diversion`. Searching for diver

Re: UTF-8 in grout and a performance regression (was: synchronous and asynchronous grout)

Hi Branden, On Fri Dec 20, 2024 at 7:45 PM CET, G. Branden Robinson wrote: > At 2024-12-20T14:15:43+0100, onf wrote: > > On Fri Dec 20, 2024 at 3:45 AM CET, G. Branden Robinson wrote: > > > Yes. I think we could do more to encourage people to understand the > > > avail

Re: On code quality, C, and C++ (was: Proposed: QS/QE macros for quotation in man(7))

Hi Branden, On Fri Dec 20, 2024 at 7:13 PM CET, G. Branden Robinson wrote: > At 2024-12-20T13:59:13+0100, onf wrote: > > [...] > > I kinda get where they are coming from with C++, though. Last time I > > tried patching groff, I was fascinated by the stark difference be

Re: Proposed: QS/QE macros for quotation in man(7)

al about \[lq] as right German quote is its spacing. Any advice on how to fix that? By the way, I don't understand how you arrived at the conclusion that \[lq] and \[rq] are preferrable to \[Bq] and \[lq] in Adobe Courier; from the image it seems to me that \[Bq] and \[rq] would achieve the same effect as the IBM Courier example. ~ onf

Re: Proposed: QS/QE macros for quotation in man(7)

ed in English, not German. > Therefore, the quote characters can be fixed in the manual > page source itself (which is different for each language) > and thus do not require customization. I should have worded it better. What I meant was locale of the document as set e.g. by `.mso den.tmac`. I completely agree that this should be in line with the language in which the document is written. ~ onf

Re: UTF-8 in grout and a performance regression (was: synchronous and asynchronous grout)

Hi Branden, On Fri Dec 20, 2024 at 3:45 AM CET, G. Branden Robinson wrote: > At 2024-12-19T22:48:41+0100, onf wrote: > > > The number of people who read GNU troff output ("grout"), whether > > > with their eyeballs or with a program they've written, is *t

  1   2   >