Re: [Groff] Different font in first line of paragraph

Hello, pet...@schwertfisch.de (Dirk-Wilhelm Peters) wrote: |is there a robust way to switch to a different font after the first |line of a paragraph is adjusted? The example below comes close, |but the first word of the second line of the paragraph is already |typeset in the previous font. li

[Groff] X in \A'X' isn't ignored - bug report?

Hello, while trying to improve performance of mdocmx(7) on groff(1) (without .hash request) further i'm now diversifying further via .length+.substring (instead of only .length). I am using \A'' so that i can ensure the generated name can actually be used. The (circumvented) problem is that, e.g.

Re: [Groff] X in \A'X' isn't ignored - bug report?

Hello! Werner LEMBERG wrote: |> :5: missing `]' |> :5: invalid component `a' in composite glyph name | |Well, the parsing for `\[...]' happens before feeding the data to |\A'...', IIRC. | |> Is this a general parser problem, i haven't looked yet.. | |I wouldn't call it a `general par

Re: [Groff] X in \A'X' isn't ignored - bug report?

Werner LEMBERG wrote: |> Well exactly that was however the initial problem: while testing the |> manual of the MUA i maintain i got three occurrences of similar |> errors for \A'' on the result of a ".substring 0 1". | |Ouch :-) Not having an `interned' representation can be advantageous, |

[Groff] mdocmx(7), III.: reference extension for the mdoc(7) semantic markup language

Hello, today i'm presenting "the first release" of mdocmx(7). Shall no comments arise i'll open a bug ticket with exactly the same content in the near future. It will also be included in my fork of GPLv2 groff, S-roff. (But that will take quite some time.) To reiterate what this thread [1,2] was

[Groff] Little oversight in hdtbl/examples/common.roff (i think)

Hello, i am finally finding time to truly sync my S-roff with the current GNU troff (a bit tricky due to copyright issues…) in order to be able to build and then act on it! Woo-hoo! Or something like that... ...And just in case you wonder... Now this: in the outsourced common hdtbl example cod

Re: [Groff] Little oversight in hdtbl/examples/common.roff (i think)

Hallo Werner, Werner LEMBERG wrote: |Sorry for the late reply. of course. Thanks for doing so much work on and maintaining GNU roff such a long time. |> Now this: in the outsourced common hdtbl example code i think i've |> found an oversight? Is the attached diff correct? | |I don't think

Re: [Groff] How remove title?

Anyway i finally have to say that it is a pity that, instead of (making the engine as such multi-pass and) instrumenting the macros for different output formats that need meta-information, and extending the macros sets to include more meta-information that may be usable in output devices, so many o

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

