[PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Brian Inglis]

I have an OpenGroup/UNIX.org/Austin Group/POSIX account,
so added the missing ASCII-EBCDIC tables by copying from the POSIX PDF,
as copying data is fair use, and the man page copy itself is authorized.

As an aside to that, those ASCII-EBCDIC tables support characters from
the old ISO 2033:1983 MICR/OCR character sets now in Unicode OCR block
U+2440-U+245F, which appears only in a few fonts like Unifont and SIL
LastResort (and MS Segoe UI Symbol), and are still available as TTF
(some font formats and support are being dropped in favour of OTF).

They appear normal on my screen running 'man 1p dd' on my system which
has those fallback fonts installed.

Is it sufficient to run the groff addition install-font.sh script on
those fonts and add them to the config as .special, or is anything else
required to register and render the glyphs on other devices?

Or should I take this up on the groff list? 

Signed-off-by: Brian Inglis <Brian.Inglis@Shaw.ca>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=215971
---
 man-pages-posix-2017/man1p/dd.1p | 132 ++++++++++++++++++++++++++++++-
 1 file changed, 129 insertions(+), 3 deletions(-)

diff --git a/man-pages-posix-2017/man1p/dd.1p b/man-pages-posix-2017/man1p/dd.1p
index 4d1353d2ed6e..f79173e06251 100644
--- a/man-pages-posix-2017/man1p/dd.1p
+++ b/man-pages-posix-2017/man1p/dd.1p
@@ -378,15 +378,137 @@ intersections. For example, ASCII 0012 (LF) is the second row, third
 column, yielding 0045 in EBCDIC. The inverted tables (for EBCDIC to
 ASCII conversion) are not shown, but are in one-to-one correspondence
 with these tables. The differences between the two tables are
-highlighted by small boxes drawn around five entries.
+highlighted by small boxes drawn around five entries:
+0136, 0176, 0313, 0325, 0345.
 .br
 .sp
 .ce 1
 \fBTable 4-7: ASCII to EBCDIC Conversion\fR
