James K. Lowden <jklow...@schemamania.org>:
> Hmm, seems to me every document is presentation-centric, depending on
> what that means. Are you suggesting Postscript and PDF are not long
> for this world? Are we doomed to the eyesores produced by
> lousy-browser ebook readers?
Oh, no. I think Postscript/PDF have a *long* future ahead of them.
What I don't believe is that there will ever again be enough demand for
printer-*only* output to justify markup formats and toolchains that don't
also do web and ePub or functional equivalent.
I lean heavily on asciidoc these days. It's been years since I wrote
anything in [nt]roff; instead, if that's needed, I use a stylesheet to
make [nt]roff from asciidoc.
Bear in mind that I've been pretty good at [nt]roff since around 1982 and
a groff contributor since...um, 1992 or thereabouts? So it's not like I
don't know the [nt]roff model intimately. I do, and I think it's headed the
way of the quill pen and the slate, and I won't miss it much when it goes.
I have better tools now; troff is just another intermediate output format.
I'd miss pic, though. I like pic. I'd like to decouple pic from troff
and save it. That would take some redesign near font specifications.
> > The one thing I thing we could usefully salvage from the groff model
> > is the notion of stacked DSLs for special formatting tasks - pic, eqn,
> > grap, chem and the like.
>
> Yes, yes! Say it, bother! Rebarbative it may be, but at least troff
> syntax was intended human beings to use.
Sorry, I think asciidoc syntax beats the crap out of troff syntax along
every axis, including usability. Time passes. Progress gets made.
> Nothing stands in the way of another post-processor, groxslfo, right?
No, but it's unnecessary work. I think the energy would be better
spent making fop work and making every former groff preprocessor speak
XSL-FO. And making stylesheets that really sing. And native UTF-8
all the way through.
> I wonder what presentation-centric -- I think you mean "paper-centric"
> -- features troff is beholden to. What is different about nonpaper
> devices, that prevents troff by design from producing documents for
> them?
Oh, Goddess. Page one, chapter one...go take a long look at doclifter.
Contemplate the huge baroque baby AI I had to write to extract decent
structure from troff markups. Those "page-centric" assumptions go way
deeper and cause way more problems than you realize. I speak with
authority here, having been the guy who *solved* this problem after
the XML-Docbook crowd told me it was impossible.
They were wrong, but they weren't far from being right.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
