But I think it's time to move on. This little change will help us
get to a fully-hypertexted, Web-centric documentation corpus. Let's
do it.
(And brace yourselves for the *real* political bunfight, which
is when I try to kill off GNU info...)
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
change will help
> > us get to a fully-hypertexted, Web-centric documentation corpus.
> > Let's do it.
>
> So long, as I've argued above, as the basic structure is retained.
I hope I have allayed your nervousness on that score.
> > (And brace yourselves for the *re
M Bianchi <[EMAIL PROTECTED]>:
> On Fri, Dec 22, 2006 at 06:19:15PM -0500, Eric S. Raymond wrote:
> > :
> > But I hear you asking "Why fix what ain't broken?".
> > :
> > The philosophical issue this raises about groff's place in the wo
head and stripped
groff.1. It's enclosed. You may have trouble spotting the differences,
which is sort of the idea.
--
http://www.catb.org/~esr/";>Eric S. Raymond
fixed-groff.man
Description: Unix manual page
___
Groff m
for tackling the problem of adding
> appropriate structure to the document base. It _has_ needed attention.
You're welcome.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
d be
the most important HTML subtrees, but there could be others, including
project-specific others.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> I agree exactly with what Peter says!
> Ted.
Re killing off info...
I just discovered that the texinfo maintainer is soliciting help,
and appears to be shopping for a new project lead.
E:-) <--- ESR smiling evilly
--
http://www.catb.org/~esr/";>Eric S. Ray
Ted Harding <[EMAIL PROTECTED]>:
> On 23-Dec-06 Eric S. Raymond wrote:
> > [...]
> > Because response on the list was supportive, I went ahead and
> > stripped groff.1. It's enclosed. You may have trouble spotting
> > the differences, which is sort of
focused on the
"render to HTML" problem than the "render to print" problem.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ithout getting in the way.
It's info files as a delivery mechanism that I want to kill off. For
on-line browsing, Texinfo content should just merge into the rest of
the webby goodness instead of being its own weird little ghetto.
--
http://www.catb.org/~esr/";>E
th Java going open, I expect the
DocBook -> XSL:FO -> PostScript path via FOP will get really good
sometime in 2007 or early 2008.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
rsions.
3) It won't solve the actual problem with the simplified markup, which
is the command synopsis not looking as nice.
> Well, you can start your training with handling groff.texinfo...
Sorry, I don't understand that.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ir man pages.
The HTML driver has the same problem man2html and its ilk do.
No semantic analysis, ergo really stupid and thin translations.
I'm not just saying we can do better than that, I'm saying we
already have.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Werner LEMBERG <[EMAIL PROTECTED]>:
> > > Looks fine to me!
> >
> > Good, I'll strip the others.
>
> Don't be so quick, please!
Just because I'm stripping them doesn't mean you have to take them.
--
ould possibly be worth.
> BTW, it would have been better to use the current CVS version, which
> differs clearly in some parts.
This is OK. Now that I've done the conversion once, I can do it on
any similar document with a couple of Emacs commands.
--
http
27;t plan to write a
> `lifting' engine by yourself to handle texinfo, right?
No. Someone else has already done most of that work, there's a
makeinfo --docbook option. It doesn't work quite right, but fixing
it would definitely be easier than messing with groff-texinfo.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ation of conditionals right is so
complex and the edge cases so nasty that these cannot in general be
in the safe set.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
thus, you wouldn't have to wire in all the policy/styling
decisions you would in a DocBook->troff renderer.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
cing anything that's adequate as a structural
description.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Enclosed version of groff.1 uses only standard man macros and .de;
I've inserted .in and .br macros to make the Synopis pretty again.
--
http://www.catb.org/~esr/";>Eric S. Raymond
fixed-groff.man
Description: Uni
ions needing to do page
layout should generate FO as their last step; an XSL:FO renderer then
takes care of translating to a printer command language.
In practice, all the energy is in FO-to-Postscript translators like
Apache FOP.
--
http://www.catb.org/~esr/"
ultiple *roff implementations, what
would you propose as a safe set? You are probably the only person here
with experience of even more weird *roff variants than I know about,
so I would put your judgment on this above mine,
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ation with cliche
analysid can reveal structural info.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Gunnar Ritter <[EMAIL PROTECTED]>:
> I have often used .in (and seen it used) in a context like
> . Looking at a few pages, it seems that
> others have used .ti similarly.
Can you send me an example?
--
http://www.catb.org/~esr/&qu
warning that hand polishing might be
needed here. I try to avoid those without a really good reason,
though. Presently I think there's only one, attached to a truly wacky
edge case in processing of list markup.
I'm open to other suggestions.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
x27;s not obvious, I'm quite grateful to you and Larry and
the other participants in this thread for the critique you are
developing. I've been working in relative isolation on this program
for a *long* time -- it feels good, and rather bracing, to have my
assumptions questioned a bit.
000+ pages with
.ti moved from the ignore set to the complain set. I'm going to eyeball
all of those instances to see if I can spot usable patterns.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
; .in +\w'\fBtroff 'u
> .ti \niu
> .B troff
ought to turn into something like
def SY
.nr a \n(.j
.ad l
.nr i \n(.i
.in +\w'\fB\\$1 'u
.ti \niu
.B \\$1
.SY troff
That definition could then be re-used on other groff
This is one possible solution. You suggest another one in a
later post. I will discuss both in my reply.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
et those.
I don't have a strong feeling about which would be better. I guess I
lean a little towards .OP/.SY; I think it's simpler. But I would
cheerfully do the work necessary for either path.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
t might translate differently depending on
whether an indent was specified or not.
With these in place, almost all of the uses of ,in, .ti, and .br in
my 13,000-page corpus could go away and be replaced by pure man macros.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
hough. I had an idea yesterday
about how to handle .ti in the general case; I'm following it up now.
FYI, I found that only 78 of 13,466 (0.03%) pages contain .ti. That's
a low enough hit rate that I won't feel bad if we have to punt this case
with a wa
-mdoc markup is cleverly designed,
it is also quite complex -- more heavyweight than most man-page writers
want to deal with.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
can tell you this much: .EX/.EE was part of the Ultrix/OSF macro set,
so it shows up on a lot of Unix heirloom pages.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
t teaching doclifter to interpret .OP and .SY
would be extremely easy -- as in, done and tested ub 20 minutes or less.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
stigate and report.
One of the things I'm working on is a revised report on the safe set.
This will include a decription of safe \w calls and safe expression
components.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
G
88)
! /usr/share/man/man5/elinkskeys.5.gz=6 (0.88)
! /usr/share/man/man7/mdoc.7.gz=6 (0.42)
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
me
> less portable with such "fixes".
I was under the impression that even these syustems are mostly using
groff nowadays. Is that not so?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Gro
ely large percentage of Linux systems if
we get 1.20 out in time for FC7 and Debian etch, both of which
will probably ship 1Q 2007.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
copied to the limbo of each man page since we can't assume that
> those macros are present in any other man implementation.
>
> What else?
I'm still working on a definition of the safe set.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
in the other direction, unfortunately.
Norm Walsh's XML-DocBook stylesheets have a man-markup output mode,
but it doesn't render tables to TBL markup.
Steve Cheng's docbook2man does do that, however.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
d keep it simple.
.DS/.DE -- display formatting for running text
.EX/.EE -- format an example with indent and CW font.
The trouble is that existing man macros don't actually cover these cases;
you end up writing cliches with .nf/.fi and .RS/.RE to handle them.
--
g should correspond to .DS?
A *filled* block display? I have been translating it as an
unfilled block, with a tag -- that's what the examples
in my corpus seem to want, and the meaning it has in mm. It differs
from .EX/.EE only in that it doesn't force the font to CW.
--
h
.
Generally people just use .sp for this, which is why .sp may be
the only low-level request that's truly essential for man pages.
.FN
To format filenames. Nice -- doclifter recognizes the Ultrix extension --
but not necessary for doclifter as it is quite capable or recognizing
fil
of a variant of -man
> before.
You could be right. They might well both have gotten confused
and imported it separately from mm.
Regardless of where it came from, it would still be the second most
effective way to clean .ti, .in, and .nf/.fi calls out of my corpus.
--
http://www
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> If doclifter handles all these cases as well as you already described
> there is no need for an exception to man format.
It's going to be Werner's decision, ultimately.
--
http://www.catb.org/~
ot really be an issue if we tried to take that requirement seriously.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ly or confrontational question -- because doclifter
can turm your man pages into high-quality DocBook markup, it's
actually the *same* question.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
t isn't, but I think DocBook can win the argument even if we grant
your parallel.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
erience of reading the documentation. I don't care whether or
not man markup survives as a composition format; what I want is for
it to get out of HTML's way on the presentation end.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
> Which does not make the writing any faster.
> Picking one of 100+ tags from the menu is no fun.
> :-)
Agreed. I think this is a major reason this class if editors has
never caught on.
--
http://www.catb.org/~esr/";>Eric S. Raymond
t; bar
> Two options ...
Oh, I misunderstood TQ then. I thought it was to be used like this
.TP
Heading
This is an indented paragraph.
.TQ
This is another paragraph that is indented.
.PP
This paragraph will not be indented, as .PP has restored the
from Texinfo to DocBook was amazingly
liberating; among other things, I found I could move all my citation
and change history information into portions of the entry markup that
aren't mormally rendered, but still have it there for visual
inspection.
--
http://www.catb.org/~es
ner, I know it looks like an easy compromise, a soft option. But don't
go there. *Bad* idea...
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
'd rather make. "But think
of the blind people..."
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
erted to HTML for online reference.
Nothing in my scheme stops you from doing that.
> Am I completely missing the point, and being ignorant?
Um, well, yes.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
#x27;m encouraging it to die
faster.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
't have this. So maybe the current way is to
> really advise people to add this stuff to the man page's preamble.
In spite of the fact that it's in the latest version of the man package?
I guess I can see doing both as a transitional measure.
--
ht
to `an-old.tmac' (which is loaded by `andoc.tmac').
I wasn't clear on how all that was partitioned, is all.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
is not. What you are really doing with them is
making your man sources un-renderable by *anything* but groff.
That is the real bug here, and that's what needs to be fixed.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ard? The way this discussion has been going,
if you do maintain that position you are likely to find yourself in a
minority of one.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
rowser-centered presentation they increasingly expect.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ting sentiment. Very German. I doubt it will be widely persuasive
in any technical argument.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
;don't use troff
requests outside the safe set" and "don't put running-text notes in a
synopsis section" and "don't write multiple description lines".
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Gunnar Ritter <[EMAIL PROTECTED]>:
> > Interesting sentiment. Very German.
>
> Hey, he is not the only German participating here.
Sorry :-).
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff maili
sion/uncompression, v1.0.3
This and the constraint on command synopses (no embedded text) are the
only places where DocBook enforces a structural regularity that man
markup doesn't have.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
eployed first, which isn't easy.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
+--->| PostScript on printers |
+-+ |++
| other... |-+
+-+
The box in the middle is intended to indicate the use of DocBook as a
common interchange format.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
unnar, you could help by reporting which requests Heirloom Troff
and the KDE man-page viewer support. Is anybody else willing to
take on analyzing XMan, TKman, or Rosetta?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Gunnar Ritter <[EMAIL PROTECTED]>:
> "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>
> > Gunnar, you could help by reporting which requests Heirloom Troff
>
> Heirloom troff supports almost all groff requests; [much more]
Thanks, that's extremely hel
rested in content, yes. But I don't see how the rest of this
follows.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> This is a part of a paragraph from an -me document.
BTW, doclifter lifts -me documrnts. It doesn't di a very good job,
however; me macros don't carry as much structural info as man, ms,
or mm.
--
http://www.catb.org/~esr
sted." It's possible might have this behavior
on some back ends.
I'll add it to the set of escapes that throw warnings, so after my next
test we'll know exactly how often it is used.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
stomizable.
Looks like Fedora Core 6 carriers version 5.1.
I've looked for, but not found, some analog of a changelog for the
DocBook DTD. Do you know where I could find such a thing?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
g somewhere?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ith
> an indent. It would be a mistake to assume that every processing
> application will indent output.
Sorry, I am in fact abusing to translate .RS/.RE. And
yes, I was aware this was an abuse, but I don't know of any better way
to translate it. Can you offer one?
--
generated from doclifter DocBook using Norm Walsh's stylesheets.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
nstate it for case 3.
The good news is that this is certainly the worst and probably the only
DocBook tag abuse that doclifter commits.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Michael(tm) Smith <[EMAIL PROTECTED]>:
> The open-source XSL-FO engine project that truly deserves some
> more help is Tony Graham's xmlroff:
>
> http://www.xmlroff.org/
Why do you believe this has a future and FOP doesn't?
--
http://www.catb
"man " would just
> cause a browser (be it a curses-based browser or a GUI one) to be
> envoked and the page displayed in that.
I got the right hooks into man(1) to do this last year.
--
http://www.catb.org/~esr/";>Eric S. Raymond
__
Michael(tm) Smith <[EMAIL PROTECTED]>:
> DocBook itself does not provide any means for marking up pages
> breaks.
There is a tag. I don't know wha the stylesheets
do with it.
--
http://www.catb.org/~esr/";>Eric S. Raymond
eginpage.html
>
> "The break identified by BeginPage may be displayed in an online
> version of the document or used for legacy purposes, but it is not
> expected to cause a page break when the document is processed by
> an SGML system."
I read it. I found it ... marve
ad to rewrite the nane-section parsing completely, and that
revealed problems with a number of pages in which name sections contained
trailing junk.)
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Grof
niverse.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
are they?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
ng to?
I thought I'd seen a change history somewhere that said it had been rewritten
to take advantage of groff features.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Werner LEMBERG <[EMAIL PROTECTED]>:
> In 1999, I copied the mdoc man page from NetBSD (renaming it to
> groff_mdoc).
OK, I have located the current owner and shipped him the fix.
It's the mtk_manpages guy.
--
http://www.catb.org/~esr/&
d the groff glyphs mapping to
Latin-1 as portable.
I favor setting a floor that includes Latin-1.
2) When, in the portable-subset description, can we say that .EX/.EE,
.SY/.OP, and .DS/.DE should be considered portable and no longer
need local definitions?
I think two years from when w
This mail is going to the man maintainer and the
groff list; please talk among yourselves until you figure out what needs
to be done.
A good question to begin with is probably "why does that --legacy
NROFF_OLD_CHARSET need to be there at all?"
--
ht
Gunnar Ritter <[EMAIL PROTECTED]>:
> "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>
> > Note that .br/.nl, .ti, .ta, and .in are *not* in the portable set.
> > These cannot be translated structurally by doclifter, and man-to-HTML
> > translators tend
>
> We will see; this is certainly possible. But as I said,
> we are not the ones who make the decision here. We can
> only observe what happens and write our recommendations
> accordingly.
What sort of trigger point would you fin acceptble? When proprietary-Unix
market share falls below 10%? 5%? 1%?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
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
___
a TTY window showing `man' output would be sufficient IMHO)
> if the number of problems exceeds a certain threshold.
And that's an excellent idea for a general fallback.
> > 2) When, in the portable-subset description, can we say that
> > .EX/.EE,
in the groff man pages only. I too would like for somebody to design
something better, but I'm not wlling to let the absence of a perfect
solution blocxk any progress at all, and I don't think Werner us either.
--
http://www.catb.org/~esr/";>Eric S. Raymond
1%. A portability guide
> has to describe the facts: ".EX and .EE are currently
> predefined on systems A, B, and C; system X lacks support
> for them. If you intend your software to be portable for
> X, you should include the definitions for .EX and .EE a
that are broken
for other reasons.
> > > Ideally, they should use groff for formatting (opening a TTY
> > > window showing `man' output would be sufficient IMHO) if the
> > > number of problems exceeds a certain threshold.
> >
> > And that's an excellent idea for a general fallback.
>
> groffer.1 comes to my mind :-)
Well, yes. But for this to work, we'd have to push patches out for
every single viewer first. That's a rather high price to pay to avoid
offending one sulky groff contributor when we can fix the problem in
one spot upstream.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
t a brief for the obsolescence of *roff; typesetting
is still typesetting and involves a rather different kind of
constraints than formatting for on-line viewing.)
This is what the discussion of viewer portability comes down to,
because the new viewers all render to HTML amnd it is dead obvious
that the
f the good things about man(1), which are
(a) the retrieval style, and (b) fast, lightweight operation.
But that's not a problem in my head, it's a problem in yours. *I* have
not confused the man retrieval style with its display channel;
he non-portable set, but I handle some common .ti cliches
better than I do.
> I'll fix the rest of groff in due course. However, this might only
> happen after we've defined (and coded) the proposed man macro
> extensions.
Don't let the p
ff.tmac file for these new
groff-page extensions.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
1 - 100 of 321 matches
Mail list logo