+.sp
+.TS
+centre;
+l   cB sB cB sB cB sB cB sB cB sB cB sB cB sB cB sB
+l    _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _
+nB | n l | n l | n l | n l | n l | n l | n l | n l |
+.
+\&	0	1	2	3	4	5	6	7
+\&
+0000	0000	NUL	0001	SOH	0002	STX	0003	ETX	0067	EOT	0055	ENQ	0056	ACK	0057	BEL
+0010	0026	BS	0005	HT	0045	LF	0013	VT	0014	FF	0015	CR	0016	SO	0017	SI
+0020	0020	DLE	0021	DC1	0022	DC2	0023	DC3	0074	DC4	0075	NAK	0062	SYN	0046	ETB
+0030	0030	CAN	0031	EM	0077	SUB	0047	ESC	0034	IFS	0035	IGS	0036	IRS	0037	ITB
+0040	0100	Sp	0132	!	0177	"	0173	#	0133	$	0154	%	0120	&	0175	\[aq]
+0050	0115	(	0135	)	0134	*	0116	+	0153	,	0140	\-	0113	.	0141	/
+0060	0360	0	0361	1	0362	2	0363	3	0364	4	0365	5	0366	6	0367	7
+0070	0370	8	0371	9	0172	:	0136	;	0114	<	0176	\&=	0156	>	0157	?
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0100	0174	@	0301	A	0302	B	0303	C	0304	D	0305	E	0306	F	0307	G
+0110	0310	H	0311	I	0321	J	0322	K	0323	L	0324	M	0325	N	0326	O
+0120	0327	P	0330	Q	0331	R	0342	S	0343	T	0344	U	0345	V	0346	W
+0130	0347	X	0350	Y	0351	Z	0255	[	0340	\e	0275	]	0232		0155	\&_
+0140	0171	`	0201	a	0202	b	0203	c	0204	d	0205	e	0206	f	0207	g
+0150	0210	h	0211	i	0221	j	0222	k	0223	]	0224	m	0225	n	0226	o
+0160	0227	p	0230	q	0231	r	0242	s	0243	t	0244	u	0245	v	0246	w
+0170	0247	x	0250	y	0251	z	0300	{	0117	|	0320	}	0137	¬	0007	DEL
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0200	0040	DS	0041	SOS	0042	FS	0043	WUS	0044	BYP	0025	NL	0006	RNL	0027	POC
+0210	0050	SA	0051	SFE	0052	SM	0053	CSP	0054	MFA	0011	SPS	0012	RPT	0033	CU1
+0220	0060		0061		0032	UBS	0063	IR	0064	PP	0065	TRN	0066	NBS	0010	GE
+0230	0070	SBS	0071	IT	0072	RFF	0073	CU3	0004	SEL	0024	RES	0076		0341	
+0240	0101		0102		0103		0104		0105		0106		0107		0110	
+0250	0111		0121		0122		0123		0124		0125		0126		0127	
+0260	0130		0131		0142		0143		0144		0145		0146		0147	
+0270	0150		0151		0160		0161		0162		0163		0164		0165	
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0300	0166		0167		0170		0200		0212		0213		0214		0215	
+0310	0216		0217		0220		0152	¦	0233		0234		0235		0236	
+0320	0237		0240		0252		0253		0254		0112	¢	0256		0257	
+0330	0260		0261		0262		0263		0264		0265		0266		0267	
+0340	0270		0271		0272		0273		0274		0241		0276		0277	
+0350	0312		0313		0314	\fB⑀\fP	0315		0316	\fB⑂\fP	0317		0332		0333	
+0360	0334		0335		0336		0337		0352		0353		0354	\fB⑁\fP	0355	
+0370	0356		0357		0372	|	0373		0374		0375		0376		0377	EO
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+.TE
 .bp
 .sp
+.sp
 .ce 1
 \fBTable 4-8: ASCII to IBM EBCDIC Conversion\fR
+.sp
+.TS
+centre;
+l   cB sB cB sB cB sB cB sB cB sB cB sB cB sB cB sB
+l    _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _
+nB | n l | n l | n l | n l | n l | n l | n l | n l |
+.
+\&	0	1	2	3	4	5	6	7
+\&
+0000	0000	NUL	0001	SOH	0002	STX	0003	ETX	0067	EOT	0055	ENQ	0056	ACK	0057	BEL
+0010	0026	BS	0005	HT	0045	LF	0013	VT	0014	FF	0015	CR	0016	SO	0017	SI
+0020	0020	DLE	0021	DC1	0022	DC2	0023	DC3	0074	DC4	0075	NAK	0062	SYN	0046	ETB
+0030	0030	CAN	0031	EM	0077	SUB	0047	ESC	0034	IFS	0035	IGS	0036	IRS	0037	ITB
+0040	0100	Sp	0132	!	0177	"	0173	#	0133	$	0154	%	0120	&	0175	\[aq]
+0050	0115	(	0135	)	0134	*	0116	+	0153	,	0140	\-	0113	.	0141	/
+0060	0360	0	0361	1	0362	2	0363	3	0364	4	0365	5	0366	6	0367	7
+0070	0370	8	0371	9	0172	:	0136	;	0114	<	0176	\&=	0156	>	0157	?
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0100	0174	@	0301	A	0302	B	0303	C	0304	D	0305	E	0306	F	0307	G
+0110	0310	H	0311	I	0321	J	0322	K	0323	L	0324	M	0325	N	0326	O
+0120	0327	P	0330	Q	0331	R	0342	S	0343	T	0344	U	0345	V	0346	W
+0130	0347	X	0350	Y	0351	Z	0255	[	0340	\e	0275	]	0137	¬	0155	\&_
+0140	0171	`	0201	a	0202	b	0203	c	0204	d	0205	e	0206	f	0207	g
+0150	0210	h	0211	i	0221	j	0222	k	0223	]	0224	m	0225	n	0226	o
+0160	0227	p	0230	q	0231	r	0242	s	0243	t	0244	u	0245	v	0246	w
+0170	0247	x	0250	y	0251	z	0300	{	0117	|	0320	}	0241		0007	DEL
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0200	0040	DS	0041	SOS	0042	FS	0043	WUS	0044	BYP	0025	NL	0006	RNL	0027	POC
+0210	0050	SA	0051	SFE	0052	SM	0053	CSP	0054	MFA	0011	SPS	0012	RPT	0033	CU1
+0220	0060		0061		0032	UBS	0063	IR	0064	PP	0065	TRN	0066	NBS	0010	GE
+0230	0070	SBS	0071	IT	0072	RFF	0073	CU3	0004	SEL	0024	RES	0076		0341	
+0240	0101		0102		0103		0104		0105		0106		0107		0110	
+0250	0111		0121		0122		0123		0124		0125		0126		0127	
+0260	0130		0131		0142		0143		0144		0145		0146		0147	
+0270	0150		0151		0160		0161		0162		0163		0164		0165	
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+0300	0166		0167		0170		0200		0212		0213		0214		0215	
+0310	0216		0217		0220		0232		0233		0234		0235		0236	
+0320	0237		0240		0252		0253		0254		0255	[	0256		0257	
+0330	0260		0261		0262		0263		0264		0265		0266		0267	
+0340	0270		0271		0272		0273		0274		0275	]	0276		0277	
+0350	0312		0313		0314	\fB⑀\fP	0315		0316	\fB⑂\fP	0317		0332		0333	
+0360	0334		0335		0336		0337		0352		0353		0354	\fB⑁\fP	0355	
+0370	0356		0357		0372	|	0373		0374		0375		0376		0377	EO
+\&	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_	_
+.TE
+.IP
+.SB Note:
+.SM Characters 0352\[->]0314, 0354\[->]0316, 0366\[->]0354 \
+are derived from those in \
+ISO 2033:1983 Coding of machine readable characters (MICR and OCR) \
+defining character sets with symbols used by \
+Magnetic Ink Character Recognition and Optical Character Recognition systems:
+.RS
+.TP
+.BR '⑀'
+0x3C/0074 table 0352\[->]0314 U+2440 OCR HOOK
+.TP
+.BR '⑂'
+0x5D/0135 table 0354\[->]0316 U+2442 OCR FORK
+.TP
+.BR '⑁'
+0x3E/0076 table 0366\[->]0354 U+2441 OCR CHAIR
+.PP
+.SM showing characters from the \
+Unicode Optical Character Recognition block U+2440\(enU+245F.
+.P
+.SM On cheques, bank code and cheque number are terminated with \c
+.BR '⑀' ,
+.SM account number and cheque type number are terminated with \c
+.BR '⑁' ,
+.SM and amount is terminated with \c
+.BR '⑂' .
+.RE
 .SH STDIN
 If no
 .BR if =
@@ -623,7 +745,9 @@ cells in the tables differ in such a way that:
 .IP " 1." 4
 EBCDIC 0112 (\c
 .BR '\(ct' )
-and 0152 (broken pipe) do not appear in the table.
+and 0152 (\c
+.BR '\(bb' " broken pipe)"
+do not appear in the table.
 .IP " 2." 4
 EBCDIC 0137 (\c
 .BR '\(no' )
@@ -664,7 +788,9 @@ in cell 0176.
 .P
 \0\0\0\0That displaced EBCDIC 0232 (no graphic) in cell 0136.
 .P
-\0\0\0\0That replaced EBCDIC 0152 (broken pipe) in cell 0313.
+\0\0\0\0That replaced EBCDIC 0152 (\c
+.BR '\(bb' " broken pipe)"
+in cell 0313.
 .P
 EBCDIC 0255 (\c
 .BR '[' )
-- 
2.39.0

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2355 bytes --]

Hi Brian!

On 2023-08-13 23:01, Brian Inglis wrote:
> I have an OpenGroup/UNIX.org/Austin Group/POSIX account,
> so added the missing ASCII-EBCDIC tables by copying from the POSIX PDF,
> as copying data is fair use, and the man page copy itself is authorized.
> 
> As an aside to that, those ASCII-EBCDIC tables support characters from
> the old ISO 2033:1983 MICR/OCR character sets now in Unicode OCR block
> U+2440-U+245F, which appears only in a few fonts like Unifont and SIL
> LastResort (and MS Segoe UI Symbol), and are still available as TTF
> (some font formats and support are being dropped in favour of OTF).
> 
> They appear normal on my screen running 'man 1p dd' on my system which
> has those fallback fonts installed.
> 
> Is it sufficient to run the groff addition install-font.sh script on
> those fonts and add them to the config as .special, or is anything else
> required to register and render the glyphs on other devices?
> 
> Or should I take this up on the groff list? 

I guess Branden is reading this, so he'll be able to better answer you.
I have little clue of those things.

> 
> Signed-off-by: Brian Inglis <Brian.Inglis@Shaw.ca>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=215971

Regarding the man-pages-posix project, I don't have in mind releasing any
soon.  In fact, I don't even maintain it, to be honest.  It just happens
that I'm the one with the keys to it.

The problem is that it's generated from scripts, and I don't know how that
project is organized.  I could try to get it working, but it would take
some work, and I don't feel motivated to do it.

And also, I don't even have the sources, which makes things more complex.

I wish that POSIX allowed us to have a copy of the original source code
of the POSIX manual in the git repository.  With that, I'd find it more
interesting to maintain the project again.

I'd also like to know what's the original source code of POSIX's manual,
because it may very well be roff(7).  If that happens to be true, I'd
like to have access to that source, instead of the HTML.

Would you mind forwarding my rage towards the Open group, which IMO is not
so open?

Thanks,
Alex

P.S.: Long live bzero(3p)!

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

At 2023-08-13T23:30:30+0200, Alejandro Colomar wrote:
> And also, I don't even have the sources, which makes things more
> complex.
> 
> I wish that POSIX allowed us to have a copy of the original source
> code of the POSIX manual in the git repository.  With that, I'd find
> it more interesting to maintain the project again.
> 
> I'd also like to know what's the original source code of POSIX's
> manual, because it may very well be roff(7).  If that happens to be
> true, I'd like to have access to that source, instead of the HTML.

My understanding from hermetic comments to the Austin Group mailing list
over the years is that:

1. they have used groff for many years (a decade or more);
2. they don't use man(7) for their man pages (I was told this directly);

and

3. they use (a customized version of) mm(7)--or I _think_ I saw someone
   say this, but I have no citation and I am not even sure it was an
   Open Group employee who claimed it.

We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
they will be cross with me about that.  Even if they didn't rely on any
erstwhile misbehavior, the source churned, some internals changed, and
if they patched the package, I wouldn't count on the patches still
applying cleanly.

> Would you mind forwarding my rage towards the Open group, which IMO is
> not so open?

Maybe scrape off the rage first, or you might get a response from Robert
Elz, who is even more cantankerous and writes at even greater length
than I do.  ;-)

Some time ago I solicited bug reports against groff from them.  So far,
nothing, unless they filed anonymously.

Regards,
Branden

[1] https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&summary=&submitted_by=0&resolution_id=1&assigned_to=0&bug_group_id=0&status_id=3&severity=0&category_id=121&plan_release_id=103&history_search=0&history_field=0&history_event=modified&history_date_dayfd=13&history_date_monthfd=8&history_date_yearfd=2023&chunksz=50&spamscore=5&boxoptionwanted=1#options

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2752 bytes --]

