bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #64360] [PATCH] [gropdf] does not correctly handle white space afte


From: G. Branden Robinson
Subject: [bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command
Date: Tue, 15 Aug 2023 09:50:57 -0400 (EDT)

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]