Follow-up Comment #31, bug #64484 (group groff): [comment #30 comment #30:] > At 2024-11-16T12:22:25-0500, Deri James wrote: >> Follow-up Comment #29, bug #64484 (group groff): >> >> Branden leans towards rejecting things even though the users intention >> is clear. For groff there are no spaces, only horizontal movements, > > I reject this claim as false. > > It is rebuttable in at least 3 respects:
Hi Branden,
It is a bit odd that you rebut my claim "For groff there are no spaces, only
horizontal movements" by showing that the statement is in fact correct!
> 1. the formatter's input language;
> 2. the formatter's internal representation form ("nodes"); and
> 3. the formatter's output page description language.
>
[...]
>
>> so should the bookmark "Chapter 1" be rejected because it does contain
>> a horizontal movement!
>
> I'd warn about it, at least.
So, to be clear, if a user entered:-
.pdfbookmark 1 "Chapter 1"
You would warn about the space being a horizontal movement. What about "Lake
Attica’s Shores", would that receive two warnings?
>> Elsewhere, in terminal output, space and \0 both result in a one
>> character cell space.
>
> As you know well, there are output devices that are not terminals.
A user may expect input destined for a bookmark to be processed similarly to
how groff outputs to a terminal, i.e. \0 is delivered as a space.
>> I am sure the user would expect the same when outputting text to a
>> bookmark.
>
> Users expect their desires to be perfectly enacted no matter what the
> quality of the input they give the system. There are limits to how well
> we can accommodate such expectations, particularly when two different
> users have differerent, but defensible, ones from the same inputs.
I am afraid I can't imagine another expectation other than \0 will result in
a space in the text, it is unlikely the expectation would be that it is simply
ignored.
[...]
>> Using HEAD & .output
>>
>> x X ps:exec [/Dest /pdf:bm1 /Title (Ph: 01632\0\&444666) /Level 1 /OUT
>> pdfmark
>>
>> The only one which "works" is the final one, i.e. produces what the
>> author would reasonably expect - a space within the phone number - for
>> both the text and the bookmark.
>
> It looks to me like you've added a feature (I assume this is gropdf) to
> interpret a bespoke selection of *roff input escape sequences within
> certain device extension commands tagged "ps:exec".
You have been aware of this for a long time, since, when we discussed this,
well before you embarked on your "death march" (as you call it), and I told
you that I wanted you to pass through text "as is" (if valid), your advice was
that I should not need to do that and you planned some looping construct.
Which never appeared.
> Where is this behavior documented? Should *roff users in general expect
> output drivers to implement *roff language interpreters, in whole or
> part?
Previous pdf.tmac used .asciify so this prevented unicode bookmarks, it is
documented that these are now accepted, which entails parsing strings passed
to gropdf.
>> Worryingly .device in HEAD manages to convert \0 to just "0"
>> which does seem wrong.
>
> Yes, that does seem odd and is worth investigating. Probably the dummy
> character should be silently discarded too. And thus likely some other
> things, like `\)`. Argh. This is the "switch out of copy mode back
> into interpretation mode, or some kind of 'mode 3'" death march you
> counseled me not to waste my time with, characterizing it as a
> self-imposed goal that would only delay the release. I believe the
> implication was that no one else would care about it.
>
> Well, on the bright(?) side, the release might be delayed for a while
> anyway, given that I have some documentation to write and, in your
> assessment, a low order of intellect with which to compose it.
>
> https://lists.gnu.org/archive/html/groff/2024-11/msg00131.html
I don't think I have ever cast aspersions about your ability to document
groff, so I have no doubt you would make a great job replacing pdfmark.ms,
combining stuff from gropdf.1 and comments in pdf.tmac. In fact I know you are
so thorough it is likely you are likely to find plenty of bugs around the
seldom used edges of pdf.tmac.
The message you reference does not question your intellect. On a number of
occasions you have stated you found the coding style of pdfmark.tmac/pdf.tmac
opaque and difficult to navigate. I sympathise - it is - it took me awhile to
fully understand Keiths code, but I do admire it. Any criticism in that post
is not aimed at your intellect, rather it is a disappointment you fired off
about 16 commits to pdf.tmac just after I went on sabbatical, so no
discussion, to pdf.tmac, a file which you said you had difficulty with, which
resulted in bugs being introduced.
The fault is not a lack of intellect, if there is one, it may be in over
confidence in changing a file which you claimed to not fully understand.
>> There have always been differences between \X and .device but after
>> Branden's extensive changes in this area I'm not sure our
>> documentation has caught up, since it appears to now say there is no
>> difference,
>
> Where does it say that?
I read the entry in groff.pdf too fast, missed the fact that later paragraphs
only applied to \X.
>> commit 2548c4659c appears to be the culprit, also affects -T html.
>
> How does grohtml interpret the following?
grohtml uses use_charnames_in_special so I was trying to give more information
to pin down the particular code path causing the issue.
[...]
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64484>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
