Follow-up Comment #21, bug #64360 (project groff):
[comment #17 comment #17:]
> Where we deviate from CSTR #54, *we say so*.
A fair point, but it only addresses my second clause about CSTR #54. The more
relevant question is, do we claim CSTR #54 as a specification for groff, aside
from such noted deviations? (Maybe we do; you know the groff docs better than
I do.) Because if groff's _own_ docs don't address this whitespace in grout,
and groff code in its history has never placed whitespace here, one could
argue this constitutes an API change within the groff ecosystem.
For the record, I'm not making an argument about this either way, just trying
to see it from multiple sides.
> I think our output drivers should behave consistently,
True, and they do behave consistently given the grout that groff has produced
to date. My reference to Postel's law was intended to point out that libgroff
being coded to liberally accept "grout" from other troffs (generically,
"rout"?) doesn't necessarily indicate an intention on groff's part to support
_producing_ such grout.
> and if someone were to convert PostScript generated by _grops_
> to PDF and PDF generated by _gropdf_ to PostScript, one should
> not be able to tell which output driver originally produced the
> document (ignoring comments within the files announcing the fact).
I agree with that, but I'm not sure I follow your logic, as the above seems to
be about the _output_ of the two postprocessors, whereas the API question is
about their _input_.
Anyway, this debate is academic: ultimately, I favor making grout more usable
by other tools (and more readable to humans), and whitespace is important for
that, regardless of whether one characterizes it as an API change.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64360>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
