> > The markup used within those man pages is not bad since it tries
> > to separate content from layout. What do you think about a few
> > comment lines in the header to `help' doclifter, something like
> >
> > .\" doclifter: .File_name () == ...preferred doclifter command...
> > .\" doclift
Werner LEMBERG <[EMAIL PROTECTED]>:
> > > So I think this is worth fixing regardless of the specific case of
> > > DocBook conversion. groff is by far not the only program which is
> > > used to display the groff manual pages.
>
> Well, does this mean that I should refrain from using any GNU
> ext
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.
--
http://www.catb.org/~esr/";>Eric S. Raymond
__
Larry Kollar <[EMAIL PROTECTED]>:
> And, more to the point, why bother converting
> this entire body of documentation to DocBook if there's already
> a good way to convert it to cross-linked HTML? Wasn't that the
> whole point of this exercise anyway?
I tried to cover this earlier. T
Werner LEMBERG <[EMAIL PROTECTED]>:
> Simply replacing them with the `standard' man macros is not the
> optimal solution. Instead, I would rather prefer some helper
> instructions so that doclifter can do the translation without
> problems.
I tried a similar path. The problem is that in order to
> ... I agree with your assessment of *roff and TeX (I used both
> extensively). However, I did write a 10 page technical
> document (34 with the appendices that simply include the
> files) in DocBook-XML. I have turned away in disgust and
> never looked back.
I'll use Zvezdan's example here as
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> You mention above a good DocBook toolchain.
> Can you give us some detail?
> What do you use to produce DocBook-XML documents effectively?
> If you consider that this is off topic for the groff list, you can reply
> off the list. I'm really interested in giv
Werner LEMBERG <[EMAIL PROTECTED]>:
> Mhmm. I have yet to see a DocBook output which looks decent (in the
> sense of good typography) without postprocessing. Maybe I've seen
> only bad examples so far -- can you point me to something?
Um...the print version of "The Art of Unix Programming"? I t
Werner LEMBERG <[EMAIL PROTECTED]>:
> I don't disagree. However, how can I assure that the final result is
> typographically well formatted? While working on groff.texinfo I've
> found many shortcomings -- and normally texinfo does a good job. And
> I'm really not willing to sacrifice that.
mak
> > Looks fine to me!
>
> Good, I'll strip the others.
Don't be so quick, please!
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> > I would claim it is. The groff manual pages also cannot be
> > displayed properly by other manual page viewers. There are
> > some glitches even with Heirloom troff; although it can handle
> > the language, some groff-specific macros do not exist in its
> > -man implementation.
groff-specific
> You mention above a good DocBook toolchain.
> Can you give us some detail?
> What do you use to produce DocBook-XML documents effectively?
> If you consider that this is off topic for the groff list, you can
> reply off the list. I'm really interested in giving DocBook another
> chance.
Please
> I want to drastically simplify the markup used in several pieces of
> groff documentation, eliminating a lot of the hairy custom macros
> they presently use.
Mhmm.
> groffer.1
> groff_out.5
> groff_tmac.5
> groff.7.gz
> groff_char.7
> groff_mdoc.7
> groff_trace.7
>
> Technically this won't be
> But the world I'm trying to get us to looks something like this:
>
> +-+ ++
> | man pages |-+ +--->| HTML on browsers |
> +-+ | / +
> It also fails because it _insists_ on interactive navigation and
> there is no way (that I am aware of) to print out a definitive
> reference.
It's quite easy:
makeinfo --output=foo.txt --plaintext foo.texinfo
I like the texinfo format due to its decent output as PDF, plain text,
HTML and in
> I *am* "skilled hands" in that sense, having done successful
> full-length technical books in all three markups. Speaking from
> that experience, I rate groff better than TeX but inferior to a good
> DocBook toolchain (with the exception that TeX wins over both if you
> have to do really intens
Hi David and Werner,
I've examined the test code and observe two main problems:
(i) equations within .tl don't work - I suspect this could be made
to work..
(ii) the division by zero is occurring because the following
characters appear to have zero height in the html devi
On Sat, Dec 23, 2006 at 12:25:01AM -0500, Eric S. Raymond wrote:
> I *am* "skilled hands" in that sense, having done successful
> full-length technical books in all three markups. Speaking from
> that experience, I rate groff better than TeX but inferior to a good
> DocBook toolchain (with the exc
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 the idea.
>
> Looks fine to me!
> Ted.
Good
Ted Harding <[EMAIL PROTECTED]>:
> On 23-Dec-06 Peter Schaffter wrote:
> >> > (And brace yourselves for the *real* political bunfight, which
> >> > is when I try to kill off GNU info...)
> >>
> >> You could have an ally ... !
> >
> > And quite possibly another. :) Although, ironically, I have to
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 the idea.
Looks fine to me!
Ted.
-
On 23-Dec-06 Peter Schaffter wrote:
>> > (And brace yourselves for the *real* political bunfight, which
>> > is when I try to kill off GNU info...)
>>
>> You could have an ally ... !
>
> And quite possibly another. :) Although, ironically, I have to say
> I use groff's TeXinfo docs far more than
Peter Schaffter <[EMAIL PROTECTED]>:
> Eric's Web-centric, fully-
> hypertexted documentation is the ideal, methinks, but not at the
> cost of losing the ability to type "man " at the command
> line.
Agreed. This is why I pushed a patch into man last year that teache
Joining the bunfight...
On Sat, Dec 23, 2006, Ted Harding wrote:
> I'm personally not that interested in "groff for man-pages" as
> such (though I think that it's as good as anything else so it
> might as well be used), in that I would not favour the intrinsic
> functionality of groff being vulner
M Bianchi <[EMAIL PROTECTED]>:
> I'm beginning to think that maybe a wiki front end that yielded
> XML-DocBook of the RefEntry document type could encourage keeping
> lots of documentation current. The Linux Documentation Project
> might find that appealing also.
Perhaps that should be a project
Gunnar Ritter <[EMAIL PROTECTED]>:
> I would claim it is. The groff manual pages also cannot be
> displayed properly by other manual page viewers. There are
> some glitches even with Heirloom troff; although it can handle
> the language, some groff-specific macros do not exist in its
> -man impleme
On Sat, Dec 23, 2006 at 12:56:47AM -0500, Eric S. Raymond wrote:
> M Bianchi <[EMAIL PROTECTED]>:
> > On Fri, Dec 22, 2006 at 06:19:15PM -0500, Eric S. Raymond wrote:
> > > :
> I think you'll see from my previous reply to Ted Harding that
> I agree with this.
Yes, I see.
> :
> Well, of
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> I want to drastically simplify the markup used in several pieces of
> groff documentation, eliminating a lot of the hairy custom macros they
> presently use.
>
> groffer.1
> groff_out.5
> groff_tmac.5
> groff.7.gz
> groff_char.7
> groff_mdoc.7
> groff
28 matches
Mail list logo
