Related to some current discussions on the list, I wanted to
mention a few projects I'm aware of that have authored their
man-page documentation in DocBook and used the DocBook Project
XSLT stylesheets to generate man-page output from them.
apt* utils (apt-get, apt-cache, aptitude, etc.)
bind9
Michael(tm) Smith wrote:
There is a alternative open-source DocBook-to-PDF/Postscript
option that already produces better output than FOP in many cases.
It's db2latex:
http://db2latex.sourceforge.net/
It doesn't use XSL-FO at all. Instead it translates DocBook to
LaTeX and then uses TeX to
Larry Kollar <[EMAIL PROTECTED]>, 2007-01-04 07:58 -0500:
> FO is sort of a "roach hotel" language in
> an XML sense -- once you have FO, you're not going to
> transform it to any other XML markup.
True, I guess that it's not likely that you'll be transforming it
to vocabularies other than FO. Th
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-01 12:25 -0500:
> M Bianchi <[EMAIL PROTECTED]>:
> > But that form is _so_ much easier to read and understand, especially for the
> > novice! That, to my mind, is the overriding goal of the exercise.
>
> I agree. Unfortunately, I can't fix this. I
Michael(tm) Smith <[EMAIL PROTECTED]>:
> I guess maybe you should be using the latest DocBook DTD for
> validation :)
I'm using 4.4 now. I've spent most of the last two days implementing
support for multiple namedivs and coping with the ripple effects of that
change. (I had to rewrite the nane-s
Intervening to publicise a relevant but possibly collateral piece.
It is certainly very relevant to the present discussion, but
probably it does not of itself take it forward. Nevertheless, for
those who do not already know it (as I did not until I happened
upon it by chance this morning) it is a v
Ted Harding <[EMAIL PROTECTED]>:
> Intervening to publicise a relevant but possibly collateral piece.
> It is certainly very relevant to the present discussion, but
> probably it does not of itself take it forward. Nevertheless, for
> those who do not already know it (as I did not until I happened
On 03-Jan-07 T. Kurt Bond wrote:
> Is there any way to find out the width of the most recent table?
> --
> T. Kurt Bond, [EMAIL PROTECTED]
The following should work. Indeed, it may always work!
When 'tbl' is invoked on groff code with ".TS"/".TE" blocks,
it seems that a register \n[TW] is create
Werner LEMBERG writes:
> > Is there any way to find out the width of the most recent table?
>
> Please give an example showing what you want to do.
I'd like to place something on the page relative to the right side of
the most recent table. Right now I have to manually place it using
\h'|...|'.
On 04-Jan-07 T. Kurt Bond wrote:
> Werner LEMBERG writes:
>> > Is there any way to find out the width of the most recent table?
>>
>> Please give an example showing what you want to do.
>
> I'd like to place something on the page relative to the right side of
> the most recent table. Right now I
(Ted Harding) writes:
> It's still not clear exactly what you want to do, and why you
> necessarily need to use the table-width for it. For example, in
> your case above it seems more likely that you want to tie the Note
> to the table itself, in which case you can make it part of the
> table. For
This is automatically generated email about problems in a man page for which
you appear to be responsible. If you are not the right person or list, tell
me and I will attempt to correct my database.
See http://catb.org/~esr/doclifter/problems.html for details on how and
why these patches were gen
(Ted Harding) <[EMAIL PROTECTED]> writes:
> URL:
> http://floppsie.comp.glam.ac.uk/Papers/grohtml-paper/grohtml.html
Thanks Ted,
for what it is worth there is a version 2 of the paper:
URL:
http://floppsie.comp.glam.ac.uk/Papers/grohtml-journal/grohtml.pdf
which contains a little more deta
Hi,
not sure if my previous email made it to the outside world so here it
goes again (apologies if multiple copies arrive). Basically here is a
patch for -me which allows the preprocessors: tbl, eqn, gremlin to so
something sensible with me based source files. It also fixes titles,
headings, pa
Hi Werner and Zvezdan,
here is a patch to help grohtml translate -me documents into html.
It also fixes the bug as reported by Zvezdan on the 2nd of January.
More cheating as ESR might put it :-)
It handles the preprocessors gremlin, tbl, eqn and macros for
titles, section headings, indices, ip,
Am Donnerstag, 4. Januar 2007 21:30 schrieb Gaius Mulley:
> URL:
> http://floppsie.comp.glam.ac.uk/Papers/grohtml-journal/grohtml.pdf
Interesting article Gaius.
Is it possible to get the groff source ? Looks like there is something to
learn from it.
Regards
Heinz
___
> URL:
> http://floppsie.comp.glam.ac.uk/Papers/grohtml-paper/grohtml.html
A side note:
Though not a big deal for the big web browsers, with error
correcting facilities (or many of the search engines that have
similar error correction), shouldn't all HTML entities be upper
case, and all a
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > For some uses, the generated troff code could also be edited
> > directly instead of the source document. This is what I already do
> > with my OpenDocument-to-troff converter - no sane person would want
> > to edit OpenDocument manually in order to c
"Michael(tm) Smith" <[EMAIL PROTECTED]> wrote:
> OK, I can definitely understand that. Anyway, I think if we were
> to have a set of stylesheets for converting DocBook to troff, a
> lot of the work done in putting those together could be
> "repurposed" to create a set of stylesheets for TEI and ot
D. E. Evans writes:
>
> Though not a big deal for the big web browsers, with error
> correcting facilities (or many of the search engines that have
> similar error correction), shouldn't all HTML entities be upper
> case, and all attributes be case sensitive (99% are lower case)?
No. From the HT
D. E. Evans writes:
>
> Though not a big deal for the big web browsers, with error
> correcting facilities (or many of the search engines that have
> similar error correction), shouldn't all HTML entities be upper
> case, and all attributes be case sensitive (99% are lower case)?
Am Donnerstag, den 04.01.2007, 17:58 +0900 schrieb Michael(tm) Smith:
> Related to some current discussions on the list, I wanted to
> mention a few projects I'm aware of that have authored their
> man-page documentation in DocBook and used the DocBook Project
> XSLT stylesheets to generate man-pag
> grohtml outputs elements/tags as lowercase, not uppercase as
> required by the HTML recommendations.
This is a contradiction. A `recommendation' can never be `required'.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman
> Basically here is a patch for -me which allows the preprocessors:
> tbl, eqn, gremlin to so something sensible with me based source
> files. It also fixes titles, headings, paragraphs, indented
> paragraphs, keeps, indices and a few other macros.
Applied to the CVS (with minor modifications).
> Problems with mdoc.7:
>
> 1. Unbalanced or superfluous quotes may screw up argument parsing.
These problems no longer apply to the current version of groff.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/gro
Werner LEMBERG <[EMAIL PROTECTED]>:
> These problems no longer apply to the current version of groff.
Good. I'll mark it "promised", then.
I didn't see CVS checkout instructions on the FSF page, or I'd
have pulled a copy and tested against that. Where are they?
--
http://www.c
> > These problems no longer apply to the current version of groff.
>
> Good. I'll mark it "promised", then.
Hmm. I've looked again: `mdoc.7' was never part of groff.
> I didn't see CVS checkout instructions on the FSF page, or I'd
> have pulled a copy and tested against that. Where are the
> Well
>
> http://directory.fsf.org/GNU/groff.html
> http://groff.ffii.org
>
> all have links to the source repository.
Which is here:
http://savannah.gnu.org/cvs/?group=groff
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gn
28 matches
Mail list logo