> > It's not clear to me why you get such bad formatting results.
>
> Partly because it's difficult to strip away the non wiki content
> from the web page (navigation bar, advertisement on the corner,
> "feed back" input textarea);
??? Those visual elements aren't part of the wiki text itself,
AFAIK. How can they disturb? But maybe I'm misunderstanding.
> Partly because there is no way to specify when this gets printed,
> how the page header, footer look like. e.g. it's not possible to
> have a front page with only title of document and author, date,
> centered in the page. I have to copy content from wiki into
> OpenOffice and format it there.
Well, the wiki has to provide proper hooks, providing these things
automatically.
> The convention I used "tikiwiki" only have a few "syntax" for
> different formats, I think less than a dozen. Compare to what ms
> package offers, it was just too few.
I think we are miscommunicating. Let's assume this wiki text:
== header text ==
body text
This might be converted by to groff like this:
.NH 2
header text
.PP
body text
Where's the problem? A proper wiki2troff converter should do this
easily (ideally implemented as a part of the wiki engine).
> However there is a strong need of using wiki for project document
> because in an agile development process the software document can be
> changed anytime by anyone. and frequently a well formated version
> is needed for print-output for commercial releases. Can we have
> roff's richness in formatting and layout text on paper, providing
> high quality print output for the product delivery, while provide
> high flexibility and co-operation of wiki, without forcing document
> writers (often not developers) to use a version control software and
> collaborate by committing instead of just work on the web pages?
Of course. Just provide a wiki2troff script. However, I can't
believe that tikiwiki hasn't something similar, probably directly
creating PS output (or converting to TeX).
> I know right-to-left language is not supported. Chinese neither, for
> the line-break issue. By the way, why being old is a reason to
> being in-active for new feature requirements (e.g. right-to-left)?
At the time of writing groff the author hasn't thought of supporting
those scripts. It's difficult to extend the internal structures
without rewriting it completely. I lack time to do even the simplest
things with groff currently, and no other people work on those groff
internals actively.
Werner
