Re: Special characters

[Lennart Jablonka]

> $ nroff -man     < doc/CSV_XS.3 > doc/CSV_XS.man
>
> or
>
> $ nroff -mandoc  < doc/CSV_XS.3 > doc/CSV_XS.man
>
> Used to render up to and including groff-1.22
>
>  $row\->[2] =~ m/pattern/ or next;
>
> as
>
>  $row->[2] =~ m/pattern/ or next;
>
> but as of 1.23, generates
>
>  $row->[2] =˜ m/pattern/ or next;
>
> which renders all manual pages useless

If you aren’t careful, you could evoke the impression your 
hyperbole is to be taken literally.

> I download the source code to read "NEWS", and I think the relevant
> section is
> --8<---
> o The an (man) and doc (mdoc) macro packages no longer remap the -, ',
>  and ` input characters to Basic Latin code points on UTF-8 devices,
>  but treat them as groff normally does (and AT&T troff before it did)
>  for typesetting devices, where they become the hyphen, apostrophe or
>  right single quotation mark, and left single quotation mark,
>  respectively.  This change is expected to expose glyph usage errors in
>  man pages.  See the "PROBLEMS" file for a recipe that will conceal
>  these errors.  A better long-term approach is for man pages to adopt
>  correct input practices; the man pages groff_man_style(7),
>  groff_char(7), and man-pages(7) (subsection "Generating optimal
>  glyphs"; from the Linux man-pages project) contain such instructions.
>  Doing so also improves man page typography when formatting for PDF.
>
>  If you maintain a generator of man(7) or mdoc(7) documents (such as a
>  tool that converts other formats to them), and need assistance, please
>  contact the groff@gnu.org mailing list and describe your situation.
> -->8---
>
> I wondered for longer why I get those silly and unwanted quotes and
> dashes, but I am now faced with projects that generate useless files,
> so I had to complete that task on a system that still had the sane 1.22
> and get the results from there.

NEWS was right:  Glyph usage errors in man pages are exposed.

> I bet your goals are laudable, but to me readable man-pages and
> cut-n-paste ready output is way more valuable than visual changes that
> I happen to not like in the first place however correct that might be.
>
> In order to enable users like me to disable that, I sincerely hope that
> the next release of nroff/groff will support an environment or RC
> option to disable these translations.

In the man page, you can use the correct characters;  for the 
output for bad man pages, you can put translations in 
m{an,doc}.local.

> And I mean everywhere. I really
> want "don't" to show as "don't" and not as "don’t", "~" as "~" and not
> as "˜", and "-" as "-" and not as "‐" and probably many more insane
> unwanted "intelligent" replacements.

If I understand you correctly, you want to replace all non-ASCII 
glyphs by ASCII approximations.   I’m inclined to agree:  That 
sounds like something quite a few people might want for different 
reasons, so it would be good if we had an option for that.

> I want an environment and not an option, because I personally do not
> want these translations ever (unless I do, and then an option would be
> appropriate).

I think you might want a device.   Like devutf8, but for ASCII.   
We could call it devascii.   You’d be able to invoke nroff, 
instead of with -Tutf8, with -Tascii.

> Sorry if I sound harsh, but this change already cost me hours of work
> to fix.

I’m afraid my hope is that the man pages’ author will pour in the 
work to fix the man pages.

> I am on the brink of getting the 1.22 source code and install that over
> the system package of 1.23, which just brings me hate.

That would be sad, seeing as 1.23 has so many improvements in its 
documentation that make it easier for the reader to grasp good 
practice.