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<foo>(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:
<https://savannah.gnu.org/bugs/?59962>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
