Hi,
Back on 2006-12-31 Eric S. Raymond wrote:
> Ralph Corderoy <[EMAIL PROTECTED]>:
> > Will /usr/share/man still have roff man pages as well as the HTML
> > conversion?
>
> Probably. But is likely that man will at some point start presenting
> through the browser by default if you have a BROWS
On Friday 05 January 2007 22:47, D. E. Evans wrote:
>But xhtml-1.0+ *requires* that tags be represented in *lower*
>case *only*, and any mixed or upper case representation is
>(strictly) invalid. AIUI, today's web authors really should be
>striving towards xhtml standards complianc
Heinz-Jürgen Oertel <[EMAIL PROTECTED]> writes:
> 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
But xhtml-1.0+ *requires* that tags be represented in *lower*
case *only*, and any mixed or upper case representation is
(strictly) invalid. AIUI, today's web authors really should be
striving towards xhtml standards compliance; in this respect,
grohtml's use of lower case is alread
On Friday 05 January 2007 15:25, Clarke Echols wrote:
> > > grohtml outputs elements/tags as lowercase, not uppercase as
> > > required by the HTML recommendations.
> >
> > This is a contradiction. A `recommendation' can never be `required'.
> >
> > I'll stick with requirement. Otherwise
D. E. Evans wrote:
> grohtml outputs elements/tags as lowercase, not uppercase as
> required by the HTML recommendations.
This is a contradiction. A `recommendation' can never be `required'.
I'll stick with requirement. Otherwise, what's the point of a
standard?
How about "...as
Read it again -- the spec itself uses upper- and lowercase for
readability, but HTML is case insensitive so , ,
, and are all equally valid.
I am corrected. Thank you.
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinf
> grohtml outputs elements/tags as lowercase, not uppercase as
> required by the HTML recommendations.
This is a contradiction. A `recommendation' can never be `required'.
I'll stick with requirement. Otherwise, what's the point of a
standard?
D. E. Evans writes [quoting me]:
>
>No. From the HTML 4.01 spec:
>
> Element names are written in uppercase letters (e.g., BODY).
> Attribute names are written in lowercase letters (e.g., lang,
> onsubmit). Recall that in HTML, element and attribute names are
> case-
> 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
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)?
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
"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
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
> 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
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
___
(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
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
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
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
> 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
"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
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
"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
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.
>
> +-+
"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
"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
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
>
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
(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
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
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
Gunnar Ritter <[EMAIL PROTECTED]>:
> > Probably. But is likely that man will at some point start presenting
> > through the browser by default if you have a BROWSER variable defined.
>
> For those who do not like that, I will definitively keep
> the Heirloom Toolchest "man" command to prefer nrof
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Ralph Corderoy <[EMAIL PROTECTED]>:
> > Will /usr/share/man still have roff man pages as well as the HTML
> > conversion?
>
> Probably. But is likely that man will at some point start presenting
> through the browser by default if you have a BROWSER
Ralph Corderoy <[EMAIL PROTECTED]>:
> Will /usr/share/man still have roff man pages as well as the HTML
> conversion?
Probably. But is likely that man will at some point start presenting
through the browser by default if you have a BROWSER variable defined.
--
http://www.catb.org
Hi Eric,
> My vision is that all the legacy help browsers become ways to point
> your browser at subtrees of the HTML on your system. /usr/share/man
> and /usr/share/info would be the most important HTML subtrees, but
> there could be others, including project-specific others.
A bit off-topic..
Zvezdan Petkovic <[EMAIL PROTECTED]>:
> If -mdoc was refused for the above reason, how accepted DocBook will be?
I'm not sure how much that matters. Nothing stops you from composing
in asciidoc or whatever; the whole conversion from composition format
to DocBook could take place out of your sight
On Wed, Dec 27, 2006 at 06:52:13AM -0500, Eric S. Raymond wrote:
> I don't think your citation of -mdoc is really on point. IMO, the
> reason it hasn't gained acceptance is that, while -mdoc markup is
> cleverly designed, it is also quite complex -- more heavyweight than
> most man-page writers wa
Werner LEMBERG <[EMAIL PROTECTED]>:
> Similar to evaluation, I would like to have some guide lines how to
> use \w -- there are examples where this escape greatly improves the
> layout in a generic way. Ideally, those are encapsulated in proper
> man macros, but...
I will investigate and report.
> Safe escapes:
> \' \- \$ \* \& \ \
> \c \d \e \f \u \n
A follow-up: This is only a small fraction of the escapes! Examples
for missing ones are \\, \e, or \~. Perhaps it's easier to tell us
which (besides \w) are problematic.
Werner
> Safe escapes:
> \' \- \$ \* \& \ \
> \c \d \e \f \u \n
>
> Note that \w is *not* safe.
Hmm.
> In general, we can't count on the viewer to be able to render
> horizontal or vertical motions with precision, we can't count on it
> to know font sizes, and we can't even count on it to
Gunnar Ritter <[EMAIL PROTECTED]>:
> > In general I might agree with you. However, .EX/.EE and .DS/.DE
> > have a couple of interesting properties:
> >
> > 1. They are, by far, the most commonly invoked man macros that don't
> > exist. :-) That is, significant numbers of man-page writers think t
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> In general I might agree with you. However, .EX/.EE and .DS/.DE
> have a couple of interesting properties:
>
> 1. They are, by far, the most commonly invoked man macros that don't
> exist. :-) That is, significant numbers of man-page writers think
Gunnar Ritter <[EMAIL PROTECTED]>:
> I doubt it is useful at all. It is perfectly okay to use
> statements outside the "safe" set if they do not do harm
> when a viewer just discards them.
I think you just widened the meaning of "safe". :-).
> > On a related topic, there are a couple of man macro
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Werner LEMBERG <[EMAIL PROTECTED]>:
> > > I think it might not be a bad idea for troff to throw warnings when
> > > a man page uses a troff request outside the safe set. Note that I
> > > am *not* recommending this measure for troff documents other
Werner LEMBERG <[EMAIL PROTECTED]>:
> > I think it might not be a bad idea for troff to throw warnings when
> > a man page uses a troff request outside the safe set. Note that I
> > am *not* recommending this measure for troff documents other than
> > man pages.
>
> Hmm. This is doable by rede
> Having grappled with troff markup weirdness on 13,000 pages, and
> written an interpreter for a a substantial part of troff within
> doclifter, one of the things I am well equipped by experience to do
> is describe a "safe troff" subset that we should recommend man-page
> writers adhere to.
Ver
mhobgood <[EMAIL PROTECTED]>:
> For those of us not up to speed on all the current jargon, would you
> explain what XSL and FO are?
http://www.w3.org/TR/2001/REC-xsl-20011015/
You can think of it as a sort of XML-world equivalent of TeX or
PostScript. The idea is that XML applications needing
On Dec 24, 2006, at 12:01 PM, Eric S. Raymond wrote:
Gunnar Ritter <[EMAIL PROTECTED]>:
But I think the most important question for troff people is,
where is a complete, high-quality converter for
+-+/ +===+
| XML-DocBook |===>| troff |
Gunnar Ritter <[EMAIL PROTECTED]>:
> But I think the most important question for troff people is,
> where is a complete, high-quality converter for
>
>+-+/ +===+
>| XML-DocBook |===>| troff | ?
>+-+\ +
Gunnar Ritter <[EMAIL PROTECTED]>:
> > Well, does this mean that I should refrain from using any GNU
> > extensions in man pages?
>
> Yes, I recommend that. As you know, I like most of them and
> have re-implemented them accordingly in Heirloom troff, so
> this is not an argument against groff ext
M Bianchi <[EMAIL PROTECTED]> wrote:
> +-+ ++
> | man pages |-+ +--->| HTML on browsers |
> +-+ | / ++
> |
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > > 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 exi
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
__
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
> 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
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
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.
-
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
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 world
> > is simple: are we willing to accept that it's
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 world
> is simple: are we willing to accept that it's a legacy rather than
> a primary format
68 matches
Mail list logo
