On Thu, Nov 16, 2023 at 02:52:23PM -0800, Adam Williamson wrote: > On Thu, 2023-11-16 at 23:41 +0100, Lukas Javorsky wrote: > > > > > > I think an upstream only wants to adhere to the language specification > > > (groff_char(7)). These small differences became prominent with the advent > > > of > > > UTF-8 capable terminals. They have always been visible in a PostScript > > > output. > > > > > > Imagine you are the upstream and a user sends you a bug report that groff > > > does > > > not behave according to the specification. While another user complains > > > that > > > his nonconforming input behaves weirdly. There is no solution which would > > > satisfy both. > > > > > > > I totally understand why they made the change, I just don't see the reason > > for requesting them to put the mapping back. > > > > I think the right decision would be that upstreams of the packages that > > have the man pages written with the wrong character, should be the ones to > > fix their man pages. > > But they *don't* have their man pages written with the "wrong > character". That's one reason why this is awkward and controversial. > > The man pages are written with the *right* character - an ASCII dash, > the character that is actually used for arguments to console commands. > groff is converting this to a Unicode dash based on the expectation > that it's being used for something more "text-y", and the writer just > used an ASCII dash because it's much more convenient to type, but they > really want a more text-ish dash. This may be the case for a lot of > text, but it's definitely not the case for CLI tool manpages. When they > write an ASCII dash, they want it to stay as an ASCII dash. > > With the 'new' behaviour, you have to markup or escape your ASCII > dashes somehow to prevent groff turning them into unicode dashes. In case of systemd man pages, it's even more confusing [1]: we write pages in docbook xml, and use that to generate man and html outputs (and even I think some people experimented with epub). We don't want to add the escaping in the xml text because at this point we don't know the output format and the escaping is only needed for one of the output formats. To fix the problem docbook itself would have to do escaping of any dashes it writes as troff. Maybe that'd be more "correct", but it's not happening right now, and hasn't been happening for the last 30 years. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2249869 "systemd‐userdbd.service(8), systemd‐homed.service(8), nss‐systemd(8) are missing" ^ this is the new hyphen ^ ^ Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