Werner LEMBERG wrote: |> Wouldn't it be useful to have the possibility of recursively |> searching the subdirectories of a directory in GROFF_TMAC_PATH, |> typically with the addition of a double-slash at the end of the |> concerned directory's name? (Cf. TeX's TEXINPUTS.) |> |> E.g., |> |

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

Werner LEMBERG wrote: |> And then think about the special path "//" which' behaviour is |> implementation defined as well according to POSIX. | |Do you actually know the kpathsea library? Without this library, TeX |file management would be a nightmare. And kpathsea works on all major |plat

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

Hello and good morning Ralph, Ralph Corderoy wrote: |> For other use cases i would have no problem with a single global |> .ini-style configuration file and a per-user one with the same syntax. | |Aside, I dislike Microsoft's INI files that have appeared in Unix. :-) |They're not line based

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

P.S.: i wrote: |Werner LEMBERG wrote: ||Do you actually know the kpathsea library? Without this library, TeX ||file management would be a nightmare. And kpathsea works on all major ||platforms and is very mature. My "all too hardwired and restricted, and then scattered at the same time" di

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

Colin Watson wrote: |Here's an updated patch for this issue. The difference relative to my Thanks for placing this under GPL2, like that it will find its way into S-roff, too! |More details on SOURCE_DATE_EPOCH (and there are many other useful |things on the same site): | | https://reprod

Re: [Groff] Does groff match my needs?

wrote: |Joh-Tob Schäg wrote (Wed, 11 Nov 2015 17:32:47 |+0100): |> i seached for an alternative to latex and found groff. Sadly i found |> no IRC or something where i could ask directly. |> But before i invest time in groff or some macro system, i wanted to |> know if it fits my needs. |>

Re: [Groff] Help locating financial reports generated by groff

"Gerard Lally" wrote: |On Sun, 13 Dec 2015 17:15:15 -, Deri James | wrote: |> On Sun 13 Dec 2015 11:31:58 Gerard Lally wrote: |>> Some time ago I came across some financial or business reports which, if |>> my memory isn't deceiving me, were generated by groff. I vaguely recall |All I

Re: [Groff] text variants

Dave Kemper wrote: |On 11/23/15, Dave Kemper wrote: |> groff_char does seem to address this issue regarding other glyphs. It |> says, "Entries marked with `***' denote glyphs for mathematical |I was finally going to do this but hit a snag: it turns out commit |07a6233adeb476611f7a286295935

Re: [Groff] text variants

Hello. Werner LEMBERG wrote: |> It seems more likely, though, that these markers were erroneously |> removed during the rather extensive changes introduced in this |> commit -- surely the point about the font metrics for these glyphs |> remains true. Bernd? | |Please restore the markers.

Re: [Groff] text variants

Werner LEMBERG wrote: |Please restore the markers. I think this should be it regarding ***. --steffen diff --git a/man/groff_char.man b/man/groff_char.man index f393578..edd3792 100644 --- a/man/groff_char.man +++ b/man/groff_char.man @@ -842,7 +842,7 @@ right angle bracket T} \[bv] \e[bv]

Re: [Groff] text variants

