"Eric S. Raymond" <[email protected]> wrote (Tue, 4 Feb 2014 23:08:02 -0500): > James K. Lowden <[email protected]>: > > 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.
Found http://asciidoc.org/article.pdf that shows the Table of Contents shifted to the right and I'm glad that in using groff I can get ride of such artifacts (yet). They would otherwise being addressed to be my faulty use of software. > > 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.
