On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson
wrote:
> I guess another way of saying this is that, as I conceive it, a line
> that is "adequately full" contributes to the page's uniformity of
> grayness by definition.
For an example of less-than-ideal results if this is _not_ considered
the
On Fri, May 2, 2025 at 8:07 AM Martin Lemaire wrote:
> Off-topic to Alejandro's initial question but related to the subject of
> justifying text set in monospace, do we owe this typographic gesture to
> the early *roff formaters or was it already a thing in previous
> publication tool, either soft
FWIW, in case you want to update the ChangeLog entry, I also
encountered this failure on gcc 9.3.0. (This commit showed up just as
I was about to submit a bug report.)
On Sun, Apr 20, 2025 at 8:54 PM Ingo Schwarze wrote:
> So just deleting it would still be the best option even now.
A better option is deprecating it
(http://savannah.gnu.org/bugs/?64772). It could emit a warning that
it's unmaintained. But, unlike deletion, this would allow users who
find it u
On Thu, Mar 13, 2025 at 10:58 PM Damian McGuckin wrote:
> I went back to a posting from 10 Nov 2002 where Greg Leahy responded to
> Larry McVoy and suggested:
>
> .de overstrike
> .nr width \w'\\$1'
> \\$1\v'-.25v'\h'address@hidden@u'\l'address@hidden@u'\v'.25v'
> ..
Hi Damian,
You've hit a doub
Hi, and welcome to the world of groff!
Tackling your second issue first:
On Wed, Mar 12, 2025 at 10:32 PM dvalin--- via GNU roff typesetting
system discussion wrote:
> OK, let's skip the macro library, and rely only on basic troff stuff.
>
> That should help me get the hang of things at a simple
On Sun, Mar 9, 2025 at 11:03 AM G. Branden Robinson
wrote:
> it appears that "removing" characters may have never really worked,
> because the act of looking one up created it.
Do you have sample input that demonstrates this? Two simple
tests--using the "c" conditional, and attempting to use the
On Sun, Feb 23, 2025 at 8:52 PM G. Branden Robinson
wrote:
> At 2025-02-24T03:36:28+0100, onf wrote:
> > I think the point is that such filenames aren't being used,
>
> No, that's not "the point". It's _your_ point,
Hey, originally it was *my* point :-P
> > so breaking compatibility (and making
On Sun, Feb 23, 2025 at 9:41 PM G. Branden Robinson
wrote:
> Please refrain from offering advice in areas beyond your expertise, at
> least without admitting the same.
>
> You're getting into Bjarni territory here. (That's the groff
> community's version of the Dunning-Kruger syndrome.)
This com
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 sure neatroff won't adopt it as it currently stands.
I'm in favor of cross-roff compatibility whenever pos
On Fri, Feb 7, 2025 at 3:06 AM G. Branden Robinson
wrote:
> At 2025-02-06T23:23:57-0600, Dave Kemper wrote:
> > The info file documents it the same way it documents everything else:
> > any attribute associated with an environment has this association
> > explicitly state
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 ' (without the quotes).
Correct. I opened http://savannah.gnu.org/bugs/?66673 in response to
this observation about the
On Sat, Feb 8, 2025 at 3:11 PM Colin Watson wrote:
> I hope 1.24 can be the start of a practice of doing smaller and more
> frequent groff releases, with which this sort of thing would be much
> less of a problem.
I'd like to see that as well, but the reason I've never pushed for it
is that there
On Tue, Feb 4, 2025 at 6:05 PM Tadziu Hoffmann
wrote:
> Given that so many attributes (for example, the hyphenation
> mode) are in fact associated with the environment, I just
> found it surprising that this isn't, (and the info file
> doesn't mention it).
The info file documents it the same way
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 this challenge (having been in
prior discussion about it on savannah), I've had a few e
On Tue, Jan 28, 2025 at 6:40 PM G. Branden Robinson
wrote:
> > On Tue, Jan 21, 2025 at 8:11 AM onf wrote:
> > > I think groff would benefit from neatroff's hydash request:
> > > hydash CHARS
> > > Specify the list of characters after which words may be broken
> > > (even when hyphenatio
On Mon, Jan 27, 2025 at 6:27 AM G. Branden Robinson
wrote:
> Dave Kemper's done some solid QA work that should avoid
> embarrassment in groff 1.24.0.rc1.
Thanks! But so that the record's not overstated:
It's great that groff has hundreds of regression tests now. But a
On Tue, Jan 21, 2025 at 8:11 AM onf wrote:
> I think groff would benefit from neatroff's hydash request:
> hydash CHARS
> Specify the list of characters after which words may be broken
> (even when hyphenation is disabled) without inserting hyphens.
Sounds like a prime candidate to file
On Sat, Jan 4, 2025 at 7:24 AM Ihor Radchenko wrote:
> "G. Branden Robinson" writes:
> > So another thing to know here is that these italic correction escape
> > sequences are, yet again, GNU troff extensions. A legacy formatter is
> > likely to render them as if the backslash were absent, which
On Fri, Dec 20, 2024 at 4:15 PM onf wrote:
> Does it have any other use nowadays besides regression testing?
The -a option is invaluable for testing in general, such as when
debugging some typesetting issues. In
http://savannah.gnu.org/bugs/?55278#comment0 some other uses I gave
are letting the
On Mon, Dec 16, 2024 at 8:28 AM G. Branden Robinson
wrote:
> I don't feel I have sufficiently broad knowledge of what man-parsing
> tools are out there besides *roffs and mandoc(1).
Fair enough, and perhaps a decent reason on its own to be conservative
with language additions.
> Plan 9 troff is
On Sat, Dec 14, 2024 at 12:02 PM G. Branden Robinson
wrote:
> This is likely due for a cleaned up re-proposal under the new names
> `QS`/`QE` as suggested by Doug McIlroy.
Man pages using these proposed macros--which, since the macros don't
exist yet, will be man pages edited in 2025 or l
On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
wrote:
> By contrast, your sample size for `ne` misuse is one--yourself.
> Formerly two, before I came to understand the request.
Well, I agree with onf's point that .ne's behavior defies user
expectation, so you can lump me in with that sample.
On Sat, Nov 2, 2024 at 5:08 AM G. Branden Robinson
wrote:
> At 2024-11-01T21:07:29+0100, Alejandro Colomar wrote:
> > No, this isn't outdated, since that reduces the quality of the diff.
> > Also, I review a lot of patches in the mail client, without running
> > git(1). And it's not just for revi
On Thu, Nov 21, 2024 at 7:50 PM G. Branden Robinson
wrote:
> At 2024-11-22T01:24:20+0100, onf wrote:
> > The result is that it seems impossible to build groff without
> > installing texinfo despite the program itself not depending on it in
> > any way, which is completely absurd.
>
> Some people f
On Wed, Nov 13, 2024 at 1:44 PM Oliver Corff via GNU roff typesetting
system discussion wrote:
> In me, adding a footer with .fo 'arg left'arg center'arg right' works as
> expected, with the blatantly obvious limitation that the elements of the
> footer should not contain line breaks.
>
> However,
On Thu, Nov 14, 2024 at 11:11 AM G. Branden Robinson
wrote:
> I think this would break the part of the file that sets up the
> hyphenation codes, which have to be 8-bit encoded given the current
> state of the formatter.
The only 8-bit characters in ru.tmac are on the ".ds \*[locale]"
lines; the
On Fri, Nov 8, 2024 at 10:20 AM Oliver Corff wrote:
> \n[LL] produces 468000.
Yes. It's not intuitive that registers defined using any other units
are stored in basic units, and that groff must be explicitly told this
whenever such values are referenced.
$ cat testfile
.nr a 4i
.tm \n[a]
$ grof
The commit log (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=f486938c5)
says:
> Spell string translations using groff special character escape
> sequences instead of Latin-1 or Latin-9 code points; this way they
> work with a document that uses them no matter what its own encoding.
>
> I
Hi onf,
Parsing strings that contain escapes is something that an open groff
bug report (http://savannah.gnu.org/bugs/?62264) seeks to make more
consistent. Does the mechanism proposed in that report sound like it
would solve the problem you're facing? (By default, the savannah bug
tracker displ
On Sat, Oct 26, 2024 at 9:01 PM Bjarni Ingi Gislason wrote:
> In the file "tmac/pdfpic.tmac" the request '.pso' is used with a variable.
> As this request is only valid in an unsafe mode (groff option '-U') it only
> may take a constant text.
As http://savannah.gnu.org/bugs/?66382 points out, t
On Wed, Oct 16, 2024 at 8:53 PM G. Branden Robinson
wrote:
> Where _is_ that interface?
https://lists.gnu.org/mailman/admin/groff (with similar URL for
bug-groff and (I presume though have never checked) groff-commit)
If you don't have the password, I'll send it off-list.
> The "new GNU maintai
On Wed, Oct 16, 2024 at 7:01 PM joerg van den hoff wrote:
> I wrote to groff-bug, I wanted (and want) to keep the response on that list.
> that's my decision, not
> yours.
Just so you know, bug-groff (like groff-commit) is not intended to be
a discussion list; it exists to lets users see all ema
On Wed, Oct 16, 2024 at 3:01 PM joerg van den hoff wrote:
> I now double-checked: the manual seems to indicate that w/o preceding mk, rt
> needs an argument
> (distance from page top). if it _really_ does the line would have to read
> `.rt 0'. but doing this
> does not change behaviour neither f
On Sun, Oct 13, 2024 at 8:31 AM G. Branden Robinson
wrote:
> It isn't, yet. What you have seen is a Savannah bug report about it.[2]
> It was filed anonymously. ("Who _was_ that masked man?" Dave Kemper, I
> reckon.)
Guilty. I (sometimes) anonymously file tickets in
On Fri, Oct 4, 2024 at 7:00 PM G. Branden Robinson
wrote:
> Putting the 1.23.0 and Git renderings side by side, leaping to the end
> and scrolling backwards, it takes a while to find discrepancies.
"diff <(groff-1.23 -a utp.mac) <(groff-HEAD -a utp.mac)" is pretty
fast. Since -a output indicates
On Fri, Oct 4, 2024 at 2:21 PM G. Branden Robinson
wrote:
> At 2024-10-04T16:41:19+0100, Deri wrote:
> > I am certainly not against changes to groff, but I do think when we do
> > alter groff in some way which will affect the typesetting of existing
> > documents
>
> ...which the font warning chan
On Sun, Sep 22, 2024 at 6:52 PM G. Branden Robinson
wrote:
> [discussion moved to groff@ which is a discussion list; I feel that
> bug-groff@, like groff-commit@, is not--Reply-To set accordingly]
Agreed, but the message to which you're replying wasn't "discussion"
on bug-groff@, but a comment po
I didn't often interact with Ted directly, but I encountered his posts
frequently in my trawls through the mailing list archive in search of
answers to some question or other. His oeuvre has helped me more than
once (and his posts were a pleasure to read even when they didn't
apply to my question)
Follow-up Comment #7, bug #66103 (group groff):
[comment #1 comment #1:]
> Use of a colon is poor grammar when the ensuing list fails to
> exhibit sentence-ending punctuation,
Avoiding such constructions is a valid style choice, but it's hard to justify
calling it poor grammar when respected styl
On Thu, Sep 5, 2024 at 2:31 PM Deri wrote:
> if Dave wants to use use Spin̈al Tap
> This seems to work:-
>
> printf ".ft TINOR\n.ps 18\nSpin\h'-5p'\[u0308]\h'+5p'al Tap\n.pdfbookmark 1
> Spi\[u006E_0308]al Tap"|test-groff -Tpdf -ms > Spin̈alTap
On Thu, Sep 5, 2024 at 4:06 PM Peter Schaffter wrote:
> there being no meaningful .cu available for PostScript or PDF
> output. (Should we raise this issue again? Nothing ever seems to
> get done no matter how much we discuss it.)
It has a Savannah ticket, opened in response to a 2014 thread on
On Wed, Sep 4, 2024 at 11:04 AM Deri wrote:
> The example using \
> [u012F] is superior (in my opinion) because it is using a single glyph the
> font designer intended for that character rather than combining two glyphs
> that don't marry up too well.
I agree with this opinion.
> If you know of
Commit 298a0281f
(http://git.savannah.gnu.org/cgit/groff.git/commit/?id=298a0281f)
modified how the em dash is displayed on UTF-8 terminals. I have
reservations about this change and want to get other opinions.
The change applies only to UTF-8 output, the only terminal encoding
that includes an e
On Thu, Aug 8, 2024 at 7:59 AM Vincent Lefevre wrote:
> FYI, +-0 could be interpreted by the reader as in C, where a unary
> minus operator is applied, then a unary plus operator. And about +/-0,
> the "/" is already used a the division operator, so that this doesn't
> help parsing.
It helps *som
On Tue, Aug 6, 2024 at 3:53 PM G. Branden Robinson
wrote:
> At 2024-08-06T15:28:25-0500, Dave Kemper wrote:
> > That will solve the problem for English. Are there other language
> > files that will need it?
>
> Every other groff localization file for a Western language --
On Tue, Aug 6, 2024 at 1:34 PM G. Branden Robinson
wrote:
> At 2024-08-06T12:08:29-0500, Dave Kemper wrote:
> > This is the only line in your test file output before any .hcode
> > requests were run, so this shows the default hyphenation for the
> > system.
>
> Well
On Tue, Aug 6, 2024 at 9:48 AM G. Branden Robinson
wrote:
> I'm thinking this has more to do with line length handling than
> hyphenation; `-ww` before `-Wbreak` might have helped.
I'm half-certain it has to do with when latin1.tmac is loaded and when it isn't.
$ echo ".tm Hi, I'm latin1.tmac!"
On Wed, Jul 31, 2024 at 11:51 PM Werner LEMBERG wrote:
> > However, in the meantime, meaning for groff 1.24, I propose to move
> > `hcode` definitions to where they make more sense: the character set
> > macro files "koi8-r.tmac", "latin1.tmac", "latin2.tmac", and
> > "latin9.tmac". (If/when I do
On Tue, Jul 30, 2024 at 6:45 PM G. Branden Robinson
wrote:
> I hope you will join me in thanking him for his excellent work.
Absolutely. Bertrand, your contributions, being mostly to the
underpinnings, may never have been as visible as Werner's when he was
maintainer, but are no less important.
On Wed, Jul 24, 2024 at 2:24 PM G. Branden Robinson
wrote:
> At 2024-07-24T13:28:04-0500, G. Branden Robinson wrote:
> > I notice now that those claims about the margin sizes might be off by
> > one vee; in my experience, a "margin" measures an extent of whitespace
> > (or "negative space"), where
On Mon, Jun 3, 2024 at 9:06 PM G. Branden Robinson
wrote:
> [1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n50
>
> The foregoing line number will get stale with time. Look for the
> text "hydefault".
You can stale-proof git URLs that point to line numbers by specifying
a parti
I haven't built a groff since 1.23. When I did so today, the first
step produced a query I hadn't seen in a groff build before.
$ ./bootstrap
/bin/mv: overwrite '.gitignore'?
I said "y" to this, and the result was that the top-level .gitignore
file gained a "/build-aux" line at the top, before t
In a few places, the groff Texinfo manual uses a line-ending @ to
continue a @cindex entry. An example is:
@DefreqList {tm, message}
@DefreqItemx {tm1, [@code{"}]message}
@DefreqListEndx {tmc, [@code{"}]message}
@cindex print to the standard error stream (@code{tm}, @code{tm1},@
@code{t
On Tue, May 14, 2024 at 8:53 AM G. Branden Robinson
wrote:
> I aim to drop EBCDIC a.k.a.
> code page (CCSID) 1047 support from groff 1.24.
No objection to this.
> The idea is, for 1.24, to get everybody migrating to pure ASCII input
> documents (as might be generated by preconv(1)) by the time G
On Fri, May 10, 2024 at 1:50 AM Gáspár Gergő wrote:
> I realized, however, that the "hungarumlauts" on the ő Ő ű and Ű glyphs are
> placed incorrectly in the built-in fonts of groff used for the pdf device.
Does this mean the problem doesn't happen for the ps device? Or have
you not tried that?
On Sat, Apr 20, 2024 at 5:21 PM Alejandro Colomar wrote:
> > It does occur
> > to me that we might enhance afmtodit make of use of it as the
> > default "spacewidth".
>
> That sounds like a great idea.
Would you be willing to open a savannah request for this feature?
https://savannah.gn
On Sun, Mar 31, 2024 at 5:31 AM Colin Watson wrote:
> I've omitted README.git to ensure that we still warn people who don't
> know what they're doing that running "./bootstrap" may not be the right
> place to start.
*raises hand* I am one of those who don't know what they're doing --
at least as
On Tue, Apr 2, 2024 at 10:14 PM Steve Izma wrote:
> Good question. One experiment might be to choose a long paragraph
> and typeset it in TeX, Heirloom troff, and groff and see what the
> differences are. Yes, I know, I should probably walk the talk,
> but I don't have Heirloom troff installed and
On Tue, Apr 2, 2024 at 3:29 PM Dave Kemper wrote:
> It would be interesting to know if someone with experience using the
> Heirloom troff implementation of this algorithm (and with a good
> typographic eye) has noticed the same problem there. That is, is it a
> bug in the algorithm i
On Tue, Apr 2, 2024 at 1:52 PM Dave Kemper wrote:
> .ll 1n
> \[rq]\%antidisestablishmentarianism\[lq]
> .br
> \%\[rq]antidisestablishmentarianism\[lq]
Ha, if I'd looked at the output of something other than -Tascii, I'd
have realized I got my "lq" and "rq&q
On Tue, Apr 2, 2024 at 2:23 PM Steve Izma wrote:
> I used TeX and LaTeX [...] and the oversetting of lines caused
> by the periodic failure of the paragraph-justification algorithms
> drove me nuts. [...] The many lines that overset by only a
> few points made proofreading really difficult. That's
On Tue, Apr 2, 2024 at 11:53 AM Tadziu Hoffmann
wrote:
> Also, "\&" is not a letter, so a leading "\&"
> should not influence hyphenation at all.
\[rq] is also not a letter, but it affects how \% is interpreted,
giving it its hyphenation-point meaning rather than its
suppress-hyphenation one. I
On Sat, Mar 23, 2024 at 1:29 PM G. Branden Robinson
wrote:
> (I've been slowly accumulating evidence that, for basic editing
> operations, vi _really is_ more keystroke-efficient than Emacs,
Not just in requiring fewer keystrokes, but in the ergonomics of them
too: (1) It requires fewer key comb
On Fri, Mar 22, 2024 at 5:24 PM G. Branden Robinson
wrote:
> My view is expressed in groff(1):
...
>An even easier way to do this is to use grog(1) to guess the
>preprocessor and macro options and execute the result by using
>the command substitution feature of the shell.
>
I don't have any complaint with your proposal, but it sounds like what
you need is a makefile or script to insure groff runs are done the
same way every time. More simplistically, you can define a shell
alias to invoke all preprocessors: "alias groff='groff -k -e -p -t
-R'". (Or name the alias so
On Sun, Mar 17, 2024 at 3:53 PM G. Branden Robinson
wrote:
> At 2024-03-16T12:32:44-0700, Russ Allbery wrote:
> > 1. Do you think you'll change the long-standing groff default from
> >full justification to ragged right under nroff in the an macro set
> >for the next release?
>
> No.
> Here
On Tue, Mar 19, 2024 at 1:28 PM Lennart Jablonka wrote:
> replace Courier by a non-fixed-width type face, because we really don’t
> need to emulate the nonsense typewriters do in print.
True if it were emulating only typewriters, but fixed-width fonts are
still very common in terminal emulators.
On Sun, Mar 17, 2024 at 2:42 PM G. Branden Robinson
wrote:
> If Sourceware's policy is to maintain an archive only consequent to some
> sort of _official_ request, then such would probably need to come from
> Bertrand Garrigues, who is still groff's GNU maintainer.
Additionally, Werner is the adm
On Fri, Mar 15, 2024 at 8:34 AM G. Branden Robinson
wrote:
> At 2024-03-14T22:02:26-0700, Russ Allbery wrote:
> > Now, any .TP directive restores full justification for all subsequent
> > text. This appears to be due to the addition of:
> >
> > . ad \\*[AD]
> >
> > in an-write-paragraph-tag. I'
On 3/8/24, G. Branden Robinson wrote:
> Sorry for the recent extra complication;
Nothing to apologize for: it was easy to figure out, and I understand
the rationale for the change.
> it didn't occur to me that
> people wouldn't just have make(1) generate the real thing.
Well, you've found me ou
On 3/8/24, ropers wrote:
> The thing I've given up on was figuring out how to preview my
> edits to groff.texi
This took me a while to figure out at first too, and the procedure
gained an extra step since that time (when groff.texi was converted to
groff.texi.in to require preprocessing) so it's
Hi Ian, thanks for your attention to the groff manual!
On 3/7/24, ropers wrote:
> "latin1" sounds awfully ISO-8859-1ish, and (I fear) not very much like
> the Latin-1 Supplement Unicode block
Correct. Since there are two different things that include "Latin-1"
in their name, perhaps this wordin
On 3/6/24, ropers wrote:
> -In fact, the ending marker is itself the name of a macro to be
> -called, or a request to be invoked, if it is defined at the time its
> -control line is read.
> +In fact, the ending marker can itself be the name of another macro to be
> +called, or a request to be invo
On 3/4/24, G. Branden Robinson wrote:
> The following change could probably use some additional eyeballs. It's
> one of the things Deri and I disagreed about.
Is Deri's view archived anywhere?
On 3/2/24, G. Branden Robinson wrote:
> Often in *roff typesetting, things like tables of contents come at the
> end of the document because it is only then that enough information is
> known to format them correctly. This can be true of cover sheets too if
> some reason they require information
On 2/23/24, Larry Kollar wrote:
> But in the case of groff, there’s at least twice as many years of inertia
> (compared to XML) to consider. It really does make sense that an -mm
> based book file should invoke the macro package(s) it needs, but so
> many of us are automatically going to put that
Haha. I hate to turn down accolades, but this isn't my crusade alone:
http://en.wikipedia.org/wiki/Wikipedia:It_should_be_noted
(But I do love that the Hamilton College Writing Center's page
"Eliminating Wordiness"
(http://www.hamilton.edu/academics/centers/writing/writing-resources/eliminating-w
On 2/22/24, G. Branden Robinson wrote:
> I've come to think that a set of "best practice" for *roff document
> composition is to:
>
> A. Load your desired full-service macro package (if any) on the command
> line with `-m`.
> B. Load any auxiliary macro packages that your document _requires_
On 2/6/24, G. Branden Robinson wrote:
> Fair! I forgot about this. Before posting, I scanned down the request
> list in groff(7) to protect myself from embarrassment--uselessly.
The advantage of my brain holding far fewer groff requests than yours
is that it can allocate space for more detail a
Deri,
I'm very sad to see your departure. This list and the groff project
will sorely miss your knowledge, expertise, and coding skills. I hope
you find a way to return soon.
On 2/5/24, hoh...@posteo.de wrote:
> On Tue, 9 Jan 2024 01:13:45 -0600
> Dave Kemper wrote:
>
>> In the message to which I was replying, you were speaking of the
>> sequence of bytes that were part of the input to gpic; in this realm,
>> ECMA-48 is irrelevant. And in
On 2/5/24, G. Branden Robinson wrote:
> As far as I know, groff has never extended AT&T troff syntax in _this_
> respect.
>
> The argument count to requests (unlike macros) is seemingly sacrosanct.
Groff extended the .ss request by adding an optional second parameter
where AT&T's took only one.
On 1/22/24, Oliver Corff wrote:
> yes, I did have a look at that section of the groff documentation, and I
> must confess that I read the text as non-exhaustive, meaning the five
> specific ligatures are built-in, with the option to increase the
> repertoire of ligatures.
You're right, the wordin
On 1/23/24, G. Branden Robinson wrote:
> At 2024-01-23T20:52:34-0600, Dave Kemper wrote:
>> However, .bp arguably shouldn't have been affected by the change,
>> since it probably wasn't subject to the same historical ambiguity.
>
> I agree, and I wasn't happy a
On 1/23/24, Bjarni Ingi Gislason wrote:
> Macros for historical documents should be put into a separate
> directory (e.g., tmac/historical), which can then be searched
> with the '-M ' option.
As the NEWS item (posted in full a couple hours ago in this thread)
mentions, this change *increases*
On 1/23/24, T. Kurt Bond wrote:
> I have a groff -ms source file
[...]
> When I groff it with version 1.23.0 the page breaks
> corresponding to the explicit .bp requests are missing.
This item in the (very lengthy) NEWS file for 1.23 probably explains
the change you're seeing:
The s (ms) macro
On 1/21/24, Oliver Corff via wrote:
> Now the question which is not language-specific: In how far can groff
> access these font-internal lookup tables? It appears that the "naive"
> approach does not trigger the ligature mechanism in the font, as
> demonstrated by Tom's and Deri's examples.
>
> Is
On 1/8/24, hoh...@posteo.de wrote:
> On Tue, 2 Jan 2024 11:04:25 -0600
> Dave Kemper wrote:
>
>> > ECMA-48 says for 0x84:
>>
>> Also irrelevant to groff, as it doesn't use ECMA-48. Groff tools
>> (including gpic) take input in Latin-1, period.
>
>
On 1/8/24, Robert Thorsby wrote:
> I realize that man pages and info documents are not always the easiest
> material to read but, for $DIETY's sake, the info page even has a pretty
> little line-drawing image that shows the relationships between the
> various components that go into the sizing of
On 1/3/24, G. Branden Robinson wrote:
> +{
> + my ($v, $d, $f) = File::Spec->splitpath($prog);
> + $prog = $f;
> +}
Since $v and $d are being discarded anyway, perl doesn't require you
to create dummy variables for them.
(http://perldoc.perl.org/perlfunc#my-VARLIST) You can say:
my (undef,
[moving this back to the thread where it belongs]
On 1/2/24, hoh...@posteo.de wrote:
> If gpic gets Ä (0xc3 0x84) it complains about 0x84.
> If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4.
True, but irrelevant, because *in neither case will the character be
interpreted the way you in
On 12/28/23, holger.herrl...@posteo.de wrote:
> echo ä | gpic | hexStream
> 0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x53 | .if !dPS
> 0x20 0x2e 0x64 0x73 0x20 0x50 0x53 0x0a | .ds PS.
> 0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x45 | .if !dPE
> 0x20 0x2e 0x64 0x73 0x20 0x50 0x45 0x0a | .ds PE.
> 0x2e 0
On 12/26/23, holger.herrl...@posteo.de wrote:
> echo Ä | gpic
> .if !dPS .ds PS
> .if !dPE .ds PE
> .lf 1 -
> gpic::1: invalid input character code 132
> �
Hi Holger,
The paste above doesn't reveal what sequences of bytes your "echo" is
outputting, but I deduce it's UTF-8, since "U+00C4 LATIN CA
On 12/18/23, Oliver Corff via wrote:
> I tried to compile my minimal document again, with all combinations of
> -e, -F /usr/share/fonts/urw35-base/ but nothing changes. The PDF file is
> always 11771 bytes long. Embedding a font or a glyph should make a
> difference, or not?
Embedding a font will
On 12/12/23, Wael Karram wrote:
> Now, it doesn't work anymore after a recent groff update. What ends
> up happening is that indeed the text is aligned as intended - but on
> different consecutive lines.
> Omitting the DEs makes it work as intended, but gives a warning about un-
> terminated DSes.
On 12/7/23, Carl Milsted wrote:
> I cloned your repo and found the bugs and fixed them on my machine. I'd
> like to know the proper procedure to send the fixes back your way. I
> have not contributed to a GNU project before.
Hi Carl,
You can open a bug report in the groff bug tracker
(https://sa
On 12/1/23, Darris Hawks wrote:
> There are a couple of things that are unclear to me after reading the
> manual for GNU refer.
Hi Darris,
Can you clarify what documentation you were reading--and, if it was
the refer(1) man page, which version of groff you have installed?
I ask because this man
On 11/29/23, hbezemer--- via wrote:
> When changing -ms to -mm (the macro I'm using): No images are created.
>
> Maybe groff_mm(7) is the culprit?
Different macro packages provide different definitions of .PS and .PE.
Some seem to work with grohtml and some not:
$ cat foo.n
.PS
box
.PE
$ groff -
On 11/21/23, Oliver Corff wrote:
> So the first line effectively was:
>
> .ig
>
> No wonder it did not work. Would it be meaningful to (optionally) tell
> groff to jump over or throw away BOMs it encounters at the beginning of
> a file? Or should sanity and awareness be left with the astute user?
1 - 100 of 509 matches
Mail list logo
