[bug #59962] soelim(1) man page uses pic diagram--should it?

[Dave]

Follow-up Comment #10, bug#59962 (group groff):

[comment #8 comment #8:]
> You are probably right. Po4a emits:
> po4a::man: This page includes another file with '.mso'. Do not forget to
translate this file ('pic.tmac').
> But this "other file" ('pic.tmac') does not appear.

Ah, pointing to .mso is very helpful!  This line in soelim.1.man loads the
definitions for the macros .PS and .PE (and a couple others that soelim.1.man
doesn't use).  They are in the file tmac/pic.tmac, which is shipped as part of
groff (http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/pic.tmac).  The
good news is that this file produces no output itself, so there is nothing in
it that needs translation.

> The current situation is that the graphics are not translated. 

The graphics are encoded within the file soelim.1.man itself, in two segments
between the macros .PS and .PE.  Is po4a stripping out these segments?  If so,
this is a separate issue from the diagnostic about the .mso line: .PS and .PE
should be recognized as start and end macros for pic segments even in the
absence of pic.tmac being included.


___

Reply to this item at:

  

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

Re: [bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Steve Izma]

On Sun, Jan 14, 2024 at 05:23:28PM -0500, G. Branden Robinson wrote:
> Subject: [bug #64285] [troff] \D't' (set line thickness) drawing command
>  alters drawing position
> 
> Update of bug#64285 (group groff):
> ...
> > If you think fixing a crazy (but well known and documented)
> > "feature" is more important than maintaining 30 years of
> > groff compatibility,
> 
> I pretty much do, yeah.  Every crazy feature we keep dragging
> along with us makes the language harder to acquire, remember,
> and work with.  Where the size of the impacted user community
> is small, as it surely is here--I fear the most prolific users
> of drawing escape sequences outside of macro packages or
> preprocessors are cargo cultists--it seems an easy choice to
> make.

I agree that this should be fixed. But I can't imagine any
situation where the current behaviour can be considered a
feature. It's more likely that everyone using to the \Z'' fix is
doing so as a workaround and any such documents would be
unaffected by improving the \D't' behaviour.

I don't understand your reference to "cargo cultists". There are
scads of situations where one doesn't want to bother with macro
packages, e.g., one-page posters, flyers, announcements. I've
probably made hundreds of them with groff. Those are the kinds of
situations where one draws lots of lines and where this bug
becomes a nuisance.

The term "cargo cult" is almost always used in a pejorative way.
But I've been to Vanuatu and it's clear to me that the real
history of cargo cults is a history of anti-colonial movements
that engaged in communal, ritualized resistance, not so-called
superstition.

-- Steve

-- 
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada  N2H 1W6
E-mail: si...@golden.net  cellphone: 519-998-2684

==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
   from Plato to Darwin*, 1996

[bug #59962] soelim(1) man page uses pic diagram--should it?

[Dave]

Follow-up Comment #9, bug#59962 (group groff):

[comment #8 comment #8:]
> The new macro is a great idea and I agree that it will be
> picked up properly very slowly. Is it a GNU extension and
> which minimum requirement is attached to it?

The .MR man macro originated as an extension in Plan 9 troff in 2020, which
GNU troff then also adopted.  In the time since Branden wrote comment #6,
groff 1.23 has been released, so this macro is now officially available.

> It would be great if there is a web page explaining the use of this
> (and the minimum requirements as well) so I could point people to this.

I'm not aware of such a page.  The groff 1.23 release notes
(http://lists.gnu.org/r/info-gnu/2023-07/msg1.html) cover the syntax of
.MR, but this information is buried in the middle of a very long document
describing a release with a huge number of changes.  And the macro is of
course documented in the groff_man(7) man page included with the 1.23 groff
release; this is probably the most definitive place to point people.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

Follow-up Comment #14, bug#64285 (group groff):

[comment #12 comment #12:]
> If you think fixing a crazy (but well known and documented) "feature"
> is more important than maintaining 30 years of groff compatibility,

I wrote a response to this point as well, then realized I was only repeating
my remarks of comment #4--except that where in that comment I had to say
"there's yet to be a released groff with the \s change, so we don't yet know
what gnashing of teeth it might engender," we now know that in the six months
that 1.23 has been out, people have complained about various changes debuting
in it, but not this one (at least not where I've seen it, though of course I
don't follow every forum where such complaints might be voiced).


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Update of bug#64285 (group groff):

  Status:   Need Info => None   
 Assigned to:deri => gbranden   

___

Follow-up Comment #13:

[comment #12 comment #12:]
> If you think fixing a crazy (but well known and documented) "feature" is
more important than maintaining 30 years of groff compatibility,

I pretty much do, yeah.  Every crazy feature we keep dragging along with us
makes the language harder to acquire, remember, and work with.  Where the size
of the impacted user community is small, as it surely is here--I fear the most
prolific users of drawing escape sequences outside of macro packages or
preprocessors are cargo cultists--it seems an easy choice to make.

For an example of me biting the bullet and restoring backward compatibility in
spite of my strong view that it was the wrong _technical_ choice, see bug
#51468.

> then it would probably make sense for you to do the deed (to libdriver and
gropdf) in the same commit. Just comment out the two lines about 3916 (in
section dealing with "Line Thickness "):-

>   $poschg=1;
>   $xpos+=$lwidth;


> And test with the code in comment #9. Both paragraphs should be the same,
and with no unusual gap later in the first lines.

Thanks for the fish, there's no telling how long I'd have been out on the
ocean casting my rod and reel fruitlessly for that one.  :)

Clearing status and reassigning to self.

Not sure when I'll get to it.  I predict low difficulty but the urgency is
also low.


___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Follow-up Comment #26, bug#63074 (group groff):

In my seat-of-the-pants example, I committed the same crime I complained of:
lack of input validation.  My point might be easier to understand if I add it
in.


.nr refno 1
.de DEFREF
.  nr refno +1
.  if !\A'\\$1' \
.ab bogus tag '\\$1' in reference definition; stick to ASCII
.  ds ref*id!\n[refno]!tag \\$1
.  ds ref*id!\n[refno]!author \\$2
.  ds ref*id!\n[refno]!desc \\$3
.  ds ref*id!\n[refno]!year \\$4
..
.DEFREF story "Dupr\[e aa]" "Best \%Story\%Book Ever" 1989
.DEFREF Гуляйпольщина "Махновщина"
"весенне-летнего" 1919 \" gets rejected




___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Follow-up Comment #25, bug#63074 (group groff):

[comment #24 comment #24:]
> Bug #64484 is marked as fixed.

Right, but I believe there was a relationship nevertheless.

> I already have a reliable way to pass byte sequences in device control
commands, .stringhex.

Okay.  But it didn't do anything about this failing test case (which
admittedly didn't exist until I started to research this issue).

https://git.savannah.gnu.org/cgit/groff.git/diff/src/roff/groff/tests/device-control-special-character-handling.sh?id=974c063f0a9e1ef6c0d2cac4755a3b9d6e925b0d

Of which the salient part is the actual test input:


input='.nf
\X#bogus1: esc \%man-beast\[u1F63C]\\[u1F00] -\[aq]\[dq]\[ga]\[ha]\[rs]\[ti]#
.device bogus1: req \%man-beast\[u1F63C]\\[u1F00]
-\[aq]\[dq]\[ga]\[ha]\[rs]\[ti]
.ec @
@X#bogus2: esc @%man-beast@[u1F63C]@@[u1F00] -@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]#
.device bogus2: req @%man-beast@[u1F63C]@@[u1F00]
-@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]'


...which looks pretty noisy but tests several things.

1.  Use of \X escape sequences versus `device` requests.
2.  Use of \% escape sequences in device control commands (do they get
removed?).
3.  Use of ordinary hyphens in device control commands (do they get converted
to some crazy Unicode thing?).
4.  Use of special character escape sequences to represent ASCII characters in
device control commands and which should therefore be passed through as
ASCII.
5.  Robustness in the face of a changed roff escape character.  This did *not*
work prior to the bug #64484 fix.

> This bug was previously named "warning messages when using special
characters in TITLE or AUTHOR" and the attached cyrillic.pdf shows both the
pdf title and author shown with cyrillics and no warnings. So I would say this
one is dependent on bug #65098, i.e. merge the rest of my branch.

I hear your expression of urgency but I don't think "stringhex" is good
long-term solution to what ails us.  You are correct in comment #22 that I did
not correctly apprehend at first what it was for.  I thought you developed it
because we had no way to reliably transmit arbitrary byte sequences to device
control commands.  But we did, sort of--it just needed to be made consistent
and reliable.  That it wasn't is what my test case attempts to illustrate and
what the fix to bug #64484 attempts to prove.

No, I accept your premise that the main driver behind "stringhex" was this:

> The problem lies in the original pdfmark API, if you look at the pdfmark.pdf
you will see that in the sections describing .pdfhref M and .pdfhref L which
both refer to a "dest-name" and "descriptive text", it says that if a
dest-name is not given the first word in the description is used as the
dest-name.

I appreciate your explanation.  If the problem was with the pdfmark API, then
let's fix the pdfmark API.

In particular, this:

> if a dest-name is not given the first word in the description is used as the
dest-name

...strikes me a short-sighted, especially without any validation going on.  A
textual description of a hyperlink/bookmark might contain all sorts of crazy
stuff.  (Like Cyrillic or CJK characters or, worse, motion or type-size or
font-selection escape sequences.)  Assuming that it was going to be a
well-behaved sequence of ASCII bytes or even that one could "sanitize" or
"cln" one's way through was a hopeless notion.  That won't be practical until
we have a string iterator and more conditional expressions that enable the
user of an iterator to identify the type of each item in an iterated
string/macro/diversion.  But if I understand you correctly, we don't need that
fancy new stuff to solve the present problem, with stringhex or without.

It would probably benefit me to look up Peter's documentation on _mom_'s
"HEADING" macro.  It is a bit baffling to me that one has to repeat arguments
like this:


.HEADING 1 NAMED Гуляйпольщина "Гуляйпольщина"
...
.PDF_LINK Гуляйпольщина PREFIX ( SUFFIX ) "see: +"


> Where the "+" is replaced by the contents of the string register
pdf:look(Гуляйпольщина), which would actually be a string of
\[u] nodes, so would generate an error. This is what stringhex is for, to
hide the contents so that groff does not see it as a sequence of nodes. The
ideal solution would be to allow string registers to have an attribute (say
"glass") which signals that groff should never try to interpret its contents,
i.e. operate as if the escape mechanism was turned off just for the contents
of that register, and have a way of turning that attribute on/off or an escape
which sets the attribute for the enclosed string.

Right now I don't understand why we would need to elaborate a fairly
fundamental *roff language data type (the string) with a "glass" attribute
when, if you have a list indexed by a number or a _valid_ identifier, you can
simply define a string using a list item's index as a prefix.


.nr refno 1
.de DEFREF
.  nr refno +1
.  ds ref*id!\n[refno]!tag \\$1
.  ds ref*id!\n[refno]!author \\$2
.  ds 

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Deri James]

Follow-up Comment #12, bug#64285 (group groff):


[comment #10 comment #10:]
> I see very little difference between PS and PDF output for your input
exhibit in comment #9, using bleeding-edge _groff_.

I agree.

> Regarding the topic at issue, I propose that the first and second paragraphs
should look the same, regardless of output device.  I am willing to undertake
the alternation of the "libdriver"-based output drivers to realize this
output, in coordination with changes in _gropdf_ to achieve the same.
> 
> What do you think?

If you think fixing a crazy (but well known and documented) "feature" is more
important than maintaining 30 years of groff compatibility, then it would
probably make sense for you to do the deed (to libdriver and gropdf) in the
same commit. Just comment out the two lines about 3916 (in section dealing
with "Line Thickness "):-

$poschg=1;
$xpos+=$lwidth;

And test with the code in comment #9. Both paragraphs should be the same, and
with no unusual gap later in the first lines.



___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[Deri James]

Follow-up Comment #24, bug#63074 (group groff):

Bug #64484 is marked as fixed. I already have a reliable way to pass byte
sequences in device control commands, .stringhex. This bug was previously
named "warning messages when using special characters in TITLE or AUTHOR" and
the attached cyrillic.pdf shows both the pdf title and author shown with
cyrillics and no warnings. So I would say this one is dependent on bug #65098,
i.e. merge the rest of my branch.

(file #55567)

___

Additional Item Attachment:

File name: cyrillic.pdf   Size:27 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-3f5b69a3b837951a0e5c0b7730ee347c798a8844.tar.gz


___

Reply to this item at:

  

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

[bug #62471] [tbl] horizontal and vertical rules are drawn too long in nroff mode

[G. Branden Robinson]

Update of bug#62471 (group groff):

  Status:   Fixed => In Progress
 Open/Closed:  Closed => Open   

___

Follow-up Comment #10:

Ah, but consider this.


$ cat EXPERIMENTS/table-top-vrule.roff 
.ns
.TS
L | L.
foo bar
.TE
$ nroff -t EXPERIMENTS/table-top-vrule.roff|cat -s # groff Git
grotty::(EXPERIMENTS/table-top-vrule.roff):20: error: output
above first line discarded
foo │ bar

$ ./build/test-groff -Tutf8 -t EXPERIMENTS/table-top-vrule.roff|cat -s # my
working copy
│
foo │ bar





___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Update of bug#63074 (group groff):

  Depends on: => bugs #64484

___

Follow-up Comment #23:

Adding dependency on bug #64484, because to achieve the aim of this ticket, a
reliable means of transmitting encoded byte sequences to the output device is
necessary.  Not all devices need to use the same convention, though that would
be nice.

I still owe Deri a reply to comment #22.


___

Reply to this item at:

  

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

[bug #59962] soelim(1) man page uses pic diagram--should it?

[Helge Kreutzmann]

Follow-up Comment #8, bug#59962 (group groff):

Hello Dave,
sorry for having missed Brandens reply (and thus the delay in responding).

#1
I think we discussed this already, I sill think this is not correct, but it
does not make sense to discuss this further

#2
Thanks for the explanation. 
a) consistency is key (and also for tools processing the man pages), so for me
youngster (I only started Linux/Unix mid 90s) putting references in bold is
all I know, hence I ask to make it consistent when I see a deviation. 

And at least some tools (external to roff) "know" these rules and hyperlink
(e.g. in HTML) B(x).

The new macro is a great idea and I agree that it will be picked up properly
very slowly. Is it a GNU extension and which minimum requirement is attached
to it? It would be great if there is a web page explaining the use of this
(and the minimum requirements as well) so I could point people to this. I
expect people to tell me "my software runs on xyz" so I cannot use it or "I
support this old Linux distribution(s)". 

And yes, the probably best thing would be to request all those markup
languages with converters into *roff to use this macro during conversion, this
would probably speed up the conversion quite a bit. To be honest, I know very
little about *roff myself, so if I were to write a man page, I would use some
higher level tool myself, in the distant past I used SGML.

b) The "bold is literal and italic is variable" is very helpful to me both as
reader and as a translator. Sometimes the text is very hard to read, and
having an indication what is the actual variable really helps, especially if I
have little knowledge of the topic. And in *many* man pages this is done, so
consistency is key again.

Ideally we had semantic markup, hard coding "bold", "italic" etc. so semantics
is not nice. 

And thanks for explaining the rationale and meaning of \%.

c) Yes, I almost exclusively read man pages in the (Linux) console, very
seldom in an xterm or somewhere else.

#3
Your rationale seems sensible. As a translator, I usually simply follow
suite.

#4
You are probably right. Po4a emits:
po4a::man: This page includes another file with '.mso'. Do not forget to
translate this file ('pic.tmac').
But this "other file" ('pic.tmac') does not appear. I remember we made some
experiments back then to solve this, but it broke more than it helped.
The current situation is that the graphics are not translated. 
In conclusion: Not a bug in *roff, but in po4a and I understand if requesting
a "workaround" in *roff is completely inapproriate. Therefor, as stated below,
this does not warrant keeping this issue open.

#5 
The current state in my VT is that the arrows work (jay!), the only have a box
before/above which is rendered as straight line in an xterm (vertically or
horizontally). So from my point this is very, very minor and not a problem of
*roff.

And as usual, thanks for your very helpful and extensive explanations.

   Helge



___

Reply to this item at:

  

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