[+= Eric]

Hi Branden, Eric,

On 2023-08-14 00:20, G. Branden Robinson wrote:
> At 2023-08-13T23:30:30+0200, Alejandro Colomar wrote:
>> And also, I don't even have the sources, which makes things more
>> complex.
>>
>> I wish that POSIX allowed us to have a copy of the original source
>> code of the POSIX manual in the git repository.  With that, I'd find
>> it more interesting to maintain the project again.
>>
>> I'd also like to know what's the original source code of POSIX's
>> manual, because it may very well be roff(7).  If that happens to be
>> true, I'd like to have access to that source, instead of the HTML.
> 
> My understanding from hermetic comments to the Austin Group mailing list
> over the years is that:
> 
> 1. they have used groff for many years (a decade or more);
> 2. they don't use man(7) for their man pages (I was told this directly);
> 
> and
> 
> 3. they use (a customized version of) mm(7)--or I _think_ I saw someone
>    say this, but I have no citation and I am not even sure it was an
>    Open Group employee who claimed it.

I'd love to have the ms(7) source then.  That way I would have a reason
to learn ms(7).  :)
It would certainly be better than the HTML files.  It would be
interesting to adapt the Linux man-pages build system to also support
ms(7) pages.

> 
> We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
> they will be cross with me about that.  Even if they didn't rely on any
> erstwhile misbehavior, the source churned, some internals changed, and
> if they patched the package, I wouldn't count on the patches still
> applying cleanly.
> 
>> Would you mind forwarding my rage towards the Open group, which IMO is
>> not so open?
> 
> Maybe scrape off the rage first, or you might get a response from Robert
> Elz, who is even more cantankerous and writes at even greater length
> than I do.  ;-)

