[bug #64360] [gropdf] does not correctly handle white space after 'w' command

[G. Branden Robinson]

Follow-up Comment #17, bug #64360 (project groff):


[comment #16 comment #16:]
> [comment #15 comment #15:]
> > I strongly object to your characterization of this as a
> > proposed API change.  It is not.  It honors the letter and
> > spirit of CSTR #54,
> 
> If the layout of groff's output language hasn't changed in 30+ years,
there's arguably a de facto API separate from the published one.  For that
matter, groff didn't publish CSTR #54 and deviates from it in various ways. 
So whether it is or isn't an API change may depend on which angle you're
looking at it from.

Where we deviate from CSTR #54, *we say so*.  (And we don't, very much.  More
often, we document errata in it.)

> > and groff's other output drivers are not tripped up by the change,
> 
> A good dose of Postel's law is often advisable.

I think this ticket is entirely in the same spirit as bug #63757, bug #62950,
bug #62934, bug #62923, bug #62346, bug #62294, bug #61908, and bug #51568,
all of which contrasted _gropdf_'s behavior with _grops_ (or, in one case,
could have done).

I think our output drivers should behave consistently, 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 am baffled as to why achieving parity and consistency in this respect is
being tarred with the "API change" brush.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64360>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/