bug-groff
[Top][All Lists]
Advanced

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

[bug #66165] commit dcae60b0fb1ad3fa3314fdfdbecb973961a40410 has wrong a


From: Deri James
Subject: [bug #66165] commit dcae60b0fb1ad3fa3314fdfdbecb973961a40410 has wrong assumption
Date: Fri, 6 Sep 2024 20:09:03 -0400 (EDT)

Follow-up Comment #7, bug #66165 (group groff):


> Observe the gymnastic achievement of a device extension command via neither
the `\X` escape sequence nor the `device` request, but raw grout stuffed into
a "transparent throughput" escape sequence!
>
> Why such indirection?  It looks for all the world like a quick hack way back
in 2012 to get around problems with the "pdfmark" package, or maybe with troff
itself.

OMG! You've caught me out. I was on that grassy knoll, Elvis was chasing me
when he left the building, and I'm sorry about JR!

It has been a long time since I have been complemented on my gymnastic
prowess, not since the 1971 National Spastics Games (3 Golds and 6 Silvers),
thank you.

I'm afraid the truth is a little less exciting.

Somewhere on here is a bug about an assert abort (I think falling off the end
of the node list), the example stopped failing after I removed asciify from
pdf.tmac. This was one of the places which triggered the bug, but I found if I
didn't call .pdfmark but replaced it with what pdfmark actually does, the
assert abort disappeared. So obviously nesting depth is involved, as well as
asciify.

> I'm guessing that either the "pdfmark" macro was trying to do too much (a
safe bet in my experience), and/or that using `device` or `\X` directly had
undesirable side effects. 

Why give the poor pdfmark macro a bad rep, it's only a one liner:-

.de pdfmark
. nop \!x X ps:exec [\\$* pdfmark
..

I left the original line as a comment to remind me to put it back when the
troff bug got fixed. It is not fixed, but no longer triggered without asciify,
so I will be reinstating the call to pdfmark in a future push.

You got a bit excited for awhile to discover I might have done something
wicked and devious, and the commented out line was the smoking gun!!

Reality is nearly always a bit of a let down.  Even my gymnastic prowess pales
a little under the spotlight of reality, because I omit from the story, "My
Nemesis", a muscly Geordie, in my ability group, who got 6 golds and 3
silvers. At least I beat the geezer who got 9 bronzes! You get on telly with
just 1 paralympic gold these days - pah!! :-)

Serious now. The intention of this commit to use the same glyphs in
pdfbookmarks as in the document has merit, its just that this is the wrong 
place to do it, since it sprays over everything, we want to only do this in
certain places. For example if the text is the label to a destination
"intro-1" we should not convert the "-" to something else since they would
expect something like "okular file.pdf#intro-1" to work, since that is
actually what they used when the destination was named. If the "-" is in text
of the bookmark, i.e. visible in  the bookmark pane, there is some sense in
using the same glyphs as would be used in the document text, but you may be a
little disappointed because they can look a bit different depending on the
system font selected on your system.

The good news is I have a 1 line addition to gropdf which I think  does  what
you want, so you can reverse this commit if you want.



    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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