I'm testing some groff source with non-GNU troff in an
OpenSolaris/ SunOS 5.11 environment and noticed a problem. I'm
using \(aq in the source to represent straight apostrophes, but
when I view the TTY output, no apostrophes (nor any other
characters) show up where they should be.
Does \(aq not wo
> > You mean a `spaces-at-line-start' macro, similar to the
> > empty-line-macro?
>
> Yes, that would work. Thus, the user defines a particular macro
> name to change the default effect of space-at-line-start (implicit
> .br), just like the user defines BLM to change the default effect of
> empty-
> I enclose a pair of patches as a shar file attachmant
Thanks! Applied to the CVS, with one minor correction:
+.IR Note :
+the registers
+.REG rsb ,
+.REG rst ,
+.REG skw
+and
+.REG ssc
+were read-only in earlier releases.
This is not correct: Those registers have always been read/write
regis
It should be enough to just check that the line (otherwise not empty) begins
with at least one space. Reading ahead to count the number of spaces is not
needed, and may indeed be bad, because the spaces need to print as usual.
As a example, consider the following text:
"This is a paragraph. T
On Monday 09 February 2009 17:47:56 brian m. carlson wrote:
> On Mon, Feb 09, 2009 at 01:56:18PM +0300, Anton Shepelev wrote:
> > groff version 1.19.2
>
> I assume since you're using Apple Mail that you're using Mac OS X.
> If so, is this the groff version that comes with Mac OS X? I seem
> to re
On Monday 09 February 2009 12:28:48 walter harms wrote:
> grotty::5: character above first line discarded
I used to see this routinely, with groff-1.18.x. It is irritating,
but seemingly benign, and it is no longer an issue in 1.19 onwards.
--
Regards,
Keith.
> It should be enough to just check that the line (otherwise not
> empty) begins with at least one space. Reading ahead to count the
> number of spaces is not needed, and may indeed be bad, because the
> spaces need to print as usual.
Groff does this already while processing leading spaces in a