I promise to scrape the rage if I get a name and an email of who to talk
to.  Maybe Eric can help.  :)

Cheers,
Alex

> 
> Some time ago I solicited bug reports against groff from them.  So far,
> nothing, unless they filed anonymously.
> 
> Regards,
> Branden
> 
> [1] https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&summary=&submitted_by=0&resolution_id=1&assigned_to=0&bug_group_id=0&status_id=3&severity=0&category_id=121&plan_release_id=103&history_search=0&history_field=0&history_event=modified&history_date_dayfd=13&history_date_monthfd=8&history_date_yearfd=2023&chunksz=50&spamscore=5&boxoptionwanted=1#options

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2893 bytes --]

On 2023-08-14 00:27, Alejandro Colomar wrote:
> [+= Eric]
> 
> Hi Branden, Eric,
> 
> On 2023-08-14 00:20, G. Branden Robinson wrote:
>> At 2023-08-13T23:30:30+0200, Alejandro Colomar wrote:
>>> And also, I don't even have the sources, which makes things more
>>> complex.
>>>
>>> I wish that POSIX allowed us to have a copy of the original source
>>> code of the POSIX manual in the git repository.  With that, I'd find
>>> it more interesting to maintain the project again.
>>>
>>> I'd also like to know what's the original source code of POSIX's
>>> manual, because it may very well be roff(7).  If that happens to be
>>> true, I'd like to have access to that source, instead of the HTML.
>>
>> My understanding from hermetic comments to the Austin Group mailing list
>> over the years is that:
>>
>> 1. they have used groff for many years (a decade or more);
>> 2. they don't use man(7) for their man pages (I was told this directly);
>>
>> and
>>
>> 3. they use (a customized version of) mm(7)--or I _think_ I saw someone
>>    say this, but I have no citation and I am not even sure it was an
>>    Open Group employee who claimed it.
> 
> I'd love to have the ms(7) source then.  That way I would have a reason
> to learn ms(7).  :)

Oops, mm(7).

