[opensuse-factory] doc formatting oddity -- that, IMO, could use correction
Which software is doing this? The bash manpage has source: [\fBtime\fP [\fB\-p\fP]] [ ! ] \fIcommand\fP [ [\fB|\fP\(bv\fB|&\fP] \fIcommand2\fP ... ] that produces: [time [-p]] [ ! ] command [ [|⎪|&] command2 ... ] - - - - - - - - - - - -- - - ^ Which *may* look right on your display or not The char over my carat, that seems to be what "(bv" in the source is being mapped to, is a U+23AA, which is a full-height vertical line used in box-drawings. It stuck out because 2/3 of my displays showed a "�" or empty box for that char. It doesn't seem to be that common, not to mention *semantically incorrect*. It would be better, I think, if the software matched "(bv" to a presentation form for a vertical bar. Presuming that half-width is preferable over full-width, (though it may not make a difference, now that I think about it) to use U+FFE8, "￨" -- a half-width light vertical bar that is taller than 0x7f (at least in the fonts I am seeing it with). Putting the logical or in the middle with the halfwidth vertical light on either side of it: looks like (with a few repeats): "￨|￨ ￨|￨ ￨|￨ ￨|￨". Is that SW troff or nroff or what? Is that something that is configured upstream? tnx... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[wearing the groff maintainer hat]
Well... `bv' is not the optimal character, but the number of choices are quite limited if you want to stay compatible.
Obviously, 2/3 of your displays don't support utf-8 well. Some possibilities: 1. your display font has just a too small character repertoire, or 2. your fallback fonts don't have a sufficiently large character repertoire, or 3. you have not properly configured your terminals, using the wrong character encoding, for example latin-1
The very problem is that character `\(bv' (in the original troff documentation you can find this is the abbreviation for `bold vertical') is intended for building up vertically oversized brackets and braces. A similar character is `\(br' (`box rule') which doesn't fit the semantical meaning either. The correct character to use would be `\(or'. However, this maps to the normal vertical bar which the bash people obviously tried to avoid.
I think that `bv' is a good choice for this very special situation in the bash manpage. In case you can't stand the appearance, feel free to adjust the used character either in the file `man.local' or in `troffrc', for example by appending .if '\*[.T]'utf8' \ . char \[bv] \N'65512' which maps `\(bv' to U+FFE8 if the output device produces utf-8. Werner
Werner LEMBERG wrote:
Yes... It is a fairly good choice from the visual *DEPENDING* on the font loaded. One of the features or important aspects of Unicode is having a rich variety of similar looking symbols that retain their semantic meaning even though they may look identical. Think Greek letters and math, for example. U sing semantically correct (or close to it) characters, can be useful for people who might be using software that -- if it cannot display it, might give the literal description (think "blind-reader SW, as a possibility, though there might be more). I felt that something that indicated vertical bar in the description might be better on those grounds and the char I pointed to was about a 75/100 (vs the one that is there probably a 90/100 on looks). But hey, what those blind people can't see won't hurt 'em right? ;-| As for my own usage, I can take a completely obtuse character, dump it in hex, decode it from UTF-8, and check it out. Given how easy it is, I'm sure it wouldn't be a problem for anyone else either!
:-) *cheers*
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[wearing the groff maintainer hat]
Well... `bv' is not the optimal character, but the number of choices are quite limited if you want to stay compatible.
Obviously, 2/3 of your displays don't support utf-8 well. Some possibilities: 1. your display font has just a too small character repertoire, or 2. your fallback fonts don't have a sufficiently large character repertoire, or 3. you have not properly configured your terminals, using the wrong character encoding, for example latin-1
The very problem is that character `\(bv' (in the original troff documentation you can find this is the abbreviation for `bold vertical') is intended for building up vertically oversized brackets and braces. A similar character is `\(br' (`box rule') which doesn't fit the semantical meaning either. The correct character to use would be `\(or'. However, this maps to the normal vertical bar which the bash people obviously tried to avoid.
I think that `bv' is a good choice for this very special situation in the bash manpage. In case you can't stand the appearance, feel free to adjust the used character either in the file `man.local' or in `troffrc', for example by appending .if '\*[.T]'utf8' \ . char \[bv] \N'65512' which maps `\(bv' to U+FFE8 if the output device produces utf-8. Werner
Werner LEMBERG wrote:
Yes... It is a fairly good choice from the visual *DEPENDING* on the font loaded. One of the features or important aspects of Unicode is having a rich variety of similar looking symbols that retain their semantic meaning even though they may look identical. Think Greek letters and math, for example. U sing semantically correct (or close to it) characters, can be useful for people who might be using software that -- if it cannot display it, might give the literal description (think "blind-reader SW, as a possibility, though there might be more). I felt that something that indicated vertical bar in the description might be better on those grounds and the char I pointed to was about a 75/100 (vs the one that is there probably a 90/100 on looks). But hey, what those blind people can't see won't hurt 'em right? ;-| As for my own usage, I can take a completely obtuse character, dump it in hex, decode it from UTF-8, and check it out. Given how easy it is, I'm sure it wouldn't be a problem for anyone else either!
:-) *cheers*
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Andrey Borzenkov -
Linda Walsh -
Werner LEMBERG