Werner LEMBERG wrote: |> I wonder what those "+" markers are for, they have been added in |> [48615a4]. | |Uh, oh, a lot of them are lost :-( As documented in the man page, they |indicate that the (two-letter) glyph name is documented in the |original troff manual. It seems i have searched

Re: [Groff] text variants

Hi. Dave Kemper wrote: |On 12/15/15, Steffen Nurpmeso wrote: |> I think the attached should do so. | |Thanks, Steffen! Once this is applied to git, I'll create a patch |with my originally suggested enhancement. The attached may do, then. (With some manual intervention.) (And r

Re: [Groff] horizontal trap

Tadziu Hoffmann wrote: |> A trap set just below the current output position could record |> the maximum .n seen on this page, moving the trap down each time. | |Indeed, trapping output instead of input would have the added |advantage that overlong lines could be detected even if the |text wa

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

Ralph Corderoy wrote: |> The project on github: https://github.com/cloutiy/tml |> Extensive documentation on its wiki: https://github.com/cloutiy/tml/wiki | |Interesting, and I'll look more when I've time. | |> Inline formatting has a nice clean syntax that resembles HTML, but |> much clean

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

Hi, Yves Cloutier wrote: |Thanks for your comment. It however wasn't real fun for i guess, but it is great that you don't mind. |Closing a inline formatting stack with a single closing bracket was a |design decision meant to reduce the noise added to running text. It's |meant to keep the r

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

"James K. Lowden" wrote: |On Sat, 16 Jan 2016 17:32:38 +0100 |Steffen Nurpmeso wrote: |> I think plain SGML is still an interesting language, much |> better than what XML made of it. | |As Dijkstra said of Algol, "an improvement over many of its |successors."

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

"James K. Lowden" wrote: |On Sat, 23 Jan 2016 12:17:35 -0500 |Larry Kollar wrote: |> IIRC, James Clark wrote the only open-source SGML parser around, and |> it didn?t support the full syntax. By contrast, there are XML parsers |> in just about every language out there including awk. | |AFA

Re: [Groff] pdfroff 1.22 calls groff 1.19 -help

Anton Shterenlikht wrote: |This is on FreeBSD 10.2-RELEASE-p9, |with base OS groff, /usr/bin/groff at 1.19.2, |and groff-1.22.2_3 istalled via packages |under /usr/local/bin. | |When I try to run pdfroff 1.22, it pulls |groff 1.19: | |$ /usr/local/bin/pdfroff --version |GNU pdfroff (grof

Re: [Groff] pdfroff 1.22 calls groff 1.19 -help

Anton Shterenlikht wrote: |>This script will prefer environment variables GROFF_BIN_DIR then |>GROFF_BIN_PATH (why is all that, btw.? ph!) falling back to |>PATH as a last option only. So doing |> |> $ ( GROFF_BIN_PATH=/usr/local/bin/; $GROFF_BIN_PATH/pdfroff ) |> |>should do it, no?

Re: [Groff] bad QE in -ms

Hi. Carsten Kunze wrote: |Can we agree to commit this? (The patch is also added as a .gz file.) | |diff --git a/tmac/s.tmac b/tmac/s.tmac |index cf0eca8..190ee11 100644 |--- a/tmac/s.tmac |+++ b/tmac/s.tmac |@@ -1298,6 +1298,10 @@ along with this program. If not, see

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

Steve Izma wrote: |On Wed, Mar 23, 2016 at 08:25:50PM -0400, Larry Kollar wrote: |> Subject: Re: [Groff] groff performance in respect to hardware platform |>> I'm wondering how CPU configurations affect groff processing |>> speed. |I guess I need to re-state the question. I'm quite familiar

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

Steve Izma wrote: |On Wed, Mar 23, 2016 at 11:21:37PM -0400, Steve Izma wrote: |> Subject: Re: [Groff] groff performance in respect to hardware platform |> |>> ... But I'm wondering if anyone can tell me if groff benefits |>> from running on multiple CPU cores and multiple CPUs. |>> I assum

Re: [Groff] psfig With groff

Hello, Henry McGilton wrote: |I’m trying to determine whether or not psfig can be used with groff. | |Pretty much all of the back and forth about groff is a decade old, and |doesn’t really answer the simple question of whether groff supports |psfig. | |I see that James Clark mentions that

Re: [Groff] grohtml missing in groff 1.22?

Anton Shterenlikht wrote: |On FreeBSD 11-current, with groff 1.22 installed | |rat> pkg info -xo groff |groff-1.22.2_4 textproc/groff |rat> pkg info -xl groff|grep groh |/usr/local/bin/post-grohtml |/usr/local/bin/pre-grohtml |/usr/local/man/man1/gro

Re: [Groff] grohtml missing in groff 1.22?

i wrote: |Anton Shterenlikht wrote: ||On FreeBSD 11-current, with groff 1.22 installed || ||rat> pkg info -xo groff ||groff-1.22.2_4 textproc/groff ||rat> pkg info -xl groff|grep groh ||/usr/local/bin/post-grohtml ||/usr/local/bin/pre-grohtml ||/usr

Re: [Groff] multi-line macro arguments

(Ted Harding) wrote: |> ?ukasz Stelmach wrote: |>> I am developing a macro to print envelopes. Is it possible to pass a |>> multi-line string (not necessarily defined with .ds) as a parameter |>> for a macro? |The basic idea is not to give a "multi-line string" as a single |paramater, but

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

"James K. Lowden" wrote: |On Fri, 29 Apr 2016 17:50:52 +0200 |Ingo Schwarze wrote: |Have you experimented with a single index for all man pages? I wonder |how useful that would be, or how it might be subdivided. An index that |spanned pages would be helpful for sets of routines covered by

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

Deri James wrote: |I've been using pdf versions of the man pages for a while now. They don't |suffer some of the problems mentioned in this thread. For example, in\ | the ksh |manual you can find the description of "read" with two mouse clicks. First |open the section "Built-in commands"

Re: [Groff] Permissible characters for hyphenation

i wrote: |Stephen Berman wrote: ||Does groff permit characters besides hyphen-minus (ASCII 45) and soft ||hyphen (octal 255) for displaying hyphenation in man pages? I'm asking | |I have been convinced that soft hyphen is a control character and …assuming you referred to U+00AD when you hav

Re: [Groff] Permissible characters for hyphenation

Oh! i wrote: |Stephen Berman wrote: ||Does groff permit characters besides hyphen-minus (ASCII 45) and soft ||hyphen (octal 255) for displaying hyphenation in man pages? I'm asking that finally made me think: Eli Zaretskii is so active on the Unicode list, why don't you use the Pd character

Re: [Groff] Permissible characters for hyphenation

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 only become |visible when surrounding text is broken. | |For instance, assume this

Re: [Groff] Permissible characters for hyphenation

John Gardner wrote: |On 30 May 2016 at 23:20, Steffen Nurpmeso wrote: |> John Gardner wrote: |>|> I have been convinced that soft hyphen is a control character and |>|> not something visual, |>| |>|Almost correct. |>| |>|Soft hyphens *do* describe potentia

Re: [Groff] How to find bugs in man pages?

Hello. Ingo Schwarze wrote: |Ralph Corderoy wrote on Sun, Jun 19, 2016 at 04:10:15PM +0100: |> Xose wrote: | |>> I'm using: groff -z -b -wall manpage.x |>> Is there anything better? | |> Not as far as I know. | |Inside groff, that is. |Several linters exist. You are too modest in my o

Re: [Groff] colorized man pages

"James K. Lowden" wrote: |http://boredzo.org/blog/archives/2016-08-15/colorized-man-pages-understood-a\ |nd-customized | |https://news.ycombinator.com/item?id=12296000 | |It's a little far afield, but some here might be interested in the |interest in manpages. mdoc has no color features, l

Re: [Groff] colorized man pages

walter harms wrote: |Am 19.08.2016 13:06, schrieb Steffen Nurpmeso: |> "James K. Lowden" wrote: |>|It's a little far afield, but some here might be interested in the |>|interest in manpages. mdoc has no color features, leaving folks to |>|resort to some pretty

Re: [Groff] colorized man pages

Clarke Echols wrote: |Just because you can doesn't mean you should. To me the problem is that i can't right now, even though i want. |With a world gone crazy over apps for this, apps for that, |and apps to manage apps (I'm guessing because I've never |owned a cell phone -- much less a smart

Re: [Groff] colorized man pages

John Gardner wrote: |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

Re: [Groff] colorized man pages

Tadziu Hoffmann wrote: |> Raw VT-100 escape sequences, in 2016. Where will it all end? | |Steering wheels. On cars. In 2016. Where will it all end? I hope not for joysticks, or maybe only for cars driven by women. Instead something more motorcyclish, where both hands can do something. |S

Re: [Groff] colorized man pages

Ingo Schwarze wrote: |Tadziu Hoffmann wrote on Tue, Aug 23, 2016 at 01:29:07AM +0200: .. |> And regarding the |> "ready-to-use solution" that has "long been available": |> for the most part, the semantic information is simply not |> encoded in the manpages. | |That is true for the Linux m

Re: [Groff] colorized man pages

Larry Kollar wrote: |> Steffen Nurpmeso wrote: |> |>|still working with a text terminal, I'd expect escape codes to |>|be your daily bread and butter, not something to scoff at. |>|(Unless I'm missing the good-natured, approving irony here?) .. |>|> I

Re: [Groff] colorized man pages

"James K. Lowden" wrote: |On Tue, 23 Aug 2016 01:29:07 +0200 |Tadziu Hoffmann wrote: .. |> Seriously: what's wrong with escape codes? I mean, if you're |> still working with a text terminal, I'd expect escape codes to |> be your daily bread and butter, not something to scoff at. |> (Unl

Re: [Groff] Possible bug in -doc

Ingo Schwarze wrote: |Carsten Kunze Heirloom wrote on Mon, Oct 03, 2016 at 12:31:02PM +0200: |> the problem in the document is the missing "-width" argument for .Bl. |> From groff_mdoc: |> |> If a width is not specified for the tag list |> type, every time ?.It? is invoked, an attempt ..

Re: [Groff] Possible bug in -doc

Hallo. Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Mon, Oct 10, 2016 at 01:41:43PM +0200: |> Having a definition list with some few first words in a different |> style, e.g., bold or emphasized, than directly following text in |> the same paragraph block, i.e., term and defin

Re: [Groff] speedata Publisher: XML to PDF.

Ralph Corderoy wrote: |I'm no fan of XML, but I thought this command-line PDF producer from an |XML file may be of interest. Has Lua somewhere under the covers. |https://speedata.github.io/publisher/index.html Pretty cool indeed, and from a glance it seems to be very clean. I really rather ha

Re: [Groff] Applying commands to all pages

"Brendan Caluneo" wrote: |So I decided to experiment a little with my own macro package. A problem |I am having right now is how to make commands, such as ".sp x" to set |the top margin, apply to all pages, not just the first one. I'm |completely lost and would appreciate any help with solv

Re: [Groff] Applying commands to all pages

Mike Bianchi wrote: |On Thu, Nov 10, 2016 at 04:35:34PM +0100, Steffen Nurpmeso wrote: |> ... Search |> the internet for cstr#54-troff-revised.pdf -- some members of this |> list have revised the original, and i think for the better. | |I cannot find anything searching for | cstr

Re: [Groff] Applying commands to all pages

Hello. Is there any particular reason this is getting private? I would prefer public lists since answers to your questions can very well be interesting for other readers of the ML. I really would like to forward this answer to the ML unless you speak against it. What is wrong with that? Say, co

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

wrote: |Werner LEMBERG wrote (Thu, 17 Nov 2016 09:02:52 +0100 |(CET)): ... |> Alas, Vienna is a bit too far away from Berlin... BTW, what do you |> mean with `left behind'? ... |Also: |markdown/ ReST -> HTML is superior to groff -> HTML. Surely this is not necessarily true. I would lov

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

John Gardner wrote: |> even though massive amount of *manpower* has been put in this ... | for Atom (a text editor |which is built using web technologies: HTML, CSS, JavaScript, etc). I Yes, i've looked at that after you mentioned it first.

Re: [Groff] overview of man(1) and groff(1) command line options

Ingo Schwarze wrote: |i just assembled an overview of all the command line options of |man(1), groff(1), and closely related utilities: | | http://mdocml.bsd.lv/man/man.options.1.html | http://mdocml.bsd.lv/cgi-bin/cvsweb/man.options.1 Good sleuthing, it seems to me. I felt the immediate d

Re: [Groff] ASCII Minus Sign in man Pages.

Ralph Corderoy wrote: |Clarke wrote: |> used the simple hyphen character because it was all monospace. |... |> If a minus sign appeared in regular text, I always used \(mi. | |It was a lot easier then when the was only ASCII `-' and nothing else. |:-) .. |I'm no clearer. Except I'm not s

Re: [Groff] ASCII Minus Sign in man Pages.

"G. Branden Robinson" wrote: |At 2017-04-21T21:56:24-0400, Doug McIlroy wrote: |> I think it's pretty hopeless to ask for AI that can tell |> whether a pasted symbol is a hyphen or a minus sign. |> The answer is likely to depend on whether it is being |> pasted into a program or into a docume

Re: [Groff] ASCII Minus Sign in man Pages.

Doug McIlroy wrote: |I think it's pretty hopeless to ask for AI that can tell |whether a pasted symbol is a hyphen or a minus sign. |The answer is likely to depend on whether it is being |pasted into a program or into a document. Of course you are right. Just ignore my rash messages, please.

Re: [Groff] ASCII Minus Sign in man Pages.

"G. Branden Robinson" wrote: |At 2017-04-22T16:15:48+0200, Steffen Nurpmeso wrote: |> "G. Branden Robinson" wrote: |>|At 2017-04-21T21:56:24-0400, Doug McIlroy wrote: |>|> I think it's pretty hopeless to ask for AI that can tell |>|> whether

Re: [Groff] Nesting font macros in man pages

"G. Branden Robinson" wrote: |At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote: ... |I entirely agree with the virtues of semantic of "presentation"-based |markup. However, this could be mitigated by encouraging a consistent |style in groff_man(7) itself. Some coordination with Michael Kerr

Re: [Groff] Nesting font macros in man pages

Ingo Schwarze wrote: |G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400: ... |> If that means a new macro, I'm fine with that. ... |For man(7), introducing new macros would be worse. There, it would |utterly break portability because other implementations do exist, Now i r

Re: [Groff] Nesting font macros in man pages

"G. Branden Robinson" wrote: Sorry for answering so late, my daily routine has shifted to night again, almost sunset, and that really makes me frustrated. |At 2017-04-25T20:19:21+0200, Steffen Nurpmeso wrote: ... |>|> c. Show people a mapping from groff's "exte

Re: [Groff] Nesting font macros in man pages

Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200: |> the HTML output of mandoc used repeated per-paragraph style |> directives and a CSS file, which caused enormous bloat, last |> time i tried. | |Does that still apply to | | view-so

Re: [Groff] Nesting font macros in man pages

Deri James wrote: |On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote: |> Does that still apply to |> |> view-source:http://man.openbsd.org/ksh | |compared with a PDF version:- | |http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh Terrible, see the spacing errors surrounding the command list

Re: [Groff] Nesting font macros in man pages

Deri James wrote: |On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote: |> Terrible, see the spacing errors surrounding the command list |> before the "Substitution" heading! Not your fault of course, but |> gr... |> |> --steffen | |Well, turns out it WA

Re: [Groff] Nesting font macros in man pages

i wrote: |Ingo Schwarze wrote: ||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200: ... |As above. That is all for today, i spent three hopeless hours in |the pic lex code, even shallow cloned 67 MB of gnulib for a few KB |of datatable that doesn't get used the right way

Re: [Groff] Nesting font macros in man pages

i wrote: |Ingo Schwarze wrote: ||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200: ... ||P.S. ||Only bacause i'm replying anyway and it's just five lines: | |Sure. | ||> .Op : Ns Fl c Ar cc-addr Ns \&: ||> .Fl S Ar var Ns Op Ns = Ns Ar value Ns

Re: [Groff] [PATCH] correct some \c-related markup

"G. Branden Robinson" wrote: |Please find a patch attached. Ordinary an ordinary, is that true. I for one always found those one/two/one/two/.. macros very suspicious, but now i see actual use cases. --steffen |Soylent Green is people!

Re: [Groff] : ASCII Minus Sign in man Pages

Doug McIlroy wrote: |Originally \(pl and \(mi came from a fixed font (S) while + and \- |came from the current font. As I understand your comment, groff |has reversed this troff convention. Additionally groff interprets - as |a compromise HYPHEN-MINUS. | |man groff_char, however, tells the o

Re: [Groff] [PATCH] correct some \c-related markup

"G. Branden Robinson" wrote: |At 2017-05-01T19:30:02+0200, Steffen Nurpmeso wrote: |> "G. Branden Robinson" wrote: |>|Please find a patch attached. ... |> I for one always found those one/two/one/two/.. macros very |> suspicious, but now i see actual use c

Re: [Groff] : ASCII Minus Sign in man Pages

Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Tue, May 02, 2017 at 11:50:31AM +0200: |> I now think it is better to revert all those per-macro adjustments |> altogether and be pure; if people use \- to get "nicer" (smoother |> and finer that is) output then pasting fr

Re: [Groff] ASCII Minus Sign in man Pages

Mike Bianchi wrote: I absolutely and completely support this opinion of yours. Maybe except that it would be nice if some future user could easily find some documentation and now what to do to get "nice"r looking output, maybe with some command line argument (variable), or a configuration file,

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

Ralph Corderoy wrote: |>> You could try replacing `.INCLUDE' with `.so'. |> |> First thing I tried with the OP. Same problem. .so is definitely not |> playing nice with unicode. | |Ah, well, in that case, I think this explains it. .. |$ soelim foo | preconv | groff -Tutf8 | grep . |

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

Hey, Ingo, Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Fri, Jul 21, 2017 at 10:30:36PM +0200: | |> In my humble opinion preconv has to go as such, |> i just do not know yet. Just talking. | |So much talk... SIIGHH!!! |In mandoc, i completed that work in October 2014: | |

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

"E. Hoffmann" wrote: |Am Fri, 21 Jul 2017 16:28:04 -0400 |schrieb Peter Schaffter : | |[...] |>> $ soelim foo | preconv | groff -Tutf8 | grep . |>> foo: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç |>> bar: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç |>> $ |>> $ groff -V -Tutf8 -sk foo |>>

Re: [Groff] Bitstream vera sans

Hi. mikkel meinike wrote: |Can any of you walk me through what I should do to use the font 'bitstream |vera sans' in my groff document? The font is somehow available in my system |because I use it in my terminal (rxvt-unicode) Peter Schaffter has written something that might help you out[1].

Re: [Groff] pdfmom grep (was parallel text processing)

Peter Schaffter wrote: |On Fri, Sep 08, 2017, Ralph Corderoy wrote: |>> You'll notice that the top of the pdf file has a line of text spit out |>> by grep(1) that obviously shouldn't be there. |> |> I couldn't come up with the groff 1.22.3-7 command line required to |> build the PDF correct

Re: [Groff] pdfmom grep (was parallel text processing)

i wrote: |Peter Schaffter wrote: ||On Fri, Sep 08, 2017, Ralph Corderoy wrote: ||>> You'll notice that the top of the pdf file has a line of text spit out ||>> by grep(1) that obviously shouldn't be there. ... ||Problem solved. ... ||The solution is to pass the -a flag to grep. This flag

Re: [Groff] pdfmom grep (was parallel text processing)

cool, and maybe Freudian. Attached. (Ah, and i have tested it with my old groff installation, then copied it onto a current v1.22.3.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himse

[groff] Fwd: Re: [Groff] Knuth-Plass Algorithm

Sorry, hit the wrong button! -- >8 -- >8 -- Forwarded message -- 8< -- 8< -- Date: Thu, 09 Nov 2017 16:33:52 +0100 From: Steffen Nurpmeso To: Bertrand Garrigues Cc: Ingo Schwarze Subject: Re: [Groff] Knuth-Plass Algorithm Bertrand Garrigues wrote: .. |Hmm... Bug #40716 &quo

[groff] Commit [09040dbf] is wrong

Hi, i am in the process of syncing my GPL2 roff tree once again, hopefully to be able to start getting that thing going. Let me first wonder why my valid remark regarding that Unicode error (i have forgotten what it was, actually) is still not fixed even if now with that GNU patch-in library thing

Re: [groff] Commit [09040dbf] is wrong

i wrote: ... |I am here for something else, the commit mentioned changed ... |I come up with (uncompiled and untested): ... | | void | char_buffer::write_upto_newline(char_block **t, int *i, int is_html){ |enum {a_NONE, a_NL, a_LEADER} ev; |char *b; |int j, u; | |if

Re: [groff] Commit [09040dbf] is wrong

Werner LEMBERG wrote: |> Blush. This should have been |> |> ev = (++j < u && b[j] == HTML_INLINE_LEADER_CHAR) ? a_LEADER : a_NL; |> |> instead. Now fixed. (Still uncompiled and untested, of course.) | |Please file a bug report in the issue tracker so that it won't be |forgotten.

Re: [groff] 04/04: tmac: Move macro diagnostics away from `quotes'.

|commit 1294c8d2272e1c43b1b683e287deb1749865e642 |Author: G. Branden Robinson |Date: Sat Nov 18 17:55:26 2017 -0500 | |tmac: Move macro diagnostics away from `quotes'. | |Signed-off-by: G. Branden Robinson |--- .. | tmac/doc-common-u | 86 ++--

Re: [groff] 04/04: tmac: Move macro diagnostics away from `quotes'.

Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Sun, Nov 19, 2017 at 02:57:36AM +0100: | |> selfishly decides over a style issue | |I think there was a discussion on this list, and what Branden does |seems in line with the outcome to me. Really? I must have missed that t

Re: [groff] 01/03: contrib/hdtbl/examples/*.roff: Seed RNG.

Ok, i finally say something. g.branden.robin...@gmail.com (G. Branden Robinson) wrote: |commit da6ac443f21ef09d90b40d2e8215955c916f396a |Author: G. Branden Robinson |Date: Sun Nov 19 22:19:52 2017 -0500 | |contrib/hdtbl/examples/*.roff: Seed RNG. | |Support reproducible build

Re: [groff] 01/03: contrib/hdtbl/examples/*.roff: Seed RNG.

Hello Branden. "G. Branden Robinson" wrote: |At 2017-12-02T01:32:01+0100, Steffen Nurpmeso wrote: ... |> g.branden.robin...@gmail.com (G. Branden Robinson) wrote: |>|commit da6ac443f21ef09d90b40d2e8215955c916f396a |>|Author: G. Branden Robinson |>|Date: Sun Nov

Re: [groff] [UTROFF] Troff and xml

Pierre-Jean wrote: |For some reason, the html file was not joined, here it is... No it is not. Maybe your mailer is the cause.. Or the used version! But interesting all that. That would have been my idea for going HTML too, doing that in all of the macros which shall be usable, but i never re

Re: [groff] Problems redefining macro $c for -me macros

Hey. Stephanie Björk wrote: |For quite a bit, I've been trying to redefine the .$c macro for the -me |macros. According to the reference manual, the macro package allows the |user to redefine how chapters look when they get printed, by redefining |that macro. | |Here's my redefinition. In

Re: [groff] A macro package for lists in TROFF

Stephanie Björk wrote: |So, after having been on the mailing list for a bit, I've found that we are |all sharing quite cool things here. Just a day ago, I wrote something I do not. My macros are a bad hack. |quite nice in Troff -- a macro package that provides for something that |most macr

Re: [groff] html output of Op vs Oo Oc

Jan Stary wrote: |This is groff 1.22.3 as installed by the OpenBSD port. | |Below please find a short manpage written in mdoc(7), |which I am trying to process into html with | | groff -Thtml -mdoc rtpdump.1 > rtpdump.html | |One point where it seems to fail is | | .Oo Ar address Oc Ns /

Re: [groff] mdoc(7) .Lk: complete rewrite of the macro

Ingo Schwarze wrote: |i just posted a patch containing a complete rewrite of the mdoc(7) .Lk |macro to: https://savannah.gnu.org/bugs/index.php?52849 I have not seen the patch yet, but .Lk is terrible and unpredictable by the document author, as you say. Making it not go in stand-out mode woul

Re: [groff] Changing A Defined String

Robert Thorsby wrote: |Temperatures here in AU have been in the range 35-45 for the past week |and are forecast to be the same for the next week. So with no |inclination towards serious work I have turned my attention to |rewriting my letterhead shell script, as one does. And you have

Re: [groff] Changing A Defined String

Tadziu Hoffmann wrote: |Just a short addendum: | |Since you know that you'll only be stripping off one of the |known weekday names, there's also a simpler solution: ... |However, there is still a caveat with these solutions: although |\*[DATE*SHORT] may look like a (single-line) string exp

Re: [groff] Changing A Defined String

Tadziu Hoffmann wrote: |> Why this? If i use \\*[DATE*SHORT] anything is fine, so it is |> because the macro is evaluated while the string is defined. | |Yes. | |If you use the "string" like this: | | Some text before \*[DATE*SHORT], and some text after | |the expansion will yield |

Re: [groff] modernization, maintanership, separate packages

Doug McIlroy wrote: |All these threads are tangled in my mind, so ... | |-a: I use this quite regularly for quick peeks at line and page |breaks without the trouble of writing a file and looking at it |in another window. It is certainly the option I type most--the |rest are buried in shell s

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

Ralph Corderoy wrote: |Ingo wrote: |> The name of that standard section in man(7) and mdoc(7) is "EXIT |> STATUS", not "Exit Status" nor "Exit status" nor "exit status". | |The shouting section heading makes it easier to find that heading rather |than the same word occurring elsewhere, e.g.

  1   2   3   4   >