> It would certainly be better than the HTML files.  It would be
> interesting to adapt the Linux man-pages build system to also support
> ms(7) pages.
> 
>>
>> We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
>> they will be cross with me about that.  Even if they didn't rely on any
>> erstwhile misbehavior, the source churned, some internals changed, and
>> if they patched the package, I wouldn't count on the patches still
>> applying cleanly.
>>
>>> Would you mind forwarding my rage towards the Open group, which IMO is
>>> not so open?
>>
>> Maybe scrape off the rage first, or you might get a response from Robert
>> Elz, who is even more cantankerous and writes at even greater length
>> than I do.  ;-)
> 
> I promise to scrape the rage if I get a name and an email of who to talk
> to.  Maybe Eric can help.  :)
> 
> Cheers,
> Alex
> 
>>
>> Some time ago I solicited bug reports against groff from them.  So far,
>> nothing, unless they filed anonymously.
>>
>> Regards,
>> Branden
>>
>> [1] https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&summary=&submitted_by=0&resolution_id=1&assigned_to=0&bug_group_id=0&status_id=3&severity=0&category_id=121&plan_release_id=103&history_search=0&history_field=0&history_event=modified&history_date_dayfd=13&history_date_monthfd=8&history_date_yearfd=2023&chunksz=50&spamscore=5&boxoptionwanted=1#options
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Eric Blake]

On Mon, Aug 14, 2023 at 12:29:23AM +0200, Alejandro Colomar wrote:
> On 2023-08-14 00:27, Alejandro Colomar wrote:
> > [+= Eric]
> > 
> > Hi Branden, Eric,
> > 
> > On 2023-08-14 00:20, G. Branden Robinson wrote:
> >> At 2023-08-13T23:30:30+0200, Alejandro Colomar wrote:
> >>> And also, I don't even have the sources, which makes things more
> >>> complex.
> >>>
> >>> I wish that POSIX allowed us to have a copy of the original source
> >>> code of the POSIX manual in the git repository.  With that, I'd find
> >>> it more interesting to maintain the project again.
> >>>
> >>> I'd also like to know what's the original source code of POSIX's
> >>> manual, because it may very well be roff(7).  If that happens to be
> >>> true, I'd like to have access to that source, instead of the HTML.

I'm not sure if the POSIX original is quite roff, but I just confirmed
that I have access to the repository where Issue 8 is being worked on
(it required me to have an Open Group login, so you may not be able to
access this page):

https://gitlab.opengroup.org/the-austin-group/sus_base/-/commits/Issue8/

I can also recommend contacting Andrew Josey (ajosey@opengroup.org -
admin) and/or Geoff Clare (gwc@opengroup.org - most active committer
in that project) of the Austin Group, to figure out if there is a way
for you to get access to that repository.

> >>
> >> My understanding from hermetic comments to the Austin Group mailing list
> >> over the years is that:
> >>
> >> 1. they have used groff for many years (a decade or more);
> >> 2. they don't use man(7) for their man pages (I was told this directly);
> >>
> >> and
> >>
> >> 3. they use (a customized version of) mm(7)--or I _think_ I saw someone
> >>    say this, but I have no citation and I am not even sure it was an
> >>    Open Group employee who claimed it.
> > 
> > I'd love to have the ms(7) source then.  That way I would have a reason
> > to learn ms(7).  :)
> 
> Oops, mm(7).

Based on my quick perusal, it is indeed .mm files that form the bulk
of the content in that repository.  For example, even if you can't
access the repository yet, I don't think there is any problem under
the fair use doctrine for sharing a snippet of a recent commit:

| commit 7fad34c5f734d7a54c6a5fa8124baf819c2b8de5
| Author: Geoff Clare <gwc@opengroup.org>
| Date:   Tue Aug 8 10:52:54 2023 +0100
| 
|     Applied bug 1741
| 
| diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
| index 13af2a5..339bfc5 100644
| --- a/Base/Text/Functions/getlocalename_l.mm
| +++ b/Base/Text/Functions/getlocalename_l.mm
| @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
|  .sE
|  .yE
|  .mH DESCRIPTION
| -The
| +If
| +.Ar category
| +is not LC_ALL, the
|  .Fn getlocalename_l
|  function shall return the locale name for the given locale category of
|  the locale object
| ...

> > It would certainly be better than the HTML files.  It would be
> > interesting to adapt the Linux man-pages build system to also support
> > ms(7) pages.
> > 
> >>
> >> We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
> >> they will be cross with me about that.  Even if they didn't rely on any
> >> erstwhile misbehavior, the source churned, some internals changed, and
> >> if they patched the package, I wouldn't count on the patches still
> >> applying cleanly.
> >>
> >>> Would you mind forwarding my rage towards the Open group, which IMO is
> >>> not so open?
> >>
> >> Maybe scrape off the rage first, or you might get a response from Robert
> >> Elz, who is even more cantankerous and writes at even greater length
> >> than I do.  ;-)
> > 
> > I promise to scrape the rage if I get a name and an email of who to talk
> > to.  Maybe Eric can help.  :)

