Home Papyrus Windows 95 M$ Word en HTML

M$ Word

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


Copyright © Rein Bakhuizen van den Brink
Last updated on 26 december 2000

Home Papyrus Windows 95 M$ Word en HTML