> Werner Lemberg wanted to know the status of \~. I found 17 uses
> within the groff documentation and 4 outside it. Of those 4, two
> were errors. So it's not much needed for manual pages, which is a
> good thing as it is not portable. In particular, I was unable to
> discover any correspondi
> Under Fedora Core 6, installing groff 1.19 from CVS totally breaks
> man(1).
:-)
> All manual pages display as blank. This appears to be the result of
> a mismatch between what /etc/man.conf expects and the way groff-1.19
> behaves.
The behaviour of groff hasn't changed in last few years, ex
> I consider a manual page portable when it can be formatted in all
> viewers without flaws. But this does not forbid further careful
> optimization for a certain viewer (i.e. nroff) as long as it does
> not cause the output of other viewers to get worse.
Well, we have `.if n', `.if t', \n[.g] (
On Fri, Jan 05, 2007 at 02:37:51PM +0100, Werner LEMBERG wrote:
>
> > "make install" doesn't install the mm macros from the contrib/mm
> > directory.
>
> Thanks for the report!
Thanks for the fix! It installs fine now.
jen.
___
bug-groff mailing li
Werner LEMBERG <[EMAIL PROTECTED]>:
> >(I had to link /usr/bin/tbl to /usr/bin/gtbl.)
>
> Hmm. Why that?
Apparently because man.config wants to invoke /usr/bin/gtbl.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff maili
Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-08 08:02 +0100:
> > Werner Lemberg wanted to know the status of \~. I found 17 uses
> > within the groff documentation and 4 outside it. Of those 4, two
> > were errors. So it's not much needed for manual pages, which is a
> > good thing as it is not
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Werner Lemberg wanted to know the status of \~. I found 17 uses
> > within the groff documentation and 4 outside it. Of those 4, two
> > were errors. So it's not much needed for manual pages, which is a
> > good thing as it is not portable. In particular,
> > 1. If the input encoding has been explicitly specified, use it.
> >
> > 2. Otherwise, check whether the input starts with a Byte Order
> >Mark. If found, use it.
> > 3. Finally, check whether there is a known coding tag in either
> >the first or second input line. If found, use it.
> > Both `\' and `\~' (and \0) are equivalent to
>
> But they're different in that "\~" stretches while "\"
> doesn't, right?
Yes, but viewed from the input encoding side, they are completely
identical.
> I have observed problems in some environments with display of lines
> containing "\~" (wh
Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-08 15:44 +0100:
[quoting me]
> > I have observed problems in some environments with display of lines
> > containing "\~" (which is why the DocBook manpages stylesheet
> > outputs "\" instead).
>
> Details, please.
Sorry, I don't have many. But for what
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Gunnar seems to think UTF-8 is the right direction.
Yes, with the exception of CJK writers, people all over
the world seem to agree on that, and it is unlikely that
anybody except those will even have the idea to write
text documents like troff input
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> What requests would you say are "visually safe" in the way you are defining
> that are not on the portable list? (It is presently .de .ds .fi .ft .ie .if
> .ig .nf .nr .rm .rn .so .sp). You make a case for .hy/.nh/.ad; what others
> would you add?
Gunnar Ritter <[EMAIL PROTECTED]>:
> All I want is to avoid an incomplete hack extension to -man
> which seems useful just for this discussion but does not
> result in a general improvement.
What you're likely to get is an "incomplete hack extension" that's used
in the groff man pages only. I too
Gunnar Ritter <[EMAIL PROTECTED]>:
> As I wrote, it depends on context.
And as I wrote, that's not a useful answer. Any portability rule that can't
be explained over a telephone and mechanically checked is going to become
irrelevant because authors simply won't apply it. They have other things
to
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> > Maybe. But still the tools should not complain if a troff
> > expert has decided that something is safe.
>
> And how are they going to do that? Mental telepathy? :-)
As I wrote in the text following, by separating a "lint"
(or "-Wall") mode and si
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter <[EMAIL PROTECTED]>:
> > All I want is to avoid an incomplete hack extension to -man
> > which seems useful just for this discussion but does not
> > result in a general improvement.
>
> What you're likely to get is an "incomplete hack e
Werner LEMBERG <[EMAIL PROTECTED]>:
> My mistake. Anyway, I think XML also knows Unicode character
> entities, right? This is what I have meant.
Yes, you can embed Unicode entities in XML. Right now doclifter does this
for a handful of cases in which the right ISO entities don't exist. The
se
Gunnar Ritter <[EMAIL PROTECTED]>:
> > > Maybe. But still the tools should not complain if a troff
> > > expert has decided that something is safe.
> >
> > And how are they going to do that? Mental telepathy? :-)
>
> As I wrote in the text following, by separating a "lint"
> (or "-Wall") mode and
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter <[EMAIL PROTECTED]>:
> > > > Maybe. But still the tools should not complain if a troff
> > > > expert has decided that something is safe.
> > >
> > > And how are they going to do that? Mental telepathy? :-)
> >
> > As I wrote in the te
> Looking at my code, I see there is one more exception; troff \*(an,
> horizontal arrow extension, can't be mapped either. You'd think
> there'd be an ISO entity for this somewhere in the AMSA arrow set,
> but there isn't. Nor have I found a Unicode equivalent.
U+23AF HORIZONTAL LINE EXTENSION
Gunnar Ritter <[EMAIL PROTECTED]>:
> Yes, and authors would also get nasty bug reports from
> people who compile their manual pages with the switch
> turned off because it is the default. This would be as
> bad as gcc shipping with -Wall enabled by default.
Only authors who didn't strict-validate
Werner LEMBERG <[EMAIL PROTECTED]>:
> > Looking at my code, I see there is one more exception; troff \*(an,
> > horizontal arrow extension, can't be mapped either. You'd think
> > there'd be an ISO entity for this somewhere in the AMSA arrow set,
> > but there isn't. Nor have I found a Unicode eq
> You wouldn't happen to know of mappings for the bracket pile
> graphics, would you?
What do you think about looking into groff_char also, not just
lifting? :-)
All I know Unicode mapping is already in this file.
> > I'll fix the rest of groff in due course. However, this might
> > only happe
23 matches
Mail list logo
