Re: [Groff] doclifter on groffer.man

[Gunnar Ritter]

address@hidden wrote:

> > Von: address@hidden
>
> > There has never been any IETF RFP, nor ANSI/ISO/W3C committee work.
> > Thus, there is no de jure standard here, only a de facto one.
>
> It is the GNU standard, so it is the standard in the world of free software.
> We spit on all commercial standards.  We use them to extend them to useful
> additions.

This is complete nonsense. The mentioned organizations are
not commercial, and GNU people are participating actively
in developing their standards. Moreover, much free software
is developed by commercial employees these days; I would not
be surprised to find ECMA standards developed by GNU persons
as well. If you are looking for an anti-capitalist platform,
you are clearly wrong with the GNU project.

Statements like yours are usually coming from ideological
followers of the GNU project, not from GNU developers. I
am under the impression that all you want is to defend
your macros just because they are yours, and resort to
non-technical bullshit since you are lacking technical
arguments.

> The stuff for blind people can be done within HTML.  So `grohtml' can be
> fixed in order to do this.  But apart from that `grohtml' can translate  all
> `groff' input into HTML without any flames, so `doclifter' should be able to
> do that as well because XML is an extension compared to HTML.  You could
> learn from `grohtml', it is free.

"XML is an extension compared to HTML" - are you really
that clueless? XML is a syntactic framework for languages
with very different semantics; many of them do not even
have anything to do with text layout. For those that do,
there are structural markup languages like DocBook-XML,
visual markup languages like XSL-FO or OpenDocument,
and page description languages like Microsoft's XML Paper.

While it would be completely natural to let a troff
postprocessor output XML Paper in case it prevails,
generating OpenDocument already makes less sense since
it throws away the H&J work which is at the heart of
troff. Still, it would be possible, since the layout
information in troff input documents is comparable to
that in OpenDocument files.

But generating DocBook from troff input is impossible
in the general case since troff knows nothing about the
document structure around which DocBook is centered,
and since there is no other way to represent much of
the information in troff input in DocBook.

It has been tried to explain this multiple times now;
perhaps you could really read up on the subject before
you continue to participate in this discussion?

> > The way this discussion has been going,
> > if you do maintain that position you are likely to find yourself in a
> > minority of one.
>
> When the slime is replaced back to reason more will come.

Even if crowds of uninformed people demanded to convert
generic troff input to DocBook, it would still be impossible
to write a tool for that. They would have to do it by hand.

        Gunnar