Hi Vincent, So ideally, the fallback for "±0" should be "+0 or -0", which is > much more readable and less ambiguous than "+-0" or "+/-0".
For approximating ± in ASCII, is there some reason \z_+0 hasn't been considered? I'm asking earnestly, as I'm primed to assume overstriking hacks have already been ruled out (pun intended) as a fallback. Regards, — John On Fri, 9 Aug 2024 at 08:15, Dave Kemper <saint.s...@gmail.com> wrote: > On Thu, Aug 8, 2024 at 7:59 AM Vincent Lefevre <vinc...@vinc17.net> wrote: > > FYI, +-0 could be interpreted by the reader as in C, where a unary > > minus operator is applied, then a unary plus operator. And about +/-0, > > the "/" is already used a the division operator, so that this doesn't > > help parsing. > > It helps *some*, in that "/" can't be a unary operator, so it signals > to the reader that +/-0 isn't a C expression. It also helps that > "+/-" has been used in other contexts where ± is unavailable, so some > readers might already be familiar with it. > > The latter point argues in favor of Branden's idea to change groff's > fallback from +- to +/-. > > > So ideally, the fallback for "±0" should be "+0 or -0", which is > > much more readable and less ambiguous than "+-0" or "+/-0". > > That is a clearer phrasing, but unfortunately, there's no way to make > that transformation an automatic fallback in the man macros (unless > Tadziu swoops in to prove me wrong); the whole phrase would have to be > specifically coded that way in the individual page--something that, > aside from being discouraged in man pages, is less reliable than one > might hope (http://savannah.gnu.org/bugs/?65403#comment0). > > > Anyway, currently, for consistency, this should be "+0 or -0", > > as this is already used: > > ...which luckily makes all the above moot. > >
