| Newsgroups |
gmane.text.unicode.general |
| Message-ID |
<[email protected]> |
--2QDQUPDKSBALVUIRXNSYSnhgwp
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
In UTC 187 Minutes, " Asmus Freytag noted that the fact that lists of t=
hings existed in the past does not make these things plain text. Ned Holbro=
ok pointed out that the purported issue occurs in a closed system, not in p=
ublic interchange. ". However, the arguments in the proposal do not mer=
ely hinge on the encodings being lists of characters, but specifically poin=
ts out methods to interchange text, including an example of copying termina=
l output and pasting to Notepad, where the copying invokes the mapping of t=
he current terminal codepage to UCS-2 (as is CHAR_INFO compatible) and the =
pasting writes it into plain text. Win32 is also not a closed system, as Wi=
n32 can capture the tiles of the output of Windows 3.1 Arabic DOS/Win16 pro=
grams and Windows 95/98/ME Arabic DOS/Win16/Win32 programs, but Win32 can a=
lso interact with public text interchange systems by reading and writing to=
files and network. I'm not saying that Unicode absolutely must include=
those characters, but those kinds of misleading claims are causing users t=
o misunderstand what the proposal is about, and I don't want Unicode to=
be relying on uninformed decisions to evaluate proposals. Dnia 18 kwietni=
a 2026 13:36 [email protected] via Unicode < [email protected]=
.org > napisa=C5=82(a): The SEW subsequently explained that the actual =
reason is due to insufficient evidence of user community that would need to=
use the resulting mapping. Despite Win32 being a highly popular platform w=
ith plenty of backwards compatibility and native UCS-2 terminal support, th=
e specific use cases of installing codepages into Windows NT and using term=
inal tiles from Windows 3.1/95/98/ME are not sufficiently documented, makin=
g it difficult for any user communities to form around it. So it seems like=
the idea of standardizing legacy Arabic terminal BMP mappings is a dead en=
d for now. Dnia 17 kwietnia 2026 22:59 [email protected] via Unicode=
< [email protected] > napisa=C5=82(a): The Recommendations =
in L2/26-100 claim that Microsoft's documentation of legacy Arabic enco=
dings is available at https://learn.microsoft.com/en-us/typography/legacy/l=
egacy_arabic_fonts. However, that article only demonstrates two encodings o=
f TrueType fonts, which are used in Windows 3.1 but are completely differen=
t from the eight terminal encodings. Unlike the TrueType encodings which re=
present internal shaping mappings and are not used for text interchange, th=
e terminal encodings have been demonstrated to be directly used in text int=
erchange through int 10h and ReadConsoleOutputA/WriteConsoleOutputA as alre=
ady demonstrated in L2/26-077. The Recommendations also claim that the prop=
osal does not demonstrate any need for interchange or encoding, but the pro=
posal actually demonstrated such a need due to the logical extension of the=
Win32 terminal API to the functions ReadConsoleOutputW/WriteConsoleOutputW=
, which are in Windows NT and may be used on the output of previously ran p=
rograms (including those that used the legacy Arabic terminal encodings), w=
hich given the CHAR_INFO structure, therefore implies a need for all the ti=
les to map to BMP for interchange. I'm not objecting to the SEW's c=
onclusion of "Users are expected to use PUA.", which can indeed be =
used to provide a mapping even if not standardized, but the reasoning given=
was flawed. Dnia 09 stycznia 2026 17:25 [email protected] < piotr=
[email protected] > napisa=C5=82(a): The following Win32 C code will outp=
ut 256 characters in system console codepage into the character grid, captu=
re those character tiles in UCS-2 if possible, and then output the current =
console codepage number. #include <windows.h> #include <stdio.h=
> int main(){ HANDLE hConsole=3DGetStdHandle(STD_OUTPUT_HANDLE); CHAR=
_INFO screen[256]; COORD size=3D{16,16,}; COORD pos=3D{0,0,}; SMALL_RECT=
rect=3D{0,0,15,15,}; for(int i=3D0;i<256;i++){ screen[i].Attributes=
=3D0xF0; screen[i].Char.AsciiChar=3Di; } WriteConsoleOutputA(hConsole,sc=
reen,size,pos,&rect); CHAR_INFO screenu[256]; if(ReadConsoleOutputW(h=
Console,screenu,size,pos,&rect)){ for(int i=3D0;i<256;i++) printf(&=
#34;%04X ",screenu[i].Char.UnicodeChar); } else{ printf("error %=
08X\n",GetLastError()); } printf("codepage %u",GetConsoleOutp=
utCP()); } In most cases, whenever a legacy Win32 codepage is used, the =
application can run on Windows NT to capture the UCS-2 mapping of those cha=
racter cells to the BMP (although for CJK codepages a more complex setup wo=
uld be necessary due to thousands of fullwidth characters with 2-byte seque=
nces). However, in Arabic versions of Windows 9x (95/98/ME) the resulting=
character set has many presentation forms that are not in Unicode. This is=
the result when running on Windows ME:=C2=A0 i.imgur.com https://i.imgur.c=
om/QFm3SkI.png =C2=A0in 10=C3=9720 font, i.imgur.com https://i.imgur.com/K=
UbLQ0A.png =C2=A0in 10=C3=9718 font (same result also appears in Windows 95=
/98). 5=C3=9712, 7=C3=9712, 8=C3=9712, 10=C3=9718, 10=C3=9720, and 12=C3=97=
16 bitmap fonts have been attested with that character set (VGAOEM.FON, 851=
4OEM.FON, DOSAPP.FON). The 10=C3=9720 font has slightly different mapping t=
han the other sizes: 0x93 is =C3=B6 instead of =C3=B4, and 0x97 is missing =
(causing the following characters on the same line to be drawn at the wrong=
position). It also claims to be using codepage 720, but many characters di=
ffer from their CP720 mappings, including the bundled=C2=A0CP_720.NLS mappi=
ngs (for example, =D9=80 (U+0640 ARABIC TATWEEL) is 0x95 in CP720, but in t=
he console 0x95 is =D8=B4 instead, and the tatweel is at 0xFF). On Windows =
9x,=C2=A0ReadConsoleOutputW is not supported so the UCS-2 mappings of the c=
onsole character tiles cannot be captured (error 0x00000078 ERROR_CALL_NOT_=
IMPLEMENTED). When that program runs on Arabic versions of Windows NT, th=
e visual output is of the CP437 character set if one of the bundled bitmap =
fonts is used ( i.imgur.com https://i.imgur.com/RxjtxMH.png ), or the CP720=
set if Lucida Console is used, with the Arabic letters either having glitc=
hy font substitution (NT 4.0, NT 5.0/2000) or the .notdef glyph (NT 5.1/XP =
and up). In fact, it seems that the only Arabic bitmap fonts that occur in =
Windows NT are CP1256 fonts, which are not used in terminals. So this appea=
rs to be one of those permanent Windows compatibility regressions that occu=
red when Windows 9x ended, where the terminals can no longer render legacy =
Arabic text. Even if the user managed to use registry hacks to set the font=
to Courier New or Simplified Arabic Fixed, it would still use the CP720 ma=
pping which is not compatible with the Windows 9x set. It appears that in=
the Windows 9x Arabic terminal character set, 244 characters (=E2=80=87=EF=
=BA=80=EF=BA=81=EF=BA=82=EF=BA=83=EF=BA=84=EF=BA=85=EF=BA=87=EF=BA=88=EF=BA=
=8A=EF=BA=8B=EF=BA=8D=EF=BA=8E=EF=BA=8F=EF=BA=91=EF=BA=93=E2=96=BA=E2=97=84=
=E2=86=95=EF=BA=95=C2=B6=C2=A7=EF=BA=97=EF=BA=99=E2=86=91=E2=86=93=E2=86=92=
=E2=86=90=EF=BA=9B=EF=B9=B0=E2=96=B2=E2=96=BC !"#$%&'()*+,-./01=
23456789:;<=3D>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst=
uvwxyz{|}~=EF=BA=9D=EF=BA=9F=EF=BA=A1=C3=A9=C3=A2=EF=BA=A3=C3=A0=EF=BA=A5=
=C3=A7=C3=AA=C3=AB=C3=A8=C3=AF=C3=AE=EF=BA=A7=EF=BA=A9=EF=BA=AB=EF=BA=AD=EF=
=BA=AF=C3=B4=EF=BA=B3=C3=BB=C3=B9=EF=BA=B7=EF=BA=BB=C2=A3=EF=BA=BF=EF=BB=81=
=EF=BB=85=EF=BB=89=EF=BB=8A=EF=BB=8B=EF=BB=8C are already in Unicode, but 1=
2 characters are not in Unicode: =E2=80=A2 6 of them are pieces of lam-ale=
f ligatures (0xDD, 0xDE, 0xF9, 0xFB, 0xFC, 0xFD) =E2=80=A2 2 of them are s=
hadda with fathatan ligatures without or with tatweel (0xD0, 0xD1) =E2=80=
=94 in some legacy Microsoft fonts, shadda with fathatan is mapped to priva=
te use U+E818 =E2=80=A2 4 of them are disunifications of seen/sheen/sad/da=
d occuring either with or without tail =E2=80=94=C2=A0=EF=B9=B3 (U+FE73 AR=
ABIC TAIL FRAGMENT) was originally encoded in Unicode 3.2 for CP864 compati=
bility; in that codepage, the forms of=C2=A0seen/sheen/sad/dad attach to th=
e tail fragment =E2=80=94 forms with included tail:=C2=A00x92, 0x95, 0x98,=
0x8A =E2=80=94 forms without tail (attaching to tail fragment like in CP8=
64):=C2=A00xF3, 0xF4, 0xF5, 0xF6 If someone tried to make a Win32 console=
implementation and tried to implement both Windows 9x Arabic terminal char=
acter set compatibility and wide string API (ReadConsoleOutputW) compatibil=
ity simultaneously, then they would run into the issue that there is curren=
tly no standardized mapping to handle that scenario. What should Windows 9x=
Arabic console compatible implementations do in that case?=0D
--2QDQUPDKSBALVUIRXNSYSnhgwp
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<p>In UTC 187 Minutes, "<span style=3D"color: rgb(0, 0, 0); font-family: &q=
uot;DMCA Sans Serif 10.0 dev1"; font-size: medium; font-style: normal;=
font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 40=
0; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px;=
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -=
webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-dec=
oration-style: initial; text-decoration-color: initial; float: none; displa=
y: inline !important;">Asmus Freytag noted that the fact that lists of thin=
gs existed in the past does not make these things plain text. Ned Holbrook =
pointed out that the purported issue occurs in a closed system, not in publ=
ic interchange.</span>". However, the arguments in the proposal do not mere=
ly hinge on the encodings being lists of characters, but specifically point=
s out methods to interchange text, including an example of copying terminal=
output and pasting to Notepad, where the copying invokes the mapping of th=
e current terminal codepage to UCS-2 (as is CHAR_INFO compatible) and the p=
asting writes it into plain text. Win32 is also not a closed system, as Win=
32 can capture the tiles of the output of Windows 3.1 Arabic DOS/Win16 prog=
rams and Windows 95/98/ME Arabic DOS/Win16/Win32 programs, but Win32 can al=
so interact with public text interchange systems by reading and writing to =
files and network. I'm not saying that Unicode absolutely must include thos=
e characters, but those kinds of misleading claims are causing users to mis=
understand what the proposal is about, and I don't want Unicode to be relyi=
ng on uninformed decisions to evaluate proposals.</p><p><br></p><div class=
=3D"nh_extra"><blockquote style=3D"padding-top: 12px;" class=3D"nh_qoute"><=
p style=3D"padding-bottom: 12px;"><strong>Dnia 18 kwietnia 2026 13:36</stro=
ng> <a href=3D"mailto:[email protected]" rel=3D"noopener noreferrer =
nofollow" target=3D"_blank"><span style=3D"margin-left: 4px;">piotrunio-200=
[email protected] via Unicode</span></a><span style=3D"margin-left: 4px;"> < unico=
[email protected] ></span> napisa=C5=82(a):</p><div id=3D"gwpbf2d884a"=
><div id=3D"gwpbf2d884ah"><div class=3D"gwpbf2d884ab" data-message-body=3D"=
true" data-color-mode=3D"light"><p>The SEW subsequently explained that the =
actual reason is due to insufficient evidence of user community that would =
need to use the resulting mapping. Despite Win32 being a highly popular pla=
tform with plenty of backwards compatibility and native UCS-2 terminal supp=
ort, the specific use cases of installing codepages into Windows NT and usi=
ng terminal tiles from Windows 3.1/95/98/ME are not sufficiently documented=
, making it difficult for any user communities to form around it. So it see=
ms like the idea of standardizing legacy Arabic terminal BMP mappings is a =
dead end for now.</p><p><br></p><div class=3D"gwpbf2d884a_nh_extra"><blockq=
uote style=3D"padding-top: 12px;" class=3D"gwpbf2d884a_nh_qoute"><p style=
=3D"padding-bottom: 12px;"><strong>Dnia 17 kwietnia 2026 22:59</strong> <a =
href=3D"mailto:[email protected]" rel=3D"noopener noreferrer nofollo=
w" target=3D"_blank"><span style=3D"margin-left: 4px;">[email protected]=
via Unicode</span></a><span style=3D"margin-left: 4px;"> < unicode@corp=
.unicode.org ></span> napisa=C5=82(a):</p><div id=3D"gwpbf2d884a_gwp2281=
a7f8"><div id=3D"gwpbf2d884a_gwp2281a7f8h"><div class=3D"gwpbf2d884a_gwp228=
1a7f8b" data-message-body=3D"true" data-color-mode=3D"light"><p>The Recomme=
ndations in L2/26-100 claim that Microsoft's documentation of legacy Arabic=
encodings is available at https://learn.microsoft.com/en-us/typography/leg=
acy/legacy_arabic_fonts. However, that article only demonstrates two encodi=
ngs of TrueType fonts, which are used in Windows 3.1 but are completely dif=
ferent from the eight terminal encodings. Unlike the TrueType encodings whi=
ch represent internal shaping mappings and are not used for text interchang=
e, the terminal encodings have been demonstrated to be directly used in tex=
t interchange through int 10h and ReadConsoleOutputA/WriteConsoleOutputA as=
already demonstrated in L2/26-077. The Recommendations also claim that the=
proposal does not demonstrate any need for interchange or encoding, but th=
e proposal actually demonstrated such a need due to the logical extension o=
f the Win32 terminal API to the functions ReadConsoleOutputW/WriteConsoleOu=
tputW, which are in Windows NT and may be used on the output of previously =
ran programs (including those that used the legacy Arabic terminal encoding=
s), which given the CHAR_INFO structure, therefore implies a need for all t=
he tiles to map to BMP for interchange. I'm not objecting to the SEW's conc=
lusion of "Users are expected to use PUA.", which can indeed be used to pro=
vide a mapping even if not standardized, but the reasoning given was flawed=
.</p><p><br></p><div class=3D"gwpbf2d884a_gwp2281a7f8_nh_extra"><blockquote=
style=3D"padding-top: 12px;" class=3D"gwpbf2d884a_gwp2281a7f8_nh_qoute"><p=
style=3D"padding-bottom: 12px;"><strong>Dnia 09 stycznia 2026 17:25</stron=
g> <span style=3D"margin-left: 4px;">[email protected] < piotrunio-20=
[email protected] ></span> napisa=C5=82(a):</p><div id=3D"gwpbf2d884a_gwp2281a7f8=
_gwpa05276c7"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7h"><div class=
=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7b" data-message-body=3D"true" data-c=
olor-mode=3D"light"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f=
718"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718h"><div data=
-color-mode=3D"light" class=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f=
718b" data-message-body=3D"true"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa052=
76c7_gwpa8b5f718_gwpa8b5f718"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c=
7_gwpa8b5f718_gwpa8b5f718h"><div data-color-mode=3D"light" class=3D"gwpbf2d=
884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718_gwpa8b5f718b" data-message-body=3D=
"true"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718_gwpa8b5f7=
18_gwpa8b5f718"><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718_=
gwpa8b5f718_gwpa8b5f718h"><div data-color-mode=3D"light" class=3D"gwpbf2d88=
4a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718_gwpa8b5f718_gwpa8b5f718b" data-messa=
ge-body=3D"true"><p>The following Win32 C code will output 256 characters i=
n system console codepage into the character grid, capture those character =
tiles in UCS-2 if possible, and then output the current console codepage nu=
mber.<br></p><p><br></p><p>#include <windows.h><br>#include <stdio=
.h><br>int main(){<br>HANDLE hConsole=3DGetStdHandle(STD_OUTPUT_HANDLE);=
<br>CHAR_INFO screen[256];<br>COORD size=3D{16,16,};<br>COORD pos=3D{0,0,};=
<br>SMALL_RECT rect=3D{0,0,15,15,};<br>for(int i=3D0;i<256;i++){<br>scre=
en[i].Attributes=3D0xF0;<br>screen[i].Char.AsciiChar=3Di;<br>}<br>WriteCons=
oleOutputA(hConsole,screen,size,pos,&rect);<br>CHAR_INFO screenu[256];<=
br>if(ReadConsoleOutputW(hConsole,screenu,size,pos,&rect)){<br>for(int =
i=3D0;i<256;i++) printf("%04X ",screenu[i].Char.UnicodeChar);<br>}<br>el=
se{<br>printf("error %08X\n",GetLastError());<br>}<br>printf("codepage %u",=
GetConsoleOutputCP());<br>}<br><br></p><p>In most cases, whenever a legacy =
Win32 codepage is used, the application can run on Windows NT to capture th=
e UCS-2 mapping of those character cells to the BMP (although for CJK codep=
ages a more complex setup would be necessary due to thousands of fullwidth =
characters with 2-byte sequences).<br></p><p><br></p><p>However, in Arabic =
versions of Windows 9x (95/98/ME) the resulting character set has many pres=
entation forms that are not in Unicode. This is the result when running on =
Windows ME: <a href=3D"https://i.imgur.com/QFm3SkI.png" =3D"" rel=3D"n=
oopener noreferrer" target=3D"_blank">https://i.imgur.com/QFm3SkI.png</a>&n=
bsp;in 10=C3=9720 font, <a href=3D"https://i.imgur.com/KUbLQ0A.png" =3D"" r=
el=3D"noopener noreferrer" target=3D"_blank">https://i.imgur.com/KUbLQ0A.pn=
g</a> in 10=C3=9718 font (same result also appears in Windows 95/98). =
5=C3=9712, 7=C3=9712, 8=C3=9712, 10=C3=9718, 10=C3=9720, and 12=C3=9716 bit=
map fonts have been attested with that character set (VGAOEM.FON, 8514OEM.F=
ON, DOSAPP.FON). The 10=C3=9720 font has slightly different mapping than th=
e other sizes: 0x93 is =C3=B6 instead of =C3=B4, and 0x97 is missing (causi=
ng the following characters on the same line to be drawn at the wrong posit=
ion). It also claims to be using codepage 720, but many characters differ f=
rom their CP720 mappings, including the bundled CP_720.NLS mappings (f=
or example, =D9=80 (U+0640 ARABIC TATWEEL) is 0x95 in CP720, but in the con=
sole 0x95 is =D8=B4 instead, and the tatweel is at 0xFF). On Windows 9x,&nb=
sp;ReadConsoleOutputW is not supported so the UCS-2 mappings of the console=
character tiles cannot be captured (error 0x00000078 ERROR_CALL_NOT_IMPLEM=
ENTED).<br></p></div></div></div><p><br></p><p>When that program runs on Ar=
abic versions of Windows NT, the visual output is of the CP437 character se=
t if one of the bundled bitmap fonts is used (<a href=3D"https://i.imgur.co=
m/RxjtxMH.png" =3D"" rel=3D"noopener noreferrer" target=3D"_blank">https://=
i.imgur.com/RxjtxMH.png</a>), or the CP720 set if Lucida Console is used, w=
ith the Arabic letters either having glitchy font substitution (NT 4.0, NT =
5.0/2000) or the .notdef glyph (NT 5.1/XP and up). In fact, it seems that t=
he only Arabic bitmap fonts that occur in Windows NT are CP1256 fonts, whic=
h are not used in terminals. So this appears to be one of those permanent W=
indows compatibility regressions that occured when Windows 9x ended, where =
the terminals can no longer render legacy Arabic text. Even if the user man=
aged to use registry hacks to set the font to Courier New or Simplified Ara=
bic Fixed, it would still use the CP720 mapping which is not compatible wit=
h the Windows 9x set.<br></p></div></div><p><br></p></div></div></div></div=
><div id=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718"><div id=3D"gwp=
bf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718h"><div data-color-mode=3D"ligh=
t" class=3D"gwpbf2d884a_gwp2281a7f8_gwpa05276c7_gwpa8b5f718b" data-message-=
body=3D"true"><p>It appears that in the Windows 9x Arabic terminal characte=
r set, 244 characters (=E2=80=87=EF=BA=80=EF=BA=81=EF=BA=82=EF=BA=83=EF=BA=
=84=EF=BA=85=EF=BA=87=EF=BA=88=EF=BA=8A=EF=BA=8B=EF=BA=8D=EF=BA=8E=EF=BA=8F=
=EF=BA=91=EF=BA=93=E2=96=BA=E2=97=84=E2=86=95=EF=BA=95=C2=B6=C2=A7=EF=BA=97=
=EF=BA=99=E2=86=91=E2=86=93=E2=86=92=E2=86=90=EF=BA=9B=EF=B9=B0=E2=96=B2=E2=
=96=BC !"#$%&'()*+,-./0123456789:;<=3D>?@ABCDEFGHIJKLMNOPQRSTUVWX=
YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~=EF=BA=9D=EF=BA=9F=EF=BA=A1=C3=A9=C3=
=A2=EF=BA=A3=C3=A0=EF=BA=A5=C3=A7=C3=AA=C3=AB=C3=A8=C3=AF=C3=AE=EF=BA=A7=EF=
=BA=A9=EF=BA=AB=EF=BA=AD=EF=BA=AF=C3=B4=EF=BA=B3=C3=BB=C3=B9=EF=BA=B7=EF=BA=
=BB=C2=A3=EF=BA=BF=EF=BB=81=EF=BB=85=EF=BB=89=EF=BB=8A=EF=BB=8B=EF=BB=8C=EF=
=BB=8D=EF=BB=8E=EF=BB=8F=EF=BB=90=EF=BB=91=EF=BB=93=EF=BB=95=EF=BB=97=EF=BB=
=99=EF=BB=9B=C2=AB=C2=BB=EF=B9=B1=E2=96=92=EF=B9=B2=E2=94=82=E2=94=A4=EF=B9=
=B4=EF=B9=B6=EF=B9=B7=EF=B9=B8=D9=A0=D9=A1=D9=A2=D9=A3=EF=B9=B9=EF=B9=BA=E2=
=94=90=E2=94=94=E2=94=B4=E2=94=AC=E2=94=9C=E2=94=80=E2=94=BC=EF=B9=BB=EF=B9=
=BE=D9=A4=D9=A5=D9=A6=D9=A7=D9=A8=D9=A9=D8=8C=EF=B9=BF=EF=B1=9E=EF=B1=9F=EF=
=B1=A0=EF=B3=B2=EF=B1=A1=EF=B3=B3=EF=B1=A2=E2=94=98=E2=94=8C=D8=9B=D8=9F=C2=
=A4=EF=BB=9D=EF=BB=9F=EF=BB=A1=EF=BB=A3=EF=BB=A5=EF=BB=A7=C2=B5=EF=BB=A9=EF=
=BB=AB=EF=BB=AC=EF=BB=AD=EF=BB=AF=EF=BB=B0=EF=BB=B1=EF=BB=B2=EF=BB=B3=EF=B3=
=B4=EF=B9=BC=EF=B9=BD=EF=BA=B1=EF=BA=B5=EF=BA=B9=EF=BA=BD=EF=B9=B3=C2=B0=C2=
=B7=E2=96=A0=D9=80) are already in Unicode, but 12 characters are not in Un=
icode:<br></p><p>=E2=80=A2 6 of them are pieces of lam-alef ligatures (0xDD=
, 0xDE, 0xF9, 0xFB, 0xFC, 0xFD)<br></p><p>=E2=80=A2 2 of them are shadda wi=
th fathatan ligatures without or with tatweel (0xD0, 0xD1)<br></p><p>=E2=80=
=94 in some legacy Microsoft fonts, shadda with fathatan is mapped to priva=
te use U+E818<br></p><p>=E2=80=A2 4 of them are disunifications of seen/she=
en/sad/dad occuring either with or without tail<br></p><p>=E2=80=94 =
=EF=B9=B3 (U+FE73 ARABIC TAIL FRAGMENT) was originally encoded in Unicode 3=
.2 for CP864 compatibility; in that codepage, the forms of seen/sheen/=
sad/dad attach to the tail fragment<br></p><p>=E2=80=94 forms with included=
tail: 0x92, 0x95, 0x98, 0x8A<br></p><p>=E2=80=94 forms without tail (=
attaching to tail fragment like in CP864): 0xF3, 0xF4, 0xF5, 0xF6<br><=
/p></div><p><br></p></div><p>If someone tried to make a Win32 console imple=
mentation and tried to implement both Windows 9x Arabic terminal character =
set compatibility and wide string API (ReadConsoleOutputW) compatibility si=
multaneously, then they would run into the issue that there is currently no=
standardized mapping to handle that scenario. What should Windows 9x Arabi=
c console compatible implementations do in that case?<br></p></div><p><br><=
/p></div></div></div></blockquote></div><p><br></p></div></div></div></bloc=
kquote></div><p><br></p></div></div></div></blockquote></div><p><br></p>
--2QDQUPDKSBALVUIRXNSYSnhgwp--