In een eerdere aflevering had ik gesproken over de weinige programma's die al gebruik maakte van een Unicode notatie [16-bits versus 8-bits] om teksten mee vast te leggen. Het van oorsprong Atari-programma Papyrus [nu ook voor OS/2 en Windows 95] kon dit al vanaf versie 4.09 - nu net aangekomen bij versie 6, als alles goed gaat tot in de Atari Messe in Neuss van 4/5 april - en verder had ik alleen vanuit de literatuur begrepen dat Word 97 het ook zou moeten kunnen. Wie echter in de meterslange rij handboeken over MS Word zoekt - achterin de indexen - komt nergens het trefwoord Unicode tegen. Nu zijn alle handboeken geschreven voor de Amerikaanse markt en vervolgens gelocaliseerd in ijltempo voor de Westeuropese markten, dus echt vreemd is het niet. |
Als vertaalbureau kun je tot op zekere hoogte isoleren van het compatibele gebeuren wat zich afspeelt onder MS-Wind/Dos, maar niet geheel. Teksten die tot dus ver werden aangeboden [en weer vertaald teruggeleverd moeten worden] kwamen meestal als WordPerfect 5.x/6.x bestanden binnen. Dankzij de conversie-programmatuur van Robert Best was dat geen enkele probleem. Klanten hoefden niet te weten dat het echte werk werd gedaan op Atari-computers met Atari-programmatuur. Ze zouden alleen al bij het woord Atari gaan denken aan iets E.T.-achtigs. Dus beter in de waan laten! Overigens op de school in Gouda waar ik begin 1998 les gaf bleek een wiskunde-collega te zitten die alles op z'n TT doet met Calamus S/L, en hevig moest gniffelen toen een Atheneum-lerling me vroeg welke processor mijn computer had. Op het antwoord een 68030 - volgde de vraag - maar welk model dan - een TT - en stilte! |
Sinds al weer enige tijd lijkt het MS-imperium ook werkelijk alles te moeten penetreren. Zelfs de MacIntosh als achterdeurtje voor de Atariaan is niet meer veilig. WordPerfect moet op grote schaal plaats maken voor MS-Word daarin gesteund door ijverige universitaire systeembeheerders die geheel opportuun de MS-standaard willen laten wapperen met als voornaamste argument dat WP te veel eigenaars heeft gehad de laatste jaren. Dat imperialisme heeft ook z'n weerslag op het aanbod van teksten. Steeds vaker is de vraag of ook Word-teksten kunnen worden aangeleverd. Zolang ik het kan afwimpelen met 'kan WP ook' is er niets aan de hand. Echter een paar weken terug ging het om een haast klus vanuit het Pools naar het Nederlands waarbij de teksten met Word 97 waren gemaakt. Ik sputterde wel even maar toen aan de andere kant als mogelijke export-optie werd gezegd 'Unicode' raakte ik geintrigeerd. OK, maar dan graag enkele varianten: het eigen formaat van MSWord, Unicode en ASCII. En alles kwam vervolgens als E-mail attachments me op me af. |
Tot dus ver had ik attachments via ESSCODE redelijk kunnen behappen. Vervelend werd het echter als in één aanhangsel meerdere boodschappen bleken te zitten, dan werd alleen de laatste afgehandeld. En dat overkwam me dus nu weer. Wat te doen?? Vaak herinnerde ik me de suggestie van het programma MUNPACK alsook dat ik zo iets had zien zitten in het NEWsie pakket. En gelukkig had ik MUNPACK nog niet als iets overbodigs weggegooid en met het simpele droppen van de file op de MUNPACK.ttp werd alles netjes ontrafeld in afzonderlijke files! De ASCII-file bleek niet echt bruikbaar omdat niet alle Poolse tekens netjes waren omgezet naar andere hogere ASCII-waarden. De veelvoorkomende 'sacute' bleek te zijn samengevallen met een 'o'. Bij kleinere teksten is dat nog te overzien omdat uit de context dit snel te achterhalen is, maar bij langere teksten in het praktisch ondoenlijk:
To jest po prostu bardzo dobry film z gatunku tych, które wszyscy lubiû najbardziej -tüumaczy P.œukasiewicz, socjolog - To komedia, która odnosi siˆ do teraYniejszooci, wrˆcz odwoüuje siˆ do ikon codziennooci, czyli do tego, co ludzie znajû, czytajû, süyszû, co ich otacza, o czym myolû, czego siˆ bojû.
In dit fragment zit b.v. het woord 'codziennooci' waarbij de 'oo' 'o'+'sacute' moet zijn. |
De Unicode file daarentegen geeft een zeer vreemd aanzicht: elke letter wordt omringd door een 'spatie' en de Poolse tekens krijgen gewoon een ander uiterlijk maar nog wel binnen de lagere ASCII-regionen. Wat is daarmee aan de hand? Met behulp van een file editor bleek de tekst te zijn opgebouwd uit byte-paren: [hexadecimaal] 64 00 42 01 etc. Waarbij de niet-Poolse tekens altijd als tweede byte een '00' hadden en de Poolse tekens altijd een '01'. Nu werd opeens duidelijk waarom de tekstvol leek te zitten met 'spaties'. Alle '00' en '01' werden als 'spatie' gepresenteerd, waarbij de '42' als 66 ofwel een 'B' er uit kwam te zien. De '42' '01' moest worden opgevat als '142' [hexadecimaal] waarbij '142' dan precies de Unicode-notatie bleek van 'lslash'. Enzovoorts... [zie tabel]. |
Bij nader onderzoek bleek in de ASCII-uitvoer nog een 'zacute' [die niet zo veel voorkomt] te zijn samengevallen. [zie tabel] Voor de lagere ASCII-waarden [=US-ASCII] lopen ze geheel gelijk op met de Unicode en zelfs de meeste ISO-8859-1 [Latin 1] geven kennelijk geen problemen zoals b.v. te zien aan de oacute en Oacute die gewoon als 'f3' + '00' resp. 'd3' +'00' worden gebracht. |
Maar daarmee was het probleem voor mij nog niet de wereld uit. Ik herinnerde me dat er een simpel programma bestond: 'Replace' waarmee een bepaald op te geven teken vervangen kon worden door een ander. Eeen telefoontje naar Robert Best bevestigde mijn vermoeden. Met zo'n programma zouden alle 18 Poolse letters omgezet moeten kunnen worden, en ook zouden alle '00' vervangen moeten worden door een tijdelijk zinloos teken als een '#' ofzo om later in een tekstverwerker er uit te worden gegooid. Leek me nogal omslachtig. Maar bij gebrek aan beter moet je wel! Bij het downloaden van 'Replace' van het Berenbord bleek de GfA-source aanwezig en dan ligt het verder uitwerken naar een programma dat alles in een ruk doet voor de hand. En zo geschiedde! Met het primitieve 'MS8-Rep' programma werden snel de teksten omgezet naar voor mij verder te bewerken tekst-bestanden en zo kon eindelijk - met enkele uren vertraging - het feitelijke vertaalwerk beginnen. |
Waarom 'MS8'? Het ging toch om tekst afkomstig van MSWord 97?? Een later onderzoekje naar de bijbehorende MSWord 97 files gaf een grote verrassing. Afgezien van de nodige 'overhead' bleek de 'body' van de tekst te bestaan uit precies dezelfde byte-paren als bij de 'Unicode-export'. En daarmee bleek het vermoeden van aan het begin van het verhaal bewaarheid te worden. MSWord 97 slaat tekst dus echt op in een 'Unicode' 16-bits notatie. En in de file komt nergens die '97' terug maar wel als versie-nummer '8'! Ook weer niet vreemd omdat MSWord 97 de opvolger is van MSWord 7. Tevens werd duidelijk waarom er zo veel ophef was over de backward in-compatibiliteit van MSWord 97 naar MSWord 6 [of 7]. Na veel aandringen was er zelfs een terug-conversie programma ontwikkeld en beschikbaar gesteld. Dat zou me verder koud moeten laten, zij het dat ik enkele dagen later weer een 'Poolse' e-mail kreeg met enkele MSWord files. Sommige files kreeg ik netjes geconverteerd, maar andere leken geheel tekst-loos. Bij nader inzien bleek de e-mail een combinatie te zijn van MSWord 6 files [op een lap-top gemaakt] en MSWord 97 [op de desk-top gemaakt] waarbij de MSWord 6 files de mist ingaan met m'n 'MS8-Rep' conversie omdat ik alleen byte-paren met '00' en '01' liet meedoen! |
Als Unicode
2-bytes hex cacute 07/01 107 lslash 42/01 142 nacute 44/01 144 sacute 5b/01 15b zacute 7a/01 17a zdot 7c/01 17c aogonek 05/01 105 eogonek 19/01 119 oacute f3/00 f3 Cacute 06/01 106 Lslash 41/01 141 Nacute 43/01 143 Sacute 5a/01 15a Zacute 79/01 179 Zdot 7b/01 17b Aogonek 04/01 104 Eogonek 18/01 118 Oacute d3/00 d3
alle andere xx < 255 waarden komen op xx/00 ! |
Als ASCII
hex dec cacute 91 145 lslash fc 252 nacute a4 164 sacute 6f 111! zacute 59 89! zdot a8 168 aogonek fb 251 eogonek 88 136 oacute a2 162 Zdot ee 238
|