[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] Work-related rants
Re: [groff] Work-related rants
Mon, 17 Dec 2018 05:06:05 +1100
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
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 font 5 TR
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
*> using monstrous frameworks like wscons/systemd/c++/whatever*
On Mon, 17 Dec 2018 at 04:07, Ingo Schwarze <address@hidden> 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
> 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
> 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.