*> IIUC, you are working on a JavaScript program in the context> of some gigantic heavy-weight framework to render manual pages in> real time on a canvas while an author is editing them. Corrrect> me if i got that wrong...*
That "heavyweight framework" is simply the World Wide Web. There is (and has been for 10 years) a standardised API for procedural graphics generation, which takes care of heavy-lifting. The project itself is less complex than you'd think; it concentrates largely on bridging two powerful (but incompatible) mediums — *roff and browser-based technologies. Also, just to confirm: this isn't HTML output which is being displayed, but PNGs of PDF/PostScript output (except with clickable anchor regions, etc). *> Even if a -Tgroff output mode were written* Don't think of this as a separate format. Give mandoc(1) a -Z switch so something like this becomes possible: $ mandoc -Z -Tpdf page.1 x T ps x res 72000 1 1 x init p1 x font 5 TR f5 For HTML output, it'd obviously be implausible (or at most, unreasonable). For TTY, PDF, PostScript, it's reasonably straightforward because you've already plotted the coordinates of each letterform, determined their size/font/colour, and Kernighan's intermediate output language (shit, I'll just call it Ditroff) makes it trivial to parse this medium. *> using monstrous frameworks like electron/atom/js/whatever...* Please do some research before you write crap like this. It makes as much sense as: *> using monstrous frameworks like wscons/systemd/c++/whatever* On Mon, 17 Dec 2018 at 04:07, Ingo Schwarze <schwa...@usta.de> wrote: > Hi John, > > John Gardner wrote on Mon, Dec 17, 2018 at 02:33:25AM +1100: > > > I really do wish Mandoc would support the Troff intermediate > > output format. > > I just had a brief look again at your message "Formal AST output > in mandoc" from January 16, and the ensuing thread, to refresh my > memory. IIUC, you are working on a JavaScript program in the context > of some gigantic heavy-weight framework to render manual pages in > real time on a canvas while an author is editing them. Corrrect > me if i got that wrong... > > If groff is installed on the system, taking groff_out(5) as the > input format for your program looks like a possible choice. > > On a system where you use mandoc(1) for rendering, you should really > use the mandoc -Thtml output as your input format. Mandoc PDF > output is just not good enough for anything except casual human > viewing, in particular nor for automated postprocessing. > > Even if a -Tgroff output mode were written, it seems to me you > would still be better off using -Thtml rather than -Tgroff because > in -Tgroff, all the information about semantic functions (class > attributes in HTML parlance) would be lost. > > Even if i'm overlooking something and -Tgroff would be better for > your particular purpose (if so, why?), and even if you were to > write the -Tgroff output mode, i would hesitate to include it; it > seems too much of a niche application to warrant the resulting > maintenance effort: i fail to imagine any other use case > where -Tgroff might help... > > > Even if processing text piped between programs isn't nearly as > > efficient as reading it from a compiled program, it's so much > > more flexible. > > I'm not sure i get the point here. You certainly don't want to > compile the mandoc parser and directly link your program to it > because the syntax tree structs are not stable, but constantly > evolving. Besides, pipes do seem quite efficient to me - you aren't > really worried about the copyin/copyout overhead in the kernel, or > are you? Can't really believe that's what you are trying to say > while on the other hand you are using monstrous frameworks like > electron/atom/js/whatever... > > So to me, the question doesn't seem to be efficiency of pipes vs. > direct memory access, but rather which communication format to use: > HTML, UTF-8 text, PostScript in order of decreasing mandoc output > quality, and -Tgroff only if there are strong arguments that i > haven't heard or understood yet. > > Yours, > Ingo >
