Re: [Groff] The future redux

[hohe72]

Tadziu Hoffmann <address@hidden> wrote (Wed, 26 Feb 2014
23:06:17 +0100):
> 
> > Three browsers, three layouts (surf uses webkit).
> 
> Hmmm, well, I suspect if you used groff with -Tlatin1, -Tlj4,
> -Tdvi, and -Tps you might also get four different layouts...
> Simply consider different browsers like different devices.
> 
> 
> > Firefox's is perfect!
> 
> It's better than the others, but I wouldn't call it perfect

I just checked firefox as a last resort. There the html output looks
better compared to the Groff-generated post script one. As for quality,
it fits into a html environment. Most importantly, it's not ambiguous!
(or confusing).

Just sad, that from point of view of the author, he cannot control the
layout. So, I would deal with the ignored .br-request, but having litte
options to fix the braces.

This touches the principle of separation of presentation and data.
Often, not only for software, someone is responsible for the overall
outcome of a "goal", and need the power to archive it. The
encapsulation principle, AFAIK, then should aim to a structure enabling
the control of the device/ program and hence should violate the layered
principle of separation at least partially.

And at this point, based on my education, I think software development
hasn't matured much. I also wonder, why compatibility to old APIs is an
issue. IBM still develops and sells the IBM System i, what is based in
the year ~1979. The problem (scalable, extensible) is old and well
known. Why is here no "principle"?

So for instance, the naming .de1 doesn't make sense for the next great
overhaul of Groff. You wanna count up? (That was just a suggestion, I
know.) Heirloom should have named its extensions with a prefix hl_*, I
think.

> (but obviously that's a matter of taste).  For example,
> numerator and denominator of fractions should in my opinion
> use the regular font size (except in inline equations, where
> you don't want extra line space).  TeX usually does it nicer.

OpenOffice's is also not bad. It is also superior at the markup language
-- and the GUI wrecks it all =).

  Holger