|
De discussie in de mailinglist Atari-nederland maakte nog al wat emoties los. Voor een groot aantal was het al gauw niet meer te volgen en werd het taalgebruik hinderlijk. Voorzover ik mijn uitgangspunten al niet in een eerdere aflevering heb geuit wil ik die nog wel eens herhalen. Het is alweer 18 jaar geleden dat ik vreselijk kwade gezichten ontmoette toen ik een NAW-bestand [naam, adres, woonplaats] moest aanleveren van een PDP mini naar een Burroughs main-frame waar de boekhouding mee draaide. Ze konden niets met de lowercast tekst en of ik dat maar eerst in uppercast wou zetten. Upper- en lowercast zijn thans geen probleem meer en vallen alle onder ASCII wat toch in de eerste [en hopelijk in de laatste] plaats een locale standaard in de USA is. Dat ze daar voldoende hebben aan 7 bits [0-127] is fijn voor de locale bevolking. De rest van de wereld - Europa in ieder geval - heeft minstens 8 bits nodig. Voor een 'letterteken' 8 bits beschikbaar hebben gaat voor de meeste recente computerapparatuur op. Voor wie vast zit aan 7 bits of minder moet toch eens aan de boekhouding vragen of de maximaal vereiste afschrijvingstermijn [10 jaar ??] niet allang verstreken is. Ik zie dan ook geen reden voor clementie - of het zou voor mijn kennissen in Opper-Mauretanië zijn - om bij het versturen van e-mail nog rekening te houden met 7 bits systemen. |
Het vastleggen van 'lettertekens' in 16 bits zou een grote stap voorwaarts, 24bits is alleen maar nodig voor wie naast CJK [Chinees, Japans en Koreaans] ook nog Quechua knopen, verkeersborden en het Apple cq Atari logo aanbrengt in zijn of haar teksten. Zolang we nog niet allen met 16 bits werken [Windows 95 bracht de populariteit ervan iets dichterbij wat als een grote bijdrage van B.G. aan de vooruitgang mag worden gezien] geeft het gebruik van 8 bits alleen maar problemen. Althans... De interpretatie van de getalletjes 0-127 ligt voor 'iedereen' vast. Om te weten hoe de getallen tussen 128 en 255 zijn te interpreteren moeten we eerst aangeven in welke taal [of codepage / characterset] we werken. Wat betekent een 211 - welk 'letterteken' wordt met dit getal vastgelegd? Ooit in de begintijd van de Atari waren er hooguit twee mogelijkheden: ofwel een Hebreeuws teken uit de Atari tekenset of een kaderlijn symbool uit de IBM 437 codepage. De Atari tekenset zit vast gebakken en is desnoods met patch-programma's te veranderen. B.v. met het hier al genoemde 'Latin-3' programma of met 'Polkey' of 'Polonica'. |
|
Met de komst in 1993 van NVDI 3 en volgende werd alles vrijgelaten. Je kon met behulp van een SPDCHAR.MAP file een eigen indeling maken en vanuit de 653 verschillende tekens van de Bitstream Speedo fonts en verbinding leggen - een mapping maken - naar de 0-255 reeks. Papyrus 4.09 en volgende gingen een stap verder en legden de link met een [16 bits] Unicode letterteken-bak. Om dat te kunnen doen moest de SPDCHAR.MAP uitgeschakeld worden [binnen Papryus]. Andere programma's bleven werken onder NVDI/SPDCHAR.MAP of niet!. Bij Papyrus kan ik aangeven of ik teksten importeer met' map' A en exporteer met 'map' B. Uitermate flexibel en er wordt niet stiekem aangenomen dat ik volgens een bepaalde 'map' werk. In de praktijk betekent het dat ik kan aangeven dat bij import de 211 wordt omgezet naar een 'o met accent aigue' en bij export dat teken een code 246 kan krijgen. |
Er zijn situaties dat ik van een programma verwacht dat een code 211 ongewijzigd wordt doorgegeven - dat het programma onverschillig is . Het UDO programma is dat van zich zelf niet maar met een aparte instructie wel zo te maken. Of mijn tekst een etiketje A of B krijgt is niet voor een programma als UDO van belang. Als ik een tekst ten behoeve van een e-mail schrijf dan moet ik er een etiketje aan kunnen hangen. En de ontvanger moet met behulp van dat etiketje ook weer de juiste lettertekens met de juiste codes kunnen associëren. Aan de Atari-kant hebben geen van de mail-programma's die ik ken [Mymail, Amail, Infitra, Newsie] zo'n mogelijkheid [misschien Okami??] terwijl b.v. aan deWindows-kant een Outlook Express een aantal mapping-opties heeft [waaronder UTF-8!]. Bij het verzenden van een mailtje ben ik dus benieuwd wat ze uiteindelijk versturen. Eigenlijk verwacht ik dat als ik er geen etiketje aan hang er niets aan de tekst wordt veranderd. Het lijkt erop dat alleen NEWsie dat netjes doet. |
|
Een programma dat aanneemt dat ik volgens de Atari tekenset werk en vindt dat de standaard ISO-8859-1 is noem ik problematisch. CAB was zo'n probleemgeval [het blijkt dat sinds versie 2.6 de situatie is opgehelderd] . Ik kon met CAB geen SPDCHAR.MAP gebruiken die sec was afgesteld op de ISO-8859-2 [ISO Latin 2] ten behoeve van Poolse websites. CAB was me [Atari-]behulpzaam en verziekte het. Voor andere programma's onder NVDI zou ik prima Pools kunnen schrijven, maar voor het Internet heb ik een andere SPDCHAR.MAP nodig. En als er een Poolse website is die gebruik maakt van Windows 1250 [of CE - Central Europe] dan heb ik een nog groter probleem want enkele Poolse tekens zijn met geen mogelijkheid zo te 'mappen' dat CAB er nog iets van brouwde. |
Hoe waren de reacties in de mailinglist? De reacties waren wisselend zakelijk en emotioneel wat niet zo vreemd is want Robert Best heeft veel energie gestoken in QPmail en daarmee impliciet in de promotie van quoted-printable en Jos de Bekker kreeg 'verantwoording' af te leggen over 'Okami'. Martin Byttebier bracht via:
"Als ik bv. met Newsie een mail ontvangt van Erik Häll dan merk ik dat Newsie (en Infiltra) de 'ä' [ALT 132] vertaalt naar '
de problemen weer terug bij Infitra want op positie 132 staat in Infitra.app 'e4' ofwel een verwijzing naar 228 [met het sommeringsteken, hoofdletter sigma]. De door mij vanuit NEWsie verstuurde reeks letters [aeou met umlaut, e met aigue etc] komen in de NEWsie message file goed leesbaar [zowel met Atari systeemfont als in hexadecimale codes] over. NEWSie laat de codes dus ongestoord passeren. En daar is niet iedereen het mee eens. |
|
Robert Best gooide nog even olie op het vuur door te propageren om 'ASCII > 127' te vermijden. Jos de Bekker en ondergetekende zijn daar nogal fel op tegen. Robert raadt ook 8-bits met charset=ISO-8859-x af vanwege het niet beschikbaar zijn van geschikte viewers op de Atari met de juiste fonts. Dat mag wel zo zijn - wie kent viewers, geen editors dus ?? - maar de interne viewer van Infitra laat zich door een SPDCHAR.MAP sturen [het in het Pools kunnen lezen van sommige messages] en ook [de interne viewer van] NEWSie geeft Poolse mailtjes goed door. Het juist kunnen instellen van de diverse mappings mag dan misschien niet zo relevant lijken voor degenen die uitsluitend met Nederlands- en Anglosaskisch-taligen corresponderen, de Europese Unie omvat meer talen. En dan heb ik het nog niet over de tig-duizend Turkse [of Marokkaanse] medeburgers die voor een probleem gesteld zijn. Dankzij de SPDCHAR.MAP oplossing uit 1993 konden in ieder geval Turkse buurtgenoten van Eva van Goor in Amsterdam gebruik maken van een Atari in hun eigen taal. |