I'm not forwarding this email directly, but I'm happy to be a liaison
to connect you with other Austin Group members.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3445 bytes --]

Hi Eric!

On 2023-08-17 17:23, Eric Blake wrote:
> 
> I'm not sure if the POSIX original is quite roff, but I just confirmed
> that I have access to the repository where Issue 8 is being worked on
> (it required me to have an Open Group login, so you may not be able to
> access this page):
> 
> https://gitlab.opengroup.org/the-austin-group/sus_base/-/commits/Issue8/
> 
> I can also recommend contacting Andrew Josey (ajosey@opengroup.org -
> admin) and/or Geoff Clare (gwc@opengroup.org - most active committer
> in that project) of the Austin Group, to figure out if there is a way
> for you to get access to that repository.
> 
>>>>
>>>> My understanding from hermetic comments to the Austin Group mailing list
>>>> over the years is that:
>>>>
>>>> 1. they have used groff for many years (a decade or more);
>>>> 2. they don't use man(7) for their man pages (I was told this directly);
>>>>
>>>> and
>>>>
>>>> 3. they use (a customized version of) mm(7)--or I _think_ I saw someone
>>>>    say this, but I have no citation and I am not even sure it was an
>>>>    Open Group employee who claimed it.
>>>
>>> I'd love to have the ms(7) source then.  That way I would have a reason
>>> to learn ms(7).  :)
>>
>> Oops, mm(7).
> 
> Based on my quick perusal, it is indeed .mm files that form the bulk
> of the content in that repository.  For example, even if you can't
> access the repository yet, I don't think there is any problem under
> the fair use doctrine for sharing a snippet of a recent commit:
> 
> | commit 7fad34c5f734d7a54c6a5fa8124baf819c2b8de5
> | Author: Geoff Clare <gwc@opengroup.org>
> | Date:   Tue Aug 8 10:52:54 2023 +0100
> | 
> |     Applied bug 1741
> | 
> | diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
> | index 13af2a5..339bfc5 100644
> | --- a/Base/Text/Functions/getlocalename_l.mm
> | +++ b/Base/Text/Functions/getlocalename_l.mm
> | @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
> |  .sE
> |  .yE
> |  .mH DESCRIPTION
> | -The
> | +If
> | +.Ar category
> | +is not LC_ALL, the
> |  .Fn getlocalename_l
> |  function shall return the locale name for the given locale category of
> |  the locale object
> | ...
> 
>>> It would certainly be better than the HTML files.  It would be
>>> interesting to adapt the Linux man-pages build system to also support
>>> ms(7) pages.
>>>
>>>>
>>>> We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
>>>> they will be cross with me about that.  Even if they didn't rely on any
>>>> erstwhile misbehavior, the source churned, some internals changed, and
>>>> if they patched the package, I wouldn't count on the patches still
>>>> applying cleanly.
>>>>
>>>>> Would you mind forwarding my rage towards the Open group, which IMO is
>>>>> not so open?
>>>>
>>>> Maybe scrape off the rage first, or you might get a response from Robert
>>>> Elz, who is even more cantankerous and writes at even greater length
>>>> than I do.  ;-)
>>>
>>> I promise to scrape the rage if I get a name and an email of who to talk
>>> to.  Maybe Eric can help.  :)
> 
> I'm not forwarding this email directly, but I'm happy to be a liaison
> to connect you with other Austin Group members.
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Brian Inglis]

On 2023-08-17 09:23, Eric Blake wrote:
> On Mon, Aug 14, 2023 at 12:29:23AM +0200, Alejandro Colomar wrote:
>> On 2023-08-14 00:27, Alejandro Colomar wrote:
>>> On 2023-08-14 00:20, G. Branden Robinson wrote:
>>>> At 2023-08-13T23:30:30+0200, Alejandro Colomar wrote:
>>>>> And also, I don't even have the sources, which makes things more
>>>>> complex.
>>>>>
>>>>> I wish that POSIX allowed us to have a copy of the original source
>>>>> code of the POSIX manual in the git repository.  With that, I'd find
>>>>> it more interesting to maintain the project again.
>>>>>
>>>>> I'd also like to know what's the original source code of POSIX's
>>>>> manual, because it may very well be roff(7).  If that happens to be
>>>>> true, I'd like to have access to that source, instead of the HTML.
> 
> I'm not sure if the POSIX original is quite roff, but I just confirmed
> that I have access to the repository where Issue 8 is being worked on
> (it required me to have an Open Group login, so you may not be able to
> access this page):
> 
> https://gitlab.opengroup.org/the-austin-group/sus_base/-/commits/Issue8/
> 
> I can also recommend contacting Andrew Josey (ajosey@opengroup.org -
> admin) and/or Geoff Clare (gwc@opengroup.org - most active committer
> in that project) of the Austin Group, to figure out if there is a way
> for you to get access to that repository.

