names of ISO 8859 encodings

Hi,

Commit 3ed1de0ddccb42bae4151c7225d3fddeab04ff43 should better be reverted, IMO. The ISO organization or their *standards* can be renamed to whatever names; what matters here is what the *encoding* is commonly referred to.

The *encoding* names are standardized by IANA:
https://www.iana.org/assignments/character-sets/character-sets.xhtml
The first ISO 8859 encoding there has the name
ISO-8859-1
or
ISO_8859-1
and the first among these is the preferred MIME name. So, please, in encoding names:
* revert the ISO -> ISO/IEC change,
* change the space after ISO to a dash/hyphen-minus.

Likewise (partially) for commit d5e5db91ece5955b21ae1aedc03ba1d56d3cf423.

Bruno

Hi Bruno,

I'm okay with reverting those if there's consensus. Would you mind CCing the interested parties (e.g., the people that requested that change, and anybody that participated in the discussion)?

(I've CCed them now, anyway.)

Thanks!
And have a lovely night!
Alex

<https://www.alejandro-colomar.es/>

Hi Bruno & Alex,

Oy vey. Helge Kreutzmann submitted a similar bug report to groff and I was planning to make the ISO -> ISO/IEC change to its man pages.

Also your point seems more strident than clear to me as regards the encoding name. If I want to refer to character encoding _not_ in the context of a machine-parsed MIME datum, I trust you're not going to tell me I need to spell with an obnoxious hyphen-minus or underscore before the standard number ("8859")...?

I would then wonder why I am not equally compelled to write "ISO-9000". Or, to name a standard that comes up in documents to which I contribute, "ISO-6429" (better known to some as ECMA-48, and yes, ECMA standards routinely get the hyphen-minus).

Thanks for looping Helge in.

Regards,
Branden

Hello Branden,
hello Bruno,
hell Alejandro,
Am Fri, Dec 13, 2024 at 06:56:54PM -0600 schrieb G. Branden Robinson:

There is no "renaming" intended. It is just the proper name of the standard, which is often (probably because of sloppiness) forgotten. There are two organizations who joined forces to create these
standards: ISO and IEC. Dropping half of them is not very nice and so far, precision is what is good about the (man) documentation. You should be able to rely on the documentation. So why should you stop short when giving credit and citing documents correctly? And yes, the correct name contains "ISO/IEC"[1].

Of course, how you name them in your day to day communication is up to you (and should be so), but in the documentation it should be correct.

Disclaimer: I'm editor of ISO/IEC standards, but not in the field of character encondings.

I'm not going into the business of valuating which standards should be adhered to. But when referrring to the proper document the correct name should be given IMHO.

My personal opinion is that correct typography is important, but on quick reading I probably would not spot the differences amongs the various dashes for example. So for me, having all the correct letters is important and of course, to copy and paste text (e.g. code) where necessary, even if that violates typography standards.

And yes, I'm well aware that Branden and Donald Knuth (and successors) strive for well printed documents, and I'm glad for this.

Greetings

Helge

[1] I carefully checked this. There are, of course, lots of standards purely from ISO (ISO 9001 comes to mind) and from IEC (e.g. IEC 62443).

      Dr. Helge Kreutzmann                     [email protected]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

Hi Helge,

Possibly the "use/mention" distinction of linguistics would be helpful here.[1] In some technical discussion contexts, we merely _mention_ a character encoding standard. For instance, "This program is capable of transliterating any document using an ISO/IEC 8859 character encoding to valid UTF-8.".

In other contexts, we _use_ the identifier itself, perhaps as an input argument to a program. For example:

   $ iconv -f iso-8859-1 -t utf-8 NEWS

In this shell command, we must spell the character encoding specifiers exactly as such,[2] and when documenting the foregoing in an example in a man page, we are well advised to spell the hyphen-minus signs with leading backslashes.

.RS
.EX

$ \c
.B "iconv \-f iso\-8859\-1 \-t utf\-8 NEWS"
.EE
.RE

Alex, do you think this issue is enough of a trip hazard to warrant presentation in man-pages(7)?

I think we can avoid violating standards of typography; more precisely, the process of rendering to an output device of limited capability will violate those standards for us.[3] For example, a character-cell terminal device generally can't (1) render arbitrary glyphs sequences superscripted or subscripted[4]; (2) change the type size;[5] or (3) change the font family (to use letterforms with or without serifs) for only part of the rendered text (as opposed to the entire display, including scrollback buffer) at once.

That's pretty august company to be paired with. Lest anyone get any inflated notions of my role in groff, Joe Ossanna of Bell Labs wrote troff in the mid-1970s. After his untimely death, Brian Kernighan refactored troff circa 1980 into "device-independent troff". These were proprietary to AT&T (and commercial products for a while), so the FSF hired James Clark to write a clean reimplementation of AT&T troff, called groff, in about 1989. Werner Lemberg later became groff maintainer and added many features to it such that it became a viable alternative to TeX in many more applications (partisan preferences aside). Then Bertrand Garrigues did some mostly unsung but badly needed work on groff's build system, making it more pleasant to work with. My role has largely been (1) fixing bugs; (2) writing automated tests to (try to) ensure that dead bugs stay dead; (3) revising and correcting documentation; and (4) making modest extensions and reforms to the *roff language and some of the macro packages, provoking heated arguments and/or revealing formerly unspecified behavior, around which some people of course poured fast-drying cement in fits of delirium years ago.

In software as in religion, the commandments held most sacrosanct are those that no one thought to write down in the first place.

("Of _course_ I can interchange pointers and ints. No one ever said I can't!" Eventually, they did say so. To much gnashing of teeth.)

Regards,
Branden

And now the footnotes, where we play free-association rambling bingo.

[1] https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction

[2] a given system's iconv(1) command may recognize alternative names for some encodings

[3] For example, the bash(1) man page contains this:

.if n Bash is Copyright (C) 1989-2024 by the Free Software Foundation, Inc. .if t Bash is Copyright \(co 1989-2024 by the Free Software Foundation, Inc.

In principle, this shouldn't be necessary. Chet should just write the second line without the ".if t" conditional and delete the first. The output device should know how to gracefully map the special character "\(co" to a copyright sign, and itself do the job of translating it to "(C)" if it has only an ASCII repertoire. Presumably, at some point in the past Chet (or the initial Bash maintainer, Brian Fox) used an nroff program that was defective, and also labored under the no-longer-correct misconception that omitting a copyright symbol from one's notice was a fatal defect that effectively placed the work in the public domain. That stopped being true as of 1 March 1989.[7] Further, prior to guidance issued by the U.S. Copyright Office in the decades since, the use of "(C)" as a substitute for a copyright sign _may not have sufficed_ to prevent the copyright notice from being regarded as defective. The Copyright Office, then and now, prefers the abbreviation "copr." when © is typographically unavailable.[7] Nowadays, its advice is that "c" (note lowercase) is an "acceptable variant", that _may_ retain the efficacy of the copyright notice. However, it is not the U.S. Copyright Office but the courts that ultimately arbitrate such things. Moreover, given recent developments, the Office's guidance to authors need not carry any weight to a federal judge. Between the U.S. Supreme Court's repeal of "Chevron Deference"[8] and the availability of a federal district court in Western Texas offering itself as a venue to any right-wing plaintiff in the country and pursuing a crusade of maximalist Federalist [read: monarchist] Society doctrine with a penchant for issuing nationwide permanent injunctions,[9][10] the status of any federal statute, executive agency guidance, or even constitutional provision[11] is uncertain for the next few years at least. But rest assured--we term this sort of radical disruption of American jurisprudence a "conservative" judicial philosophy. 👍

[4] Often, the decimal digits 0-9 are available as superscripts. This selection is too meager for general typography, let alone mathematical typesetting where arbitrary, complex expressions may occur in exponents, for instance. Occasionally you need an integral up there.

[5] The DEC VT100 and its successors could do double-width and

     double-size type.[6]  Try this in your preferred terminal emulator.

     $ printf "$(tput bold)\e#3See also\n\e#4See also$(tput sgr0)\n\
          $(tput sitm)xterm$(tput ritm)(1)\n\n\e#6Patch #395    2024-09-11\
          $(tput sitm)xterm$(tput ritm)(1)\e#5\n"

     Anyone think these are worth supporting in grotty(1)?  ;-)

[6] https://vt100.net/docs/vt510-rm/DECDHL.html

     https://vt100.net/docs/vt510-rm/DECDWL.html

[7]  https://www.copyright.gov/circs/circ03.pdf
[8]  https://www.scotusblog.com/2024/06/supreme-court-strikes-down-chevron-curtailing-power-of-federal-agencies/
[9]  https://www.americanprogress.org/article/the-5th-circuit-court-of-appeals-is-spearheading-a-judicial-power-grab/

[10] I would not personally wager that copyright holders have much to fear under the current regime; revenues consequent to copyrights are a form of monopoly rent and therefore a worldwide tent pole of conservative political economy. But, if a poweful stakeholder has a prospect of a sufficiently large windfall from a radical change to copyright protections, and is willing to spend lavishly enough on political campaigns and super PACs, who knows what might happen?

Here's some model statutory language. "Any work under copyright by any entity other than the Walt Disney Company, its subsidiaries, or affiliates, enters the public domain as of January 1 of the year subsequent to its fixation in tangible form."

I mean, that's just "common sense", right?[12] Only Disney has any business adapting anything into a feature film, or exercising merchandising rights. Duh.

[11] https://www.cbsnews.com/news/what-is-birthright-citizenship/

[12] another term debased by conservative/centrist political rhetoric

I offer my own definition, in the spirit of Ambrose Bierce.

"Commonsense solution": a course of action I want to take for reasons I will not share with you.

Hi Branden,

I agree.

What's the issue? I think it's simple:

When referring to a standard, use the pedantically correct name for it. When showing a command line, use text that is pedantically correct to the command interpreter.

Am I missing anything?

Cheers,
Alex

<https://www.alejandro-colomar.es/>

[looping in groff@gnu]

Hi Alex,

I agree.

Only that people may sometimes not be clear on which is which. That is why it is important to typographically distinguish the cases. Traditionally this has been difficult in man pages, I think because (1) the man(7) package has no macros for quotation; (2) idioms for displayed examples and other I/O were not in Seventh Edition and slow to evolve.

I think some of the blame for (2) can be laid at the feet of the "it's reference, not a tutorial" camp. Even references sometimes need exhibits.

With Chet Ramey's kind indulgence, I've been trialling a simple quotation macro Q in the bash man pages (bash(1), readline(3), history(3)) this year.[1] I have an alternative design for quotation macros in mind as a future groff man(7) development.[2]

Regards,
Branden

[1] https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00027.html

Chet soon added a QN variant to prevent hyphenation, because it's a little tricky to achieve that in a quotation context otherwise.

[2] https://lists.gnu.org/archive/html/groff/2023-09/msg00052.html
https://lists.gnu.org/archive/html/groff/2023-09/msg00058.html

This is likely due for a cleaned up re-proposal under the new names QS/QE as suggested by Doug McIlroy. Also, an optional argument to disable hyphenation, brought to my attention by Chet this year, might be worth having, though mandoc(1) has the problem of formatting all arguments to unrecognized macros as text, which is not a very *roffy thing to do. It will do the same with .YS 0, until and unless mandoc(1) comes to support this extension scheduled for groff 1.24.

Having gained some practical experience with several other man(7) corpora, I probably would not float Q as a groff man(7) extension; I think QS and QE would suffice. I am mindful of the benefit of keeping the man(7) language as small as possible (but no smaller).