Sorry the previous bug report was unclear; hope I've made it better.
Yes, thanks! Applied to the CVS.
Werner
___
Bug-groff mailing list
Bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
When I visit Savannah, however, only the CVS repository for the groff
web site is available.
CVS_RSH=ssh; export CVS_RSH
cvs -d:ext:[EMAIL PROTECTED]/cvsroot/groff -z5 co groff
Werner
___
Bug-groff mailing list
Bug-groff@gnu.org
DESCRIPTION OF INCORRECT BEHAVIOUR:
sqrt function in EQN seems to behave badly
Hmm, the PS output looks fine -- eqn has no other possibility than to
scale the right whole square root glyph, with the result that it looks
far too fat. Only if you use the -Tdvi device you get a decent
looking
DESCRIPTION OF INCORRECT BEHAVIOUR:
Inside a list the H1 register seems to get messed up using MM and
EQN.
I've also forwarded this bug report to the mm author.
Werner
___
Bug-groff mailing list
Bug-groff@gnu.org
o Since version 1.19 you can say `.vs 0'. Older versions emit a warning
and convert this to `.vs \n[.V]'.
This seems to break my tables, which have been using '.vs 0' to
disable vertical movement inside gtbl macro.
Hmm, why can't you change
.vs 0
to
.vs \n[.V]
in your macro
Now I'm really confused. My intention IS to get a zero vertical
spacing.
You don't get one with groff 1.18 -- \n[.V] for devps output is *very*
small (1/72000 inch). Anyway, it increases the vertical position
counter which probably triggers some trap (I haven't checked the code)
...
The
groff-1.19.2 does not compile on IRIX 5.3 because
src/utils/pfbtops/pfbtops.c uses getopt_long() which IRIX 5.3 does
not provide. Prior versions did not have that issue.
This is already fixed in the current CVS, I think. Please test.
Werner
The following bug still exists in 1.19.2. I've identified the
problem -- see below.
Sorry, but your analysis is wrong.
.S 27 29
.SP
foo
.SK
foo.tr:4: fatal error: input stack limit exceeded (probable
infinite loop)
Happens
file foo:
.nr q 1
.nr N 1
.af q i
.ie (\n[q]=1)(\n[N]=1) .tm Ho!
.el .tm boo
.fp 1 PR
.fp 2 PI
.fp 3 PB
.fp 4 PBI
.fp 5 CW
.fp 6 CI
.fp 7 CB
.fp 8 H
.fp 9 HB
.ds HF 3 3 3 4 4 4 3
.BR bold roman
groff -ww -mm foo foo.ps
bug.r:4: expected `;' after scale-indicator (got `=')
I used New Century Schoolbook for fonts 1, 2, and 3, and Courier for
font 4. They were specified by four lines in the manpage macros I
was using that I had modified from the ATT to suit my own purposes.
This is still possible.
I assume the .fam request came along when groff was invented...
I don't see how this is related to the concept of accessing a font
position directly. \f[B] does the same, doesn't it?
It does now, but in 1989-1993 there was no .fam request, and it was
much easier to use .fp instead of \f(NB or some such thing in a
macro file, having to change it
Currently, your project does not support the DESTDIR variable in
generated Makefiles (marked as optional in the GNU coding policies,
make and automake manual).
Indeed.
In my opinion, DESTDIR support can be very helpful for the user, the
distribution-specific packagers and third-party
The bug-groff mailing list was previously accepting mail from
anyone, thus unfortunately passing on plenty of spam. With
Werner's approval, I've now configured it to hold messages from
strangers, so there may be a small delay for first-time
posters.
Perhaps this could be
This pic drawing parses fine, but I don't get the results I expect.
It is as though the with .whatever isn't there. I think line
has the same problem as arrow, but I have used arrows here to make
.PS
box
arrow up with .start at last box.nw
arrow right with .end at last box.nw
arrow down
Dear FreeTypers and groffers!
Dear Savannah hackers!
From time to time it happens that gnu.org (and nongnu.org) gets
`blacklisted', which means that a bunch of servers no longer accept
email from the gnu.org mailing lists. It takes some time until this
action has been reverted. The normal
This report highlights two problems with the mm macro package.
Both your patches are now in the CVS. Thanks again. I'm now
convinced that your proposed solution is the right one, and that my
suggestions are bad. I've also documented that R, I, and B are
hardwired to positions 1, 2, and 3.
Sorry for the late reply.
It looks to me that the lines
.nr pg*footer-size 5v\ 1v+footer+even/odd footer+2v
.nr pg*header-size 7v\ 3v+header+even/odd header+2v
are executed when m.tmac is loaded, so 5v is converted to u units
based on the vertical spacing at that time. .S
Equation numbers are not justified within the right margin
This is fixed now.
and only the last equation number is applied to an entire display
block.
This is a feature. I've documented it. You can suppress the
insertion of additional vertical space between displays by setting
number
`preconv -h' is aborted by the failed assertion as below.
$ ./src/preproc/preconv/preconv -h
./src/preproc/preconv/preconv: Failed assertion at line 1164, file
`preconv.cpp'.
Abort trap (core dumped)
Patch applied.
`preconv --version' says without iconv support when the iconv
[This file exhibits another problem: In spite of a correct version
statement, lilypond CVS from 2006-06-18 complains about a missing
\version line.]
%
% [EMAIL PROTECTED]
\version 2.9.10
\header { texidoc =
In chords, the start and end of slurs must not be positioned
too near to the center
I just got groff-1.19
This is old. Please try groff-1.19.2.
1. In a side directory of the untarred bundle I did
../groff-1.19/configure
make
The make failed due to not being able to find gnu.eps which is
the untar tree.
This should be fixed since a long time.
2. When I
[I've Cc'ed the groff mailing list to reach a broader audience.]
I'm using GNU groff version 1.19.2, but I've observed this problem
with previous versions going back several years. Using the ms macro
package, the HM (header margin) and FM (footer margin) variables
don't appear to have any
I got the latest version and problem 1 was fixed. I did however have the
second problem still
Aah, maybe I've fixed it in the current CVS only; I can't remember. I
hope to release 1.19.3 within a month or so.
Werner
___
bug-groff mailing
groff -p -U does not pass the -U flag on to pic. As pic has a
default of -S, it is impossible to run pic in unsafe mode from the
groff front end.
Fixed in the CVS. Thanks for the report!
Werner
___
bug-groff mailing list
bug-groff@gnu.org
\s[-\n(.s] resets the size to the previous value while \s-\n(.s
sets it to the smallest possible value, which seems inconsistent:
Fixed, thanks. At the same time, I've disallowed `\s-[-...]' and
friends.
Werner
___
bug-groff mailing list
At the same time, I've disallowed `\s-[-...]' and friends.
Why? Their previous behavior was just fine mathematically.
First of all, it isn't documented. Secondly, it creates an ambiguity:
shall the second minus character start a relative size change (within
the relative size change), or
Yes it is: \s+[N] ... N is a numeric expression.
Oops.
Reverted, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
To be completely sure: Do you get a file `grnexmpl.ps' which displays
an electronic circuit diagram?
Yes, I do.
Thanks. Anyway, I have to update grn to something newer since at
least two people get a segfault with the code from 1.18.1.3.
Werner
Would you mind taking a look at
http://www.linuxfromscratch.org/~matthew/patches/groff-1.18.1.4-debian_fixes-1.patch
(379KB!) to see if there's anything there you could merge upstream?
Will do, thanks.
rant
On the other hand, it quite annoys me that the Debian people (and guys
from other
I investigated and found that GNU pic crashes if I invoke a macro
with more than nine arguments: [...]
This is now fixed in the CVS. I've added code to support up to 32
macro arguments (up to 16 on EBCDIC platforms).
To make it really generic, this is, to support an arbitrary number of
I would like to report a problem with groff compilation when the
blank line macro request (.blm) is used. [...]
Your analysis is wrong. The problem is completely unrelated to the
blank line macro. It is possible to reduce your example to this:
.ev 1
.br
.ev
.LP
x
The call to
Since this hasn't been observed until now, it would appear that the
OP is trying to achieve something rather unusual. As [EMAIL PROTECTED]'
needs to be invoked in environment 0, perhaps a warning could be
emitted if the environment has been changed before initialisation
occurs?
Good idea!
I would go by what the printer manufacturers say -
OK, your arguments sound convincing. Fixed in the CVS. And thanks
for the report!
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
May I complement you and your colleagues and thank you all for the
GNU troff suite. It is obviously excellently done. [...]
Thanks for the praise. However, we lack an active maintainer for the
mm macros (which I've never used). Jörgen Hägg apparently has either
no time or no interest to
I observed this unexpected behaviour:-- [...]
Ok to apply the following patch, which resolves this?
Please do.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
Arfrever Frehtes Taifersar Arahesis
What a name! May I ask where you come from?
I tried to build trunk version of Groff and I had this problem:
xpmtoppm ./gnu.xpm | pnmdepth 15 | \
pnmtops -noturn -rle gnu.eps
/bin/sh: xpmtoppm: command not found
/bin/sh: line 1: pnmtops:
Here's what I did for my document:
\(sr\z\([EMAIL PROTECTED]@
(where
.EQ
delim @@
.EN )
Perhaps eqn could do that as well?
And I'm not saying that the glyph is ruined on large fonts: I'm
saying that each character overlaps, like in the other guy's
original PostScript output. I
I figured out the problem, but not the solution.
Both of the ones you gave me just now look perfect because they use
Type 1 fonts, while the one generated by my PostScript system uses a
subset of the TrueType font equivalent, which is why it looks wacky.
Hmm. I think there is nothing I
The continuation at the beginning does not work as expected since it
ends with the comment, and the third line is executed in any
case. However, since the macro file is normally processed by
strip.sed before it is installed, this problem disappears for the
installed version. [...]
The
Cannot render HTML documents using Groff on .gz man files directly.
Of course not. You have first to uncompress, then you can process it.
Example:
gunzip -c foo.1.gz | groff -Thtml -mandoc foo.1.html
Werner
___
bug-groff mailing list
However, I believe the nroff wrapper should still honor TYPESETTER
as it is attempting to be compatible with nroff and that's how nroff
worked by my reading of the documentation.
You can't assume in general that the devices have the same name. For
example, `37', `450', `lp' are valid (TTY)
I tried to use groff's -Thtml; it worked beautifully, except for the
fact that post-html.cpp produces
vertical-align=top
in the CSS section. This should probably be changed to
vertical-align:top
Applied, thanks! Und ein gutes Neues!
Werner
I solve it with patch, which is attached. Please let me know, if
it's ok this way.
This is the correct change (which is in newer versions of groff since
many years, BTW).
Werner
___
bug-groff mailing list
bug-groff@gnu.org
In groff, the .ne, .nw, .se and .sw corners of a line are all placed
at the start of a line. I don't have access to the original pic but
I do have access to the Plan 9 pic which places these four corners
at the centre of the line.
This behaviour is basically unspecified but see below for
This should be pretty obvious:
Applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
When I run a make depend, I get a bunch of warnings like:
./device.c:12: warning: No include path in which to find X11/Xos.h
The following fixes it, but I'm not sure whether it would be better
to add the EXTRA flags to the ALL flags instead.
I've applied your patch as-is. Thanks!
In makefiles, the $ macro is only guaranteed to be defined in
inference rules, not in explicit target rules. [...]
Most versions of ls don't have a --color option. [...]
Both patches applied, thanks.
Werner
___
bug-groff mailing list
In Gpic 1.18.1.4 a box with rounded corners cannot be filled
with color.
Fixed already in the current CVS.
Thanks for the report.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
There seems to be a bug in either the mm macros or gtroff itself,
where if the .S directive is used to change the vertical spacing
after a .ne command, then if the text adds up to more than one
page-length an abort occurs with
fatal error: input stack limit exceeded (probable infinite
I'm looking at the nroff script in SLES 10 (2.6.16.46-0.12-smp) and
I'm not sure of the exact relationship between SLES 10 and the Linux
project, but the issue is fairly simple. The newer script has
clearly taken away the concatenation of input files and processes
only the first file it
DESCRIPTION OF INCORRECT BEHAVIOUR: Always generates a warning. .EQ
and .EN are used from eqnrc before the user can define them.
SUGGESTED FIX: Add the following to the very start of eqnrc
.de EQ
..
.de EN
..
Fixed (in a slightly different way) in CVS. Thanks.
Werner
This patch fixes bug in the preconv.man.
Patch attached.
Applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
Following patch adds -D in the preconv to change the input encoding
by default.
Thanks, applied (with modifications). Note, however, that I need a
disclaimer in case you want to contribute more code (see below).
Additionally, it makes my life easier if you write a ChangeLog entry
also.
URL:
http://savannah.gnu.org/bugs/?24527
Summary: equaionts in .tl confuses grohtml
Project: GNU troff
Submitted by: wl
Submitted on: Sa 11 Okt 2008 08:57:56 CEST
Category: None
Severity: 3 - Normal
in pic 1.18.1 (obtained through cygwin)
.PS
sprintf(xxx%gxxx,123)
.PE
produces the text xxxgxxx
I can't reproduce this. On my openSuSE GNU/Linux box, with both pic
1.18.1 and 1.20.1, I get the expected `xxx123xxx' result.
Please contact the cygwin maintainers for further assistance
They should be written using the aq character name.
Fixed in CVS, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
The construct
\o'\0.'
draws the diagnostic
standard input:1: normal or special character expected (got a
node) in groff 1.20.1. Apparently \0 is not treated as a special
character, as it was in original troff.
Fixed in CVS. Thanks for the report. \o now accepts all escapes
which produce
It would be nice to just:
#if defined(__INTERIX) !defined(_ALL_SOURCE)
#define _ALL_SOURCE
#endif
Indeed, this seems to be the right solution.
in lib.h, but that invites clashing declarations like:
/src/groff-1.20/src/include/lib.h:120: error: declaration of C function `int
The autoconf tests are run without the #define of _ALL_SOURCE so
they get a different view of if things are declared or not. This is
a common problem with autoconf.
Not anymore; autoconf version 2.60 added proper support for this, and
version 2.62 fixed it for Interix.
If you can foist the
While this bug was reported against groff 1.18.1.1, I've confirmed that
the typo is still present in groff CVS
Applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
While this was reported against groff 1.18.1.1 and the patch doesn't
quite apply any more, the substance of the report is still valid
with groff CVS HEAD, and I agree with the English improvement (or
maybe become standard usage?). Here's an updated patch.
Applied too, thanks.
Werner
Using groff 1.20.1, it seems that play with -mfr or try to load
the hyphen.fr file in a doc currently just draws groff to not make
any hyphen at all.
Visibly, the problem comes from a trailing \endinput TeX command
in hyphen.fr, which prevents file from being loaded correctly.
Please
I can't cross-compile groff-1.20.1 with gcc-4.4.1. [...]
/bin/sh: /mnt/clfs/sources/groff-build/src/roff/groff/groff: cannot
execute binary file
I think this is because the host machine is 32-bit, while the target
machine is 64-bit, so the groff command cannot be executed. The
build
if (radius d)
radius = d;
Your fix sounds reasonable. Thanks for the analysis! I don't see
any reason at all why there is this loop. In case noone objects
I'll apply your change within a few days.
This is now in the CVS.
Werner
gdiffmk unnecessarily uses a function declaration syntax that only
works with bash. The changes necessary to make it work with other
POSIX shells as well (dash is now Debian's default /bin/sh) are
trivial, and follow.
Applied, thanks.
Werner
I have found an inconsistency of the behavior of the man pack- age
with its manual. The manual says (about the .TP macro):
The indentation is set to nnn if that argument is
supplied (the default unit is `n' if omitted), other-
wise it is set to the previous indentation
The documentation of .PP mentions that it restores the
indentation. However, `restore' is not precise
enough; I've now slightly improved the wording.
Thank you. What actually confused me is that the .PP command
is not mentioned in the description of the .TP macro,
Here's another trouble I have run into. I tried the .SY com-
mand to produce a nice synopsys specification, but it didn't
work right. Then I tried GROFFing the troff(1) page (which I
believe should be OK) and the .SY macro gave wrong results
again: [...]
I can't repeat this. For
In most cases the patch is very simple: just replace
printf(string) with printf(%s, string). This is the case of
Groff =)
The attached patch was made for the 1.20.1 version but also applies
to the current cvs checkout.
Applied, thanks.
Werner
Hyphenation is Winch-es-ter instead of Win-ches-ter according to
the execption case.
Exceptional hyphenation in the hyphenex... files does not
work if the word has a captial initial.
Works if the word in the \hyphenation block begins with
a lower letter.
Fixed in CVS. Thanks for
I just had a look at source code file
groff-1.18.1.1/src/devices/grops/ps.cc,
This is oold -- 1.18.1 has been released more than seven years ago.
char buf[256];
while (fgets(buf, 512, fp) != 0) {
It seems slightly less than optimal to me to allow 512 characters
into a buffer of size
With file1, the text is not vertically centered between the two
lines.
Correct.
Specifically, the distance between the top of the text and the top
line is much smaller than between the bottom of the text and the
bottom line.
Correct.
Using old ATT tbl/troff, the text is properly
Define pg*col-top after the paragraph has been initialized.
Sorry for the long delay. Applied finally to the CVS, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
m4/groff.m4 Line 750
x0 should be x1
(configure wrongly reports no previous groff installation)
You haven't read the message carefully: configure reports no previous
*troff* installation. This is not the same: In this test, GROFF_G
checks whether there exists a `troff' binary which
DESCRIPTION OF INCORRECT BEHAVIOUR:
/groff-current/src/roff/troff/node.h:277: undefined reference to
`node::~node()'
SUGGESTED FIX: ??? I note differences from initial release of 1.20.1
are small, but that compiles.
Remove the `inline' keyword as described in the last entry of the
PROBLEMS
Werner, could you apply this patch? FreeBSD 7.3 hasn't been
released yet, but -RC1 is out. I noticed also that we needed to
add an entry for IEEE Std 1003.1-2008, which the following patch
takes care of.
Applied, thanks.
Werner
___
Among other things fixed a while ago,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256226 reports that
groff uses the 'trap' builtin with numeric signal names rather than
named signal names. POSIX only supports named signal names and '0';
the other numeric signals are XSI extensions.
The .Dx macro doesn't work correctly due to doc-common not having a
register setting for Dx.
Thanks. This patch has been already applied on 2009-10-26 to the CVS
repository.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
Hi. I have some additional postscript fonts that I like to have
available. Every time I install Linux I have to copy these into the
/usr/share/.../devps directory and update the download and DESC
files.
Is there some way to specify a search path (e.g., an environment
variable) so that I
The french hyphenation file doesn't work.
Thanks for the report. This has already been fixed in the current
CVS.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
[about latin2 support for groff]
Since this topic is possibly of broader interest, I'm CCing this mail
to the groff mailing list. It's nothing new, but...
GROFF VERSION: 1.18
This version is far too old. The current one is 1.20.1.
OS: openSuSE 11.2
Sigh. If you don't need Japanese
To prevent failed make install on subsequent makes, change all ln
-s to ln -sf This holds fair for most packages.
Please give more details. Can you provide a log file of your failure?
Werner
___
bug-groff mailing list
bug-groff@gnu.org
GROFF VERSION: 1.20
MACHINE: noname
OS: openSuSE 11.2
COMPILER: g++ 4.4
INPUT FILES: tmac/groff_mdoc.n
COMMAND LINE: ./test-groff -s -mandoc -Tascii tmac/groff_mdoc.n
DESCRIPTION OF INCORRECT BEHAVIOUR:
Tons of warnings, and the resulting text is stripped, defaced and
Tons of warnings, and the resulting text is stripped, defaced and
unreadable. I suppose it is a problem in tmac/groff_mdoc.n, not in
groff itself.
Workaround:
ln '-s' '.' 'tmac/mdoc'
This reduces the number of errors to just five: [...]
Well, there are no warnings or error messages
DESCRIPTION OF INCORRECT BEHAVIOUR: devps families A, BM and
font ZCMI are wrong, and represent out-of-date versions.
SUGGESTED FIX: In the directory Adobe-Core35_AFMs-229 make links
where required to .afm files with the base name same as FontName
entry, then remake.
Fixed, thanks. While
The problem is a simple and/or confusion when negated:
Applied, thanks. I've done the same for the `nP' command.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
The CVS version of MM uses the troff page number(\n%) for TOC
entries rather than the MM page number (\nP).
Applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
DESCRIPTION OF INCORRECT BEHAVIOUR:
Section header in comment is Legalize
Thanks. I've fixed all other occurences (but one) too.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
DESCRIPTION OF INCORRECT BEHAVIOUR:
The text says: See Expressions, for more info. However, the
referenced node does not describe all expressions that are available
for this instruction.
Patch applied, thanks.
Werner
___
bug-groff mailing
The .O number register is undocumented. Here's a diff to add it to
the groff_diff man page. (Note that I've chose to document it as a
read-only register in accordance with its name even though it
appears to be a read/write register in the code.)
Applied, thanks.
Werner
DESCRIPTION OF INCORRECT BEHAVIOUR:
The command '.Nm' causes a line break in SYNOPSIS. This is probably
desirable because manual pages such as pftp.1 depend on it;
however, this feature is not mentioned in tmac/groff_mdoc.n. Here
is the result:
NAME
name name
SYNOPSIS
name
+ .Ql .Nm
+ causes a line break within the
+ .Sx SYNOPSIS
+ section.
+ .Pp
Applied. Thanks a lot!
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
The mm macros support the traditional ATT names for the page
headers (}t, }e, and }o) but not the footers.
Patch applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
The MM macros should define the string \*(BU regardless of whether the
.BL macro is used or not.
Patch applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
I'm building groff 1.20.1 from the cvs repository using MinGW with gcc
4.5.0 on Win XP and texinfo 4.13.
I get the following error:
...
./groff.texinfo:68: Unknown index `tp' and/or `cp' in @synindex.
makeinfo: Removing output file
I have decided it would be better to fill them with a summary of the
documentation provided in the separate manual page. I have
rewritten the information from the manual page so as to make it more
compact; I have also skipped the options that are documented as
private. Please review and
Attached is a patch that includes the new DFly release, the
tmac/doc-common strings and the information for OpenBSD.
Thanks, applied!
Btw, I think the whole checking of known OS versions is kinda futile
...
Well, yes, this is inherited stuff, IIRC.
And one more nit, the Changelog
I just noticed that tbl was crashing under certain conditions with
the nospaces option. [...]
Everything works here. But, if, say we didn't have a value in the
second column, but still had spaces, we get a segmentation fault in
tbl:
Fixed in CVS. Thanks for the report!
Werner
I happened to notice this typo in Makefile.comm, as a result of
wondering why my make output contained '-I/src/libs/gnulib/lib'.
Applied, thanks.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
* src/devices/grotty/tty.cpp (tty_printer::make_underline): Only
emit a single backspace in no-SGR mode. less (at least) backspaces
over a character at a time.
(tty_printer::make_bold): Likewise.
=== modified file 'src/devices/grotty/tty.cpp'
---
1 - 100 of 279 matches
Mail list logo
