Re: [groff] Work-related rants

[John Gardner]

*> 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 <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
> 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
>