Hi Eric,

I've had an OG login for a few years and some Austin Group material access, but 
can only see OG gitlab Projects, and Austin Group group, but no projects or 
subgroups, so that appears to be separately authorised - perhaps by repo and 
login or via Plato visibility level: the Mailing List appears to be Public level 
and Drafts are subject to terms.

>>>> My understanding from hermetic comments to the Austin Group mailing list
>>>> over the years is that:
>>>>
>>>> 1. they have used groff for many years (a decade or more);
>>>> 2. they don't use man(7) for their man pages (I was told this directly);
>>>>
>>>> and
>>>>
>>>> 3. they use (a customized version of) mm(7)--or I _think_ I saw someone
>>>>     say this, but I have no citation and I am not even sure it was an
>>>>     Open Group employee who claimed it.
>>>
>>> I'd love to have the ms(7) source then.  That way I would have a reason
>>> to learn ms(7).  :)
>>
>> Oops, mm(7).
> 
> Based on my quick perusal, it is indeed .mm files that form the bulk
> of the content in that repository.  For example, even if you can't
> access the repository yet, I don't think there is any problem under
> the fair use doctrine for sharing a snippet of a recent commit:
> 
> | commit 7fad34c5f734d7a54c6a5fa8124baf819c2b8de5
> | Author: Geoff Clare <gwc@opengroup.org>
> | Date:   Tue Aug 8 10:52:54 2023 +0100
> |
> |     Applied bug 1741
> |
> | diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
> | index 13af2a5..339bfc5 100644
> | --- a/Base/Text/Functions/getlocalename_l.mm
> | +++ b/Base/Text/Functions/getlocalename_l.mm
> | @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
> |  .sE
> |  .yE
> |  .mH DESCRIPTION
> | -The
> | +If
> | +.Ar category
> | +is not LC_ALL, the
> |  .Fn getlocalename_l
> |  function shall return the locale name for the given locale category of
> |  the locale object
> | ...
> 
>>> It would certainly be better than the HTML files.  It would be
>>> interesting to adapt the Linux man-pages build system to also support
>>> ms(7) pages.
>>>>
>>>> We fixed a bunch of bugs in GNU mm for groff 1.23.0.[1]  I wonder if
>>>> they will be cross with me about that.  Even if they didn't rely on any
>>>> erstwhile misbehavior, the source churned, some internals changed, and
>>>> if they patched the package, I wouldn't count on the patches still
>>>> applying cleanly.

Perhaps originally from AT&T 6th edition sources in mm?

>>> I promise to scrape the rage if I get a name and an email of who to talk
>>> to.  Maybe Eric can help.  :)

I've found OG and Austin Group info and docs to be freely accessible for 
personal use (not necessarily easy to navigate and find), unlike WG14 C F/DIS 
(Final/Draft Intl Std) which are (now) locked in password protected zips prior 
to ISO publication.

> I'm not forwarding this email directly, but I'm happy to be a liaison
> to connect you with other Austin Group members.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1677 bytes --]

Hi Eric!

On 2023-08-17 17:23, Eric Blake wrote:

[...]

> I can also recommend contacting Andrew Josey (ajosey@opengroup.org -
> admin) and/or Geoff Clare (gwc@opengroup.org - most active committer
> in that project) of the Austin Group, to figure out if there is a way
> for you to get access to that repository.

Thank you very much!  Done.

[...]

> 
> Based on my quick perusal, it is indeed .mm files that form the bulk
> of the content in that repository.  For example, even if you can't
> access the repository yet, I don't think there is any problem under
> the fair use doctrine for sharing a snippet of a recent commit:
> 
> | commit 7fad34c5f734d7a54c6a5fa8124baf819c2b8de5
> | Author: Geoff Clare <gwc@opengroup.org>
> | Date:   Tue Aug 8 10:52:54 2023 +0100
> | 
> |     Applied bug 1741
> | 
> | diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
> | index 13af2a5..339bfc5 100644
> | --- a/Base/Text/Functions/getlocalename_l.mm
> | +++ b/Base/Text/Functions/getlocalename_l.mm
> | @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
> |  .sE
> |  .yE
> |  .mH DESCRIPTION
> | -The
> | +If
> | +.Ar category
> | +is not LC_ALL, the
> |  .Fn getlocalename_l
> |  function shall return the locale name for the given locale category of
> |  the locale object
> | ...
> 

[...]

> 
> I'm not forwarding this email directly, but I'm happy to be a liaison
> to connect you with other Austin Group members.

:)

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

