> Maybe you will be interested by the quick set of macros I wrote for
> typesetting right-to-left with the -mm macros:
>
>http://baruchel.free.fr/~thomas/code/rtlgroff.pdf
Very nice! Can you provide a package which contains the source code
of the document also?
Werner
___
On 03/01/2007, at 9:18 AM, Clarke Echols wrote:
It is important to minimize clutter at the start of the page.
and later on :-)
the old AT&T page which combined them with a NAME line:
cp, mv, ln \- copy, link, or move files
Yeah, we had the same thing on our then top-of-the-world SGI syst
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-01 11:32 -0500:
> I'm talking about name sections like this:
>
> NAME
>bzip2, bunzip2 - a block-sorting file compressor, v1.0.3
>bzcat - decompresses files to stdout
>bzip2recover - recovers data from damaged bzip2 files
>
>
Dear Werner,
On Mon, 1 Jan 2007, Werner LEMBERG wrote:
Are you interested in font descriptions for URW fonts?
As mentioned in an earlier thread, I won't integrate it into groff
directly. Instead, I ask you to create an add-on package for them.
The same should be done for the Adobe core fonts
Ralph Corderoy <[EMAIL PROTECTED]>, 2006-12-31 12:42 +:
> For those of us that think browsers are a poor way to read documentation
> like man pages, e.g. poor searching, no remembering the scroll-bar
> position, etc., presumably there will be a way we can keep the old
> behaviour on a per-user
On 03-Jan-07 Michael(tm) Smith wrote:
> Ralph Corderoy <[EMAIL PROTECTED]>, 2006-12-31 12:42 +:
>
>> For those of us that think browsers are a poor way to read
>> documentation like man pages, e.g. poor searching, no remembering
>> the scroll-bar position, etc., presumably there will be a way
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-28 09:15 -0500:
> There's a bit of a problem 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.
They do now. I finished adding table support to
[apologies for re-posting; wanted to change the subject line to
match the actual subject of the message]
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-28 09:15 -0500:
> There's a bit of a problem in the other direction, unfortunately.
> Norm Walsh's XML-DocBook stylesheets have a man-markup outp
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-28 18:07 -0500:
> In translating to DocBook, these indented displays would be
> rendered with various nestings of and
> tags. I don't presently do this, because I don't presently notice
> whether .DS has an indent argument or not -- but if .DS wit
Ted Harding <[EMAIL PROTECTED]>, 2006-12-23 00:48 -:
> Therefore my case for groff would not rest on man-pages. Indeed,
> if groff were superseded by something else for man-pages I would
> maintain that this would not diminsh the usefulness of groff,
> nor the necessity to keep it going.
>
>
Michael(tm) Smith <[EMAIL PROTECTED]>:
> That was true prior to DocBook 4.3, but it's not true currently
> (neither in DocBook 4 nor DocBook 5).
Oh, good. I shall add support for this immediately and get rid of a large
number of warnings and fix patches. Thanks for the heads-up,
> The current
Michael(tm) Smith <[EMAIL PROTECTED]>:
> They do now. I finished adding table support to the DocBook
> Project manpages stylesheet in March of last year -- for release
> 1.69.1 or so of the stylesheets. (The current release that distros
> should be packaging is 1.71.1).
Great, I can get rid of an
Michael(tm) Smith <[EMAIL PROTECTED]>:
> I think doing that would be an abuse of . I hope
> doclifter isn't currently using that way in other
> places. It's not supposed to be a means to indent things. A
> particular processing application may or or may not render it with
> an indent. It would be
Werner LEMBERG <[EMAIL PROTECTED]>, 2006-12-23 15:26 +0100:
> 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?
If you mean Postscript/PDF output:
Zvezdan Petkovic <[EMAIL PROTECTED]>, 2006-12-23 15:06 -0500:
> I would classify myself as "skilled hands" too and 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
(Ted Harding) <[EMAIL PROTECTED]> wrote:
> On 03-Jan-07 Michael(tm) Smith wrote:
> > You could use a console/curses-based browser, right? lynx or
> > elinks or w3m. I'd think paging through a man page with one of
> > those would be much the same as you have with less(1) now. Except,
> > for one th
Gunnar Ritter <[EMAIL PROTECTED]>:
> That said, most HTML manual pages I have seen so far look ugly
> just because their visual layout is inferior to that of -man,
> e.g. regarding indenting, but this is fixable.
One of my to-do items is to compose a good stylesheet for HTML
generated from doclift
> Delta, Omega, mu are to be mapped to greek letters or to symbols (in
> not-symbol fonts)?
I favour `*D', `*W', and `*m' to be symbols, using `u03XX' for glyphs
intended to write Greek.
> What about character composition (CC lines in AFM). Are you going
> to implement it or not?
Definitely no
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-03 07:17 -0500:
> Michael(tm) Smith <[EMAIL PROTECTED]>:
> > That was true prior to DocBook 4.3, but it's not true currently
> > (neither in DocBook 4 nor DocBook 5).
>
> Oh, good. I shall add support for this immediately and get rid of a large
> n
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-03 07:28 -0500:
> 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?
Nope. I think the case of .RS/.RE exposes the basic problem of
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-23 18:01 -0500:
> FOP is at 0.92 level now.
I'm not sure that should be seen as a sign of stability. Certainly
it shouldn't be seen as sign that it's anywhere close to being
compliant with the XSL-FO 1.0 spec (it isn't). And anyway, the
release previ
Peter Schaffter <[EMAIL PROTECTED]>, 2006-12-23 12:12 -0500:
> I don't see any problem with the proposal of DocBook XML as the
> source from which manpages are actually rendered--provided
> engines exist to render XML manpages *at the terminal* as well
> as groff does.
If you mean to render man p
M Bianchi <[EMAIL PROTECTED]>, 2006-12-22 20:00 -0500:
> The value of man pages is not the markup language.
> The value is (when done right):
>
> structured, standardized presentation
> NAME, SYNOPSIS, DESCRIPTION, OPTIONS, SEE ALSO, BUGS
>
> standardized nomenclature
>
Michael(tm) Smith <[EMAIL PROTECTED]>:
> The only way for doclifter to generate proper markup for .RS/.RE
> instances like that would be be for it to figure out what semantic
> meaning the author intended for that indented block to have. Is it
> a program listing, an example, or what? It sound like
M Bianchi <[EMAIL PROTECTED]>, 2006-12-22 20:00 -0500:
> I believe that if the effort was done properly, then the content could be
> mechanically translated into any of the formats, including long, flat text
> files. man -> docBook would imply docBook -> man
As mentioned in recent discussion h
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.org/~esr/";>Eric S. Raymond
_
Michael(tm) Smith <[EMAIL PROTECTED]>:
> I think we could have a system in which man pages were stored on
> local systems simply as HTML (which could be HTML originally
> generated from DocBook or generated by some other means or even
> just authored directly in HTML), and "man " would just
> cause
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-03 11:28 -0500:
> 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 do
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-23 00:56 -0500:
> Well, no, actually. DocBook -> man is easy -- you're throwing away
> structure when you do that. man -> DocBook is *hard*, because you have
> to deduce semantic structure from presentation-level cliches.
DocBook -> man may be e
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-24 13:01 -0500:
> Gunnar Ritter <[EMAIL PROTECTED]>:
> > But I think the most important question for troff people is,
> > where is a complete, high-quality converter for
> >
> >+-+/ +===+
> >| XML-Doc
Gunnar Ritter <[EMAIL PROTECTED]>, 2006-12-25 21:17 +0100:
> Real *roff is hardly the problem since it has supported the
> two-character requests (except .do) for more than thirty years
> now. The issues are with scripts that convert manual pages or
> build indexes for them or whatever. I would sa
> > 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?
>
> If you mean Postscript/PDF output:
>
> Unicode Explained (Jukka K. Korpela)
> htt
M Bianchi <[EMAIL PROTECTED]>, 2006-12-23 08:26 -0500:
> I encourage the flat text format because sometimes things like X fail and
> you
> want access to the documents without requiring the fancy programs work and a
> flat-file editor is all you have.
>
> +-+
"Michael(tm) Smith" <[EMAIL PROTECTED]> wrote:
> "Eric S. Raymond" <[EMAIL PROTECTED]>, 2006-12-24 13:01 -0500:
> > XSL-FO to troff would be far more appropriate. XSL and troff are at about
> > the same level; thus, you wouldn't have to wire in all the policy/styling
> > decisions you would in a
Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-03 17:59 +0100:
> Well, yes, but I wonder how much hand-editing has been done?
I don't know actually. I think not terribly much, because if the
XSL-FO toolchain had required an unreasonable amount of
hand-editing, they would not have used it for all the
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
___
Groff
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-01-03 12:48 -0500:
> 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.
I'm starting to wonder if you read the docs
"Michael(tm) Smith" <[EMAIL PROTECTED]>, 2007-01-04 02:51 +0900:
> 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/
Actually, it's this:
http://dblatex.sour
Michael(tm) Smith <[EMAIL PROTECTED]>:
> > There is a tag. I don't know wha the stylesheets
> > do with it.
>
> I'm starting to wonder if you read the docs :) The purpose of the
> element is documented here:
>
> http://docbook.org/tdg/en/html/beginpage.html
>
> "The break identified by Beg
Gunnar Ritter <[EMAIL PROTECTED]>, 2007-01-03 18:30 +0100:
> The other side is that it is much easier to convert DocBook
> to troff directly.
True. And people familiar with LaTex and ConTeXt find it much
easier to convert DocBook to those formats directly. It makes
great sense if DocBook is the o
Is there any way to find out the width of the most recent table?
--
T. Kurt Bond, [EMAIL PROTECTED]
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
"Michael(tm) Smith" <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter <[EMAIL PROTECTED]>, 2007-01-03 18:30 +0100:
> > The other side is that it is much easier to convert DocBook
> > to troff directly.
> True. And people familiar with LaTex and ConTeXt find it much
> easier to convert DocBook to those fo
> Is there any way to find out the width of the most recent table?
Please give an example showing what you want to do.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> [...] I am certain that LaTeX allows you a lot tighter control over
> such things than an XML/XSL-FO toolchain ever will. I guess loss of
> that control over presentational fine-tuning is one of the
> trade-offs that comes with having a system-independent means of
> marking up content semantica
> As a troff user, my preference would actually be to have a
> collection of XSLT stylesheets, one for each of the supported XML
> input languages, and to have a common troff macro set to which all
> of these are transformed.
This sounds good.
> For doing anything which is not representable in t
Gunnar Ritter <[EMAIL PROTECTED]>, 2007-01-03 19:55 +0100:
> As a troff user, my preference would actually be to have
> a collection of XSLT stylesheets, one for each of the
> supported XML input languages, and to have a common troff
> macro set to which all of these are transformed. This is
> bec
Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-04 07:52 +0100:
> What I imagine is to conditionally tag the
> input for a certain output `device' (be it LaTeX, troff, or whatever).
> Such tags are ignored if the document is converted to a different
> device. The more such data is in the original inp
47 matches
Mail list logo
