Follow-up Comment #33, bug #64360 (project groff):
Hi Deri,
[comment #32 comment #32:]
> Again a long reply will be required since you've again extended the scope
bringing in heirloom, dwb, libdriver. whereas i tried to limit the scope to
examine whether gropdfs grout parser was cnformant to our current docs. You
may consider our current documentation inadequate, i have no issue with it,
and if you alter it and libdriver
You may have missed this island in my ocean of text:
> > Fortunately, I see no need to alter libdriver in any way
And this remains the case, despite my findings in comment #30.
> to do what you want, then gropdf will no longer be conformant, because you
have changed the api it relied omn.
I am telling you that _gropdf_ is not behaving congruently with _grops_
*today*. I don't need to change anything to make that statement true. I
mention _libdriver_ only because that is factually where the _troff_ output
parser for all of _groff_'s other output drivers lives.
I checked the behavior of Heirloom and DWB only to see if they might shed any
light on interpretations of CSTR #54. If you're like me, you can treat them
as suggestive but not dispositive, particularly given their bad behavior as
shown in comment #30.
So what remains is this:
> i tried to limit the scope to examine whether gropdfs grout parser was
cnformant to our current docs. You may consider our current documentation
inadequate, i have no issue with it,
Then you should be able to resolve the dilemma I raised in comment #29--a
dilemma which arose from two competing claims of the current documentation,
which I therefore do not regard as sufficient to characterize an API.
> > does a command with one fixed-length argument get followed by a line break
or not?
If it does, then this _groff_ 1.23.0 (or 1.22.4) output demands explanation.
$ printf '\\o@abc@\n' | groff -Tascii -Z | sed -n '12p'
cacbccH24
If it doesn't, then this sentence from our docs demands explanation.
> > > in 'gtroff''s intermediate output, every command with
> > > at least one argument is followed by a line break,
If you can tell me how the foregoing facts are not in tension, I'd appreciate
hearing it. If you cannot, then I submit to you that you are putting too much
stock in our documentation, and that the implementation of _libdriver_, which
has seen little change since 2006, should be given more weight.
> Im afraikd it will be sometime before i can give f ull reply, computer gone
kaput,
That sucks. I'm sorry to hear it. :(
> new one built (son under guidance), but teething issues so not quite
customised yet. hand typing so evben slower than noprmal. :-(
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64360>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