At 2023-08-17T10:23:55-0500, Eric Blake wrote:
> | diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
> | index 13af2a5..339bfc5 100644
> | --- a/Base/Text/Functions/getlocalename_l.mm
> | +++ b/Base/Text/Functions/getlocalename_l.mm
> | @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
> |  .sE
> |  .yE
> |  .mH DESCRIPTION
> | -The
> | +If
> | +.Ar category
> | +is not LC_ALL, the
> |  .Fn getlocalename_l
> |  function shall return the locale name for the given locale category of
> |  the locale object

Thanks for the peek behind the curtain, Eric!

I infer that the Open Group's use of mm has an extensive layer of
bespoke macros supplementing it (not really a suprise).  _None_ of the
macro names we see above appears in Documenter's Workbench troff 3.3 mm
or GNU troff.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[Eric Blake]

On Thu, Aug 17, 2023 at 06:49:03PM -0500, G. Branden Robinson wrote:
> At 2023-08-17T10:23:55-0500, Eric Blake wrote:
> > | diff --git a/Base/Text/Functions/getlocalename_l.mm b/Base/Text/Functions/getlocalename_l.mm
> > | index 13af2a5..339bfc5 100644
> > | --- a/Base/Text/Functions/getlocalename_l.mm
> > | +++ b/Base/Text/Functions/getlocalename_l.mm
> > | @@ -12,7 +12,9 @@ const char *getlocalename_l(int \f6category\fP, locale_t \f6locobj\fP);
> > |  .sE
> > |  .yE
> > |  .mH DESCRIPTION
> > | -The
> > | +If
> > | +.Ar category
> > | +is not LC_ALL, the
> > |  .Fn getlocalename_l
> > |  function shall return the locale name for the given locale category of
> > |  the locale object
> 
> Thanks for the peek behind the curtain, Eric!
> 
> I infer that the Open Group's use of mm has an extensive layer of
> bespoke macros supplementing it (not really a suprise).  _None_ of the
> macro names we see above appears in Documenter's Workbench troff 3.3 mm
> or GNU troff.

Indeed, there is another git repository containing a (rather sizable)
set of tooling for converting sus_base into both .pdf and .html
formats.  Among other things,

https://gitlab.opengroup.org/the-austin-group/sus_tools/-/blob/master/tools/macros.xo

is over 43kB, containing custom macros such as:

| ..
| .\" Heading on man page: really a list item
| .de mH
| .\".P
| .br
| .ne 4v
| .LI "\f3\\$1\f1"
| .br
| ..

Supposedly the process is fairly automated, though (but I haven't
tried it myself); the README for that project states:

| For example, to do a build of SUS_Base from scratch:
| 
|     Check out sus_tools and sus_base from gitlab
|     cd sus_tools
|     ./build-docker.sh
|     cd ../sus_base
|     ../sus_tools/run-docker.sh sh -c 'cd /build/Base && /tdocs/build/tools/build'

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: [PATCH] man-pages-posix-2017/man1p/dd.1p: added missing ASCII-EBCDIC tables

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

Hi Brian,

At 2023-08-13T15:01:44-0600, Brian Inglis wrote:
> I have an OpenGroup/UNIX.org/Austin Group/POSIX account, so added the
> missing ASCII-EBCDIC tables by copying from the POSIX PDF, as copying
> data is fair use, and the man page copy itself is authorized.
> 
> As an aside to that, those ASCII-EBCDIC tables support characters from
> the old ISO 2033:1983 MICR/OCR character sets now in Unicode OCR block
> U+2440-U+245F, which appears only in a few fonts like Unifont and SIL
> LastResort (and MS Segoe UI Symbol), and are still available as TTF
> (some font formats and support are being dropped in favour of OTF).
> 
> They appear normal on my screen running 'man 1p dd' on my system which
> has those fallback fonts installed.
> 
> Is it sufficient to run the groff addition install-font.sh script on
> those fonts and add them to the config as .special, or is anything
> else required to register and render the glyphs on other devices?

That sounds correct to me.

> Or should I take this up on the groff list?

See if the gropdf(1) and/or grops(1) pages in groff 1.23.0 get the
essential information across; if either one doesn't (independently of
the other), please report a bug against groff.

> +.sp

Just use a paragraphing macro call here, like `.P`.

> +.TS
> +centre;
> +l   cB sB cB sB cB sB cB sB cB sB cB sB cB sB cB sB
> +l    _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _
> +nB | n l | n l | n l | n l | n l | n l | n l | n l |
> +.
> +\&	0	1	2	3	4	5	6	7
> +\&
> +0000	0000	NUL	0001	SOH	0002	STX	0003	ETX	0067	EOT	0055	ENQ	0056	ACK	0057	BEL
[...]

I guess it's hard to change the tab character for this ultra-wide table
since every printable ASCII character is represented in it, and tbl
affords no mechanism to escape the tab character.

> +.TE
> +.IP
> +.SB Note:

There's no reason to use `SB` (a SunOS extension) anymore since groff
1.22.4 (2018) and mandoc 1.14.2 (2017).

.IP
.SM
.B Note:

will work